[U-Boot] simple buildman usage

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/15/2015 09:54 AM, 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?

No, I almost always only build for ARM. I just very rarely build for 
x86/sandbox, which simply requires not including the CROSS_COMPILE value 
on the command-line. For new shells, I simply cut/paste the 
command-lines from a text file I keep my shell history all saved it, so 
I find it quite easy.