Hi York, On 5 August 2014 17:21, York Sun <york...@freescale.com> wrote: > On 08/05/2014 04:07 PM, Simon Glass wrote: >> Hi York, >> >> On 5 August 2014 16:34, York Sun <york...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
