| Message ID | 1407250023-9501-3-git-send-email-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
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. Beside, buildman still needs boards.cfg. It takes long to generate this file. Not too long, but if my other tools clean the working directory for each commit, this accumulates to long time. York
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'? > > Beside, buildman still needs boards.cfg. It takes long to generate this file. So does MAKEALL, right? > 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. Regards, Simon
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
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
On 8/5/14 7:15 PM, "Simon Glass" <sjg@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. > >> >>> >>>> >>>> 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. York >
Hi York, On 5 August 2014 20:53, York Sun <yorksun@freescale.com> wrote: > > > On 8/5/14 7:15 PM, "Simon Glass" <sjg@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
On Wed, Aug 06, 2014 at 08:20:47AM -0600, Simon Glass wrote: > Hi York, > > On 5 August 2014 20:53, York Sun <yorksun@freescale.com> wrote: > > > > > > On 8/5/14 7:15 PM, "Simon Glass" <sjg@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 Spaces outside of parens are implicit ORs here, so all powerpc+freescale, all arm+freescale and all aarch64. In the fullness of time the last one might become all freescale+aarch64. Bonus points if we can easily write 'buildman ... ((powerpc|arm|aarch64) & freescale)' Thinking out loud, the problem is today we have | for OR but we don't have an AND symbol. I can do: $ buildman 'arm|powerpc|aarch64' Today and get what I want. But I can't: $ buildman '(powerpc&freescale)|(arm&freescale)'
Hi Tom, York, On 6 August 2014 09:06, Tom Rini <trini@ti.com> wrote: > On Wed, Aug 06, 2014 at 08:20:47AM -0600, Simon Glass wrote: >> Hi York, >> >> On 5 August 2014 20:53, York Sun <yorksun@freescale.com> wrote: >> > >> > >> > On 8/5/14 7:15 PM, "Simon Glass" <sjg@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 > > Spaces outside of parens are implicit ORs here, so all > powerpc+freescale, all arm+freescale and all aarch64. In the fullness > of time the last one might become all freescale+aarch64. Bonus points > if we can easily write 'buildman ... ((powerpc|arm|aarch64) & freescale)' > > Thinking out loud, the problem is today we have | for OR but we don't > have an AND symbol. I can do: > $ buildman 'arm|powerpc|aarch64' > Today and get what I want. But I can't: > $ buildman '(powerpc&freescale)|(arm&freescale)' OK I'll have a crack at this. Regards, Simon
Hi. On Thu, 7 Aug 2014 06:12:18 -0600 Simon Glass <sjg@chromium.org> wrote: > Hi Tom, York, > > On 6 August 2014 09:06, Tom Rini <trini@ti.com> wrote: > > On Wed, Aug 06, 2014 at 08:20:47AM -0600, Simon Glass wrote: > >> Hi York, > >> > >> On 5 August 2014 20:53, York Sun <yorksun@freescale.com> wrote: > >> > > >> > > >> > On 8/5/14 7:15 PM, "Simon Glass" <sjg@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 > > > > Spaces outside of parens are implicit ORs here, so all > > powerpc+freescale, all arm+freescale and all aarch64. In the fullness > > of time the last one might become all freescale+aarch64. Bonus points > > if we can easily write 'buildman ... ((powerpc|arm|aarch64) & freescale)' > > > > Thinking out loud, the problem is today we have | for OR but we don't > > have an AND symbol. I can do: > > $ buildman 'arm|powerpc|aarch64' > > Today and get what I want. But I can't: > > $ buildman '(powerpc&freescale)|(arm&freescale)' > > OK I'll have a crack at this. > I am afraid the requirement for buildman is getting too complicated. > > $ buildman '(powerpc&freescale)|(arm&freescale)' This feature completely depends on boards.cfg but we want to completely break with it, don't we? Grepping Kconfig for searching Freescale boards is almost impossible, I think. Maybe it is time to change our mind. But I have no idea for the replacement. Best Regards Masahiro Yamada
Hi Masahiro, On 7 August 2014 07:14, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi. > > > > On Thu, 7 Aug 2014 06:12:18 -0600 > Simon Glass <sjg@chromium.org> wrote: > >> Hi Tom, York, >> >> On 6 August 2014 09:06, Tom Rini <trini@ti.com> wrote: >> > On Wed, Aug 06, 2014 at 08:20:47AM -0600, Simon Glass wrote: >> >> Hi York, >> >> >> >> On 5 August 2014 20:53, York Sun <yorksun@freescale.com> wrote: >> >> > >> >> > >> >> > On 8/5/14 7:15 PM, "Simon Glass" <sjg@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 >> > >> > Spaces outside of parens are implicit ORs here, so all >> > powerpc+freescale, all arm+freescale and all aarch64. In the fullness >> > of time the last one might become all freescale+aarch64. Bonus points >> > if we can easily write 'buildman ... ((powerpc|arm|aarch64) & freescale)' >> > >> > Thinking out loud, the problem is today we have | for OR but we don't >> > have an AND symbol. I can do: >> > $ buildman 'arm|powerpc|aarch64' >> > Today and get what I want. But I can't: >> > $ buildman '(powerpc&freescale)|(arm&freescale)' >> >> OK I'll have a crack at this. >> > > I am afraid the requirement for buildman is getting too complicated. > > >> > $ buildman '(powerpc&freescale)|(arm&freescale)' > > This feature completely depends on boards.cfg > but we want to completely break with it, don't we? > > Grepping Kconfig for searching Freescale boards > is almost impossible, I think. Actually buildman requires this information regardless, so it knows what boards to build. It needs a list of all boards even if there are no conditions. > > Maybe it is time to change our mind. > But I have no idea for the replacement. Let's continue in the other thread. Regards, Simon
diff --git a/tools/buildman/README b/tools/buildman/README index a5d181c..1c919af 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -3,6 +3,8 @@ # SPDX-License-Identifier: GPL-2.0+ # +(Please read 'How to change from MAKEALL' if you are used to that tool) + What is this? ============= @@ -663,6 +665,96 @@ Other options Buildman has various other command line options. Try --help to see them. +How to change from MAKEALL +========================== + +Buildman includes most of the features of MAKEALL and is generally faster +and easier to use. In particular it builds entire branches: if a particular +commit introduces an error in a particular board, buildman can easily show +you this, even if a later commit fixes that error. + +The reasons to deprecate MAKEALL are: +- We don't want to maintain two build systems +- Buildman is typically faster +- Buildman has a lot more features + +But still, many people will be sad to lose MAKEALL. If you are used to +MAKEALL, here are a few pointers. + +First you need to set up your tool chains - see the 'Setting up' section +for details. Once you have your required toolchain(s) detected then you are +ready to go. + +Buildman works on entire branches, so the normal use is: + + ./tools/buildman/buildman -b <branch_name> <list of things to build> + +followed by (afterwards, or perhaps concurrently in another terminal): + + ./tools/buildman/buildman -b <branch_name> -s <list of things to build> + +to see the results of the build. Rather than showing you all the output, +buildman just shows a summary, with red indicating that a commit introduced +an error and green indicating that a commit fixed an error. Use the -e +flag to see the full errors. + +You don't need to stick around on that branch while buildman is running. It +checks out its own copy of the source code, so you can change branches, +add commits, etc. without affecting the build in progress. + +The <list of things to build> can include board names, architectures or the +like. There are no flags to disambiguate since ambiguities are rare. Using +the examples from MAKEALL: + +Examples: + - build all Power Architecture boards: + MAKEALL -a powerpc + MAKEALL --arch powerpc + MAKEALL powerpc + ** buildman -b <branch> powerpc + - build all PowerPC boards manufactured by vendor "esd": + MAKEALL -a powerpc -v esd + ** buildman -b <branch> esd + - build all PowerPC boards manufactured either by "keymile" or "siemens": + MAKEALL -a powerpc -v keymile -v siemens + ** buildman -b <branch> keymile siemens + - build all Freescale boards with MPC83xx CPUs, plus all 4xx boards: + MAKEALL -c mpc83xx -v freescale 4xx + ** buildman -b <branch> mpc83xx freescale 4xx + +Buildman automatically tries to use all the CPUs in your machine. If you +are building a lot of boards it will use one thread for every CPU core +it detects in your machine. This is like MAKEALL's BUILD_NBUILDS option. +You can use the -T flag to change the number of threads. If you are only +building a few boards, buildman will automatically run make with the -j +flag to increase the number of concurrent make tasks. It isn't normally +that helpful to fiddle with this option, but if you use the BUILD_NCPUS +option in MAKEALL then -j is the equivalent in buildman. + +Buildman puts its output in ../<branch_name> by default but you can change +this with the -o option. Buildman normally does out-of-tree builds: use -i +to disable that if you really want to. But be careful that once you have +used -i you pollute buildman's copies of the source tree, and you will need +to remove the build directory (normally ../<branch_name>) to run buildman +in normal mode (without -i). + +Buildman doesn't keep the output result normally, but use the -k option to +do this. + +Please read 'Theory of Operation' a few times as it will make a lot of +things clearer. + +Some options you might like are: + + -B shows which functions are growing/shrinking in which commit - great + for finding code bloat. + -S shows image sizes for each commit (just an overall summary) + -u shows boards that you haven't built yet + --step 0 will build just the upstream commit and the last commit of your + branch. This is often a quick sanity check that your branch doesn't + break anything. But note this does not check bisectability! + + TODO ====
For those used to MAKEALL, buildman seems strange. Add some notes to ease the transition. Signed-off-by: Simon Glass <sjg@chromium.org> --- Changes in v4: None Changes in v3: None Changes in v2: - Minor changes to the text tools/buildman/README | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+)