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

[Tom Rini]

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)
?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150714/d15ab949/attachment.sig>