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

Simon Glass
2014-08-06T02:15:27Z

Hi York,

On 5 August 2014 17:21, York Sun <yorksun@freescale.com> wrote:
> 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.

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