[U-Boot] simple buildman usage

[Stephen Warren <swarren@wwwdotorg.org>]

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@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.

 > 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.
>