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

Simon Glass sjg at chromium.org
Wed Aug 6 16:20:47 CEST 2014


Hi York,

On 5 August 2014 20:53, York Sun <yorksun at freescale.com> wrote:
>
>
> On 8/5/14 7:15 PM, "Simon Glass" <sjg at chromium.org> wrote:
>>>>
>>>> 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?
>
> With the ability to build targets for more than one arch, I will be
> tempted to use syntax like this
>
> buildman (powerpc & freescale) (arm & freescale) aarch64
>
> buildman mpc85xx mpc83xx mpc86xx (arm & freescale) aarch64
>
> buildman powerpc (arm & freescale) aarch64
>
> I can see myself using these commands if they can be supported.

Gosh that sounds like a lot of complexity. Can you explain what you
would want these commands to do?

>
>>
>>>
>>>>
>>>>>
>>>>> 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.
>
> I use "git clean -xfqd" after checkout every commit to make sure I have a
> clean working directory. Each commit can potentially add/remove a board.

Then again, you will have the same problem with MAKEALL so it is more
a Kconfig/process question than a buildman one.

Regards,
Simon


More information about the U-Boot mailing list