[U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released)

[Simon Glass]

Hi Tom,

On 14 July 2015 at 17:33, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
> > On 07/14/2015 04:09 PM, Tom Rini wrote:
> > >On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
> > >>On 07/14/2015 11:56 AM, Tom Rini wrote:
> > >>>Hey all,
> > >>>
> > >>>I've pushed v2015.07 out to the repository and tarballs should exist
> > >>>soon.
> > >>>
> > >>>This sounds a bit like a broken record, but it's true.  The Kconfig
> > >>>migration and DM work continue moving along.
> > >>>
> > >>>Looking over the announcement for v2015.04, I see I said we'd deprecate
> > >>>MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
> > >>>right after the tag.  If buildman isn't working for you and your use
> > >>>case, we really need to talk.
> > >>
> > >>The nice thing about MAKEALL was that I could simply grab a source
> > >>tree, and run the following to build in-tree:
> > >>
> > >>CROSS_COMPILE=something ./MAKEALL foo
> > >>
> > >>However, with buildman, some complex config file needed to be set up
> > >>to configure the toolchain (and I could never parse the docs to work
> > >>out how to create it in a new checkout), plus it made copies of the
> > >>source tree which takes ages for me.
> > >>
> > >>Is there an equivalently simple way to invoke buildman that doesn't
> > >>require configuration and copying?
> > >
> > >For no copying, --in-tree does what you want I think.
> >
> > OK. Making that the default would be useful, or providing a buildman
> > wrapper script in the root directory that always passes this option.
> >
> > >For not
> > >configuring a toolchain, there's two ways to go about this.  One would
> > >be to do something like:
> > >
> > >diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
> > >index e33e105..bba60d5 100644
> > >--- a/tools/buildman/toolchain.py
> > >+++ b/tools/buildman/toolchain.py
> > >@@ -159,7 +159,7 @@ class Toolchains:
> > >                   " to your buildman config file %s. See README for details" %
> > >                   bsettings.config_fname)
> > >
> > >-        paths = []
> > >+        paths = ['/usr', '/usr/local']
> > >          for name, value in toolchains:
> > >              if '*' in value:
> > >                  paths += glob.glob(value)
> > >
> > >And then any toolchains in /usr and /usr/local would be picked up and
> > >used.  Another option would be to add --tool-chain-path DIR and throw
> > >that into the above function.  Thoughts?
> >
> > Does that find cross-compilers? IIRC I had to add the full compiler
> > binary name into the config file, not just a /usr search directory,
> > so I don't think the above patch is enough to make it work. What if
> > I want to use a specific cross-compiler and I have 4 different ARM
> > compilers installed in /usr? How would it know which architecture's
> > cross-compiler to use?
>
> Well, how much are you expecting to Just Work without making a real
> config?  That much does work for finding cross tools installed into
> those paths.  But if you have > 1 architecture toolchain in a
> single location buildman does fail there today.
>
> > I like the interface of just setting the CROSS_COMPILE variable,
> > since I can just set it in the environment and forget it if I want.
> > Perhaps buildman could just use it if it was set, and ignore the
> > config file (or again, a simple wrapper script could do that)?
>
> I do not want a wrapper script.  Trying to make one thing act like
> another thing leads to madness and corner cases.  That said, how hard
> would it be to have buildman see if CROSS_COMPILE is set and in turn
> force that to be used for all specified build targets?  I thought about
> making it see what the value is and then heuristic which arch to use,
> but I think that's more error prone than perhaps buildman
> --default-tool-chain (Uses passed value or CROSS_COMPILE if set in env)

We can do that - is this a boolean value? What do you mean by 'passed value'?

Regards,
Simon