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

[Simon Glass]

Hi Stephen,

On 14 July 2015 at 16:39, Stephen Warren <swarren at wwwdotorg.org> 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.

$ buildman seaboard

will build U-Boot for seaboard. It does not copy the git tree. It puts
the output in ../current, or some other directory of your choosing. I
think that's pretty convenient.

For toolchains you can use

$ buildman --fetch-arch arm

to get a default one and set it up ready for use complete with config
file. But honestly the config file is not that hard to figure out!

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

That would work for building a single arch. We could perhaps add an
option for that. But full multi-toolchain support is something that
would be nice to add to buildman, if someone has time.

Regards,
Simon