[U-Boot] simple buildman usage

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/14/2015 05:37 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 14 July 2015 at 17:27, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/14/2015 05:07 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 14 July 2015 at 16:39, Stephen Warren <swarren@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.
>>
>>
>> I'd prefer it to go in . so I don't get clutter outside my working tree.
>
> -o .
>
>>
>>> 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.
>>
>>
>> I already have the toolchain I want to use installed, so I'd like a simple
>> way to use it.
>>
>>> But honestly the config file is not that hard to figure out!
>>
>>
>> Well perhaps if you understand its concepts/semantics, but I've always had
>> an extremely hard time grasping it, and at least the last time I RTFMd there
>> weren't any examples aimed at "this is how to write a config file to just
>> use this binary name in $PATH". Equally, having to edit a config file any
>> time I want to switch compilers is a bit annoying.
>
> Agreed. Perhaps annoying enough to contribute a patch?

I recall vaguely looking at the buildman source to try and work out how 
the config file worked, but failing. Most likely, I'll just save off a 
shell snippet that runs "make xxx_config && make" and use that instead.