[U-Boot] [PATCH v4 02/13] buildman: Add some notes about moving from MAKEALL

York Sun
2014-08-05T23:21:03Z

On 08/05/2014 04:07 PM, Simon Glass wrote:
> Hi York,
>
> On 5 August 2014 16:34, York Sun <yorksun@freescale.com> wrote:
>> On 08/05/2014 07:46 AM, Simon Glass wrote:
>>> + - build all Freescale boards with MPC83xx CPUs, plus all 4xx boards:
>>> + MAKEALL -c mpc83xx -v freescale 4xx
>>> + ** buildman -b <branch> mpc83xx freescale 4xx
>>> +
>>
>> This is not very clear to me. Is the condition "AND", or "OR"? When I do
>> "MAKEALL -c mpc83xx -v freescale", I want to build all Freescale boards with
>> MPC83xx. It is "AND". But with the buildman command, it is "OR". Examples below
>>
>> $ ./tools/buildman/buildman -n -b master mpc83xx
>> No section: 'make-flags'
>> Could not find ./boards.cfg
>> Generating boards.cfg ... (jobs: 4)
>> 1177/1177 [=======================================================>]
>> Dry run, so not doing much. But I would do this:
>>
>> Building 14 commits for 50 boards (4 threads, 1 job per thread)
>> Build directory: ../denx_master
>> 25b4adbb include: remove CONFIG_SPL/CONFIG_TPL definition in config headers
>> 35c84002 buildman: Fix a few typos
>> b308e4a8 buildman: Add some notes about moving from MAKEALL
>> cd739429 buildman: Allow building of current source tree
>> 5ace7165 buildman: Move BuilderThread code to its own file
>> d095b480 buildman: Sort command line options
>> 5bf27712 buildman: Refactor output options
>> 461f4050 buildman: Add verbose option to display errors as they happen
>> 65f46549 buildman: Remove unused non-incremental build method code
>> 0723a71a buildman: Add an option to specify the buildman config file
>> b2b89c32 buildman: Add a message indicating there are no errors
>> eedb4545 buildman: Search for *cc instead of *gcc for the compiler
>> fe99029f buildman: Add a few more toolchain examples to the README
>> c976629f RFC: Deprecate MAKEALL
>>
>> mpc83xx : 50 boards
>> Total boards to build for each commit: 50
>>
>> $ ./tools/buildman/buildman -n -b master mpc83xx freescale
>> No section: 'make-flags'
>> Dry run, so not doing much. But I would do this:
>>
>> Building 14 commits for 364 boards (4 threads, 1 job per thread)
>> Build directory: ../denx_master
>> 25b4adbb include: remove CONFIG_SPL/CONFIG_TPL definition in config headers
>> 35c84002 buildman: Fix a few typos
>> b308e4a8 buildman: Add some notes about moving from MAKEALL
>> cd739429 buildman: Allow building of current source tree
>> 5ace7165 buildman: Move BuilderThread code to its own file
>> d095b480 buildman: Sort command line options
>> 5bf27712 buildman: Refactor output options
>> 461f4050 buildman: Add verbose option to display errors as they happen
>> 65f46549 buildman: Remove unused non-incremental build method code
>> 0723a71a buildman: Add an option to specify the buildman config file
>> b2b89c32 buildman: Add a message indicating there are no errors
>> eedb4545 buildman: Search for *cc instead of *gcc for the compiler
>> fe99029f buildman: Add a few more toolchain examples to the README
>> c976629f RFC: Deprecate MAKEALL
>>
>> mpc83xx : 50 boards
>> freescale : 314 boards
>> Total boards to build for each commit: 364
>>
>> This is not the desired target list.
>
> OK I see.
>
> But in this case why not just leave off the 'freescale'?

This is just an example. What if I chose "-a arm" and "-v freescale". ARM has
300+ targets, but only 20+ are for Freescale. I could save time by building a
lot less platforms.

The point here is the "OR" logic.

>
>>
>> Beside, buildman still needs boards.cfg. It takes long to generate this file.
>
> So does MAKEALL, right?

Yes. MAKEALL also generates the boards.cfg.

>
>> Not too long, but if my other tools clean the working directory for each commit,
>> this accumulates to long time.
>
> Can you expand on at a little please? I'm not sure what this refers to.
>
Again it is our internal tools of choice. We use Gerrit and Jenkins. Each commit
triggers a build on Jenkins. Right now I use MAKEALL to build the concerned
targets. Before each build, the working directory is checkout out to that
particular commit and cleaned. So if each build needs to generate the
boards.cfg, a lot of time will be consumed if I have many commits in the queue.

But generating boards.cfg is not caused by your patch. I just point out what I saw.

York