From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Warren <swarren@wwwdotorg.org>
Date: Tue, 14 Jul 2015 16:39:01 -0600
Subject: [U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07
	released)
In-Reply-To: <20150714220949.GD25532@bill-the-cat>
References: <20150714175627.GJ23886@bill-the-cat>
 <55A56CED.5090008@wwwdotorg.org> <20150714220949.GD25532@bill-the-cat>
Message-ID: <55A58F85.9090300@wwwdotorg.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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?

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