[U-Boot] simple buildman usage

[Tom Rini]

On Wed, Jul 15, 2015 at 02:12:15PM -0600, Stephen Warren wrote:
> On 07/15/2015 10:14 AM, Tom Rini wrote:
> >On Wed, Jul 15, 2015 at 09:54:41AM -0600, Simon Glass wrote:
> >>Hi Stephen,
> >>
> >>On 15 July 2015 at 09:50, Stephen Warren <swarren at wwwdotorg.org> wrote:
> >>>On 07/14/2015 05:33 PM, Tom Rini 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?
> >>>
> >>>
> >>>The same way MAKEALL did; by honoring CROSS_COMPILE:-)
> >>
> >>Do you give it a different CROSS_COMPILE for every arch? Isn't that a pain?
> 
> (I think this is the email Simon asked me to respond to...)
> 
> >And that's the problem / hard part about having buildman do something
> >with CROSS_COMPILE.  CROSS_COMPILE is inherently single-arch.
> 
> IIRC I've seen other projects use CROSS_COMPILE_ARM,
> CROSS_COMPILE_X86, etc. and blindly use those without any kind of
> probing/heuristics, but rather purely based on the architecture the
> tool is building for.
> 
> I'd certainly prefer something that just uses the toolchain that
> it's told to rather than trying to probe a list of them, even if I
> can force something to override the list.

Which is what the preferences file is for[1].  But since you're trying to
avoid making one...

> > And while
> >that's fine for some use cases that's a huge problem for other use
> >cases.  What I have in mind is we add an option called say:
> >--add-tool-chain=PREFIX.  Will force PREFIX to be the toolchain used
> >for whatever architecture the heuristics apply it to.  This will
> >override anything found by the automagic checking.
> >
> >This means that everyone that has automagic scripts for kernel building
> >can wrap in --add-tool-chain=${CROSS_COMPILE} and be done with it.  This
> >is slightlyd different than when I was thinking last night, but I think
> >more useful / less likely to surprise people.

Does this do what you're asking for?

[1]: Yes, it's not quite right in all cases, which I consider something
that needs work.

-- 
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/20150715/65583901/attachment.sig>