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

[Simon Glass]

Hi York,

On 5 August 2014 17:21, York Sun <yorksun at freescale.com> wrote:
> On 08/05/2014 04:07 PM, Simon Glass wrote:
>> Hi York,
>>
>> On 5 August 2014 16:34, York Sun <yorksun at 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.

I suppose you could use mx6 or similar, but I take your point.

So what could we do here? Perhaps add a --vendor flag to limit to a
particular vendor? Would that be enough?

>
>>
>>>
>>> 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.

I don't think it works like that. Once you have a boards.cfg you don't
need to regenerate it. Granted if a patch adds a new board there will
be confusion.

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

Regards,
Simon