| Message ID | 1409240626-6924-15-git-send-email-sjg@chromium.org |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
Hi Tom, On 28 August 2014 17:43, Simon Glass <sjg@chromium.org> wrote: > Since buildman now includes most of the features of MAKEALL it is probably > time to talk about deprecating MAKEALL. > > Comments welcome. > > Signed-off-by: Simon Glass <sjg@chromium.org> Should this patch go in the release? Regards, Simon
On Tue, Oct 14, 2014 at 09:38:36AM +0200, Simon Glass wrote: > Hi Tom, > > On 28 August 2014 17:43, Simon Glass <sjg@chromium.org> wrote: > > Since buildman now includes most of the features of MAKEALL it is probably > > time to talk about deprecating MAKEALL. > > > > Comments welcome. > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > Should this patch go in the release? No, not yet. I am going to mention in the release notes that we're going to strongly start thinking about deleting MAKEALL. We can pick up the deprecation patch early in the next merge window.
Dear Tom, In message <20141014081724.GF25506@bill-the-cat> you wrote: > > No, not yet. I am going to mention in the release notes that we're > going to strongly start thinking about deleting MAKEALL. We can pick up > the deprecation patch early in the next merge window. Can we please keep at least some script (as a wrapper around buildman?) that keeps the old user interface in place? I frequently use "git bisect run MAKEALL <board> ...", and it would be nice if we could keep this working even in newer versions of the code. Or is there a similar alternative command that works with identical parameters for - say - all versions of the last two years or so? Best regards, Wolfgang Denk
Hi Wolfgang, On 22 October 2014 02:33, Wolfgang Denk <wd@denx.de> wrote: > Dear Tom, > > In message <20141014081724.GF25506@bill-the-cat> you wrote: >> >> No, not yet. I am going to mention in the release notes that we're >> going to strongly start thinking about deleting MAKEALL. We can pick up >> the deprecation patch early in the next merge window. > > Can we please keep at least some script (as a wrapper around > buildman?) that keeps the old user interface in place? > > I frequently use "git bisect run MAKEALL <board> ...", and it would > be nice if we could keep this working even in newer versions of the > code. > > Or is there a similar alternative command that works with identical > parameters for - say - all versions of the last two years or so? Unfortunately there is not really an equivalent, and buildman only recently - sets its return code correctly - supports building the current tree (previously it required a branch name for the commit to build) During development of buildman/patman I used to keep a separate tree. Then you can run the latest buildman from that tree using you current directory for the bisect. I could perhaps look at adjusting MAKEALL to call buildman if that solution isn't good enough (this will work assuming that buildman has been set up with toolchains, etc.). Still I think a deprecation warning is a good start. Regards, Simon
On 10/22/2014 08:11 AM, Simon Glass wrote: > Hi Wolfgang, > > On 22 October 2014 02:33, Wolfgang Denk <wd@denx.de> wrote: >> Dear Tom, >> >> In message <20141014081724.GF25506@bill-the-cat> you wrote: >>> >>> No, not yet. I am going to mention in the release notes that we're >>> going to strongly start thinking about deleting MAKEALL. We can pick up >>> the deprecation patch early in the next merge window. >> >> Can we please keep at least some script (as a wrapper around >> buildman?) that keeps the old user interface in place? >> >> I frequently use "git bisect run MAKEALL <board> ...", and it would >> be nice if we could keep this working even in newer versions of the >> code. >> >> Or is there a similar alternative command that works with identical >> parameters for - say - all versions of the last two years or so? > > Unfortunately there is not really an equivalent, and buildman only recently > > - sets its return code correctly > - supports building the current tree (previously it required a branch > name for the commit to build) > > During development of buildman/patman I used to keep a separate tree. > Then you can run the latest buildman from that tree using you current > directory for the bisect. > > I could perhaps look at adjusting MAKEALL to call buildman if that > solution isn't good enough (this will work assuming that buildman has > been set up with toolchains, etc.). Still I think a deprecation > warning is a good start. > Simon, While you work on buildman, please consider to regenerate boards.cfg for each build. If one patch in a series adds a board, there will be a false error for patches before it. York
On Wed, Oct 22, 2014 at 09:11:21AM -0600, Simon Glass wrote: > Hi Wolfgang, > > On 22 October 2014 02:33, Wolfgang Denk <wd@denx.de> wrote: > > Dear Tom, > > > > In message <20141014081724.GF25506@bill-the-cat> you wrote: > >> > >> No, not yet. I am going to mention in the release notes that we're > >> going to strongly start thinking about deleting MAKEALL. We can pick up > >> the deprecation patch early in the next merge window. > > > > Can we please keep at least some script (as a wrapper around > > buildman?) that keeps the old user interface in place? > > > > I frequently use "git bisect run MAKEALL <board> ...", and it would > > be nice if we could keep this working even in newer versions of the > > code. > > > > Or is there a similar alternative command that works with identical > > parameters for - say - all versions of the last two years or so? > > Unfortunately there is not really an equivalent, and buildman only recently > > - sets its return code correctly > - supports building the current tree (previously it required a branch > name for the commit to build) > > During development of buildman/patman I used to keep a separate tree. > Then you can run the latest buildman from that tree using you current > directory for the bisect. > > I could perhaps look at adjusting MAKEALL to call buildman if that > solution isn't good enough (this will work assuming that buildman has > been set up with toolchains, etc.). Still I think a deprecation > warning is a good start. I think for Wolfgang's case that might just have to be handled with an external wrapper, translating all of the ways to run MAKEALL into buildman, reliably, would be a bit of an undertaking. But for bisect run: if [ -x ./MAKEALL ]; then ./MAKEALL $@ else ./tools/buildman/buildman $@ fi And "board" will get built, one way or another, defaulting to MAKEALL while it's still here.
Dear Tom, In message <20141022160936.GY25506@bill-the-cat> you wrote: > > I think for Wolfgang's case that might just have to be handled with an > external wrapper, translating all of the ways to run MAKEALL into Yes, you are right, an external wrapper would work, too. Silly me. OTOH, why not keep a script under the old name that provides such functionality to translate calls to the buildman API? Best regards, Wolfgang Denk
On Wed, Oct 22, 2014 at 06:59:44PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20141022160936.GY25506@bill-the-cat> you wrote: > > > > I think for Wolfgang's case that might just have to be handled with an > > external wrapper, translating all of the ways to run MAKEALL into > > Yes, you are right, an external wrapper would work, too. Silly me. > > OTOH, why not keep a script under the old name that provides such > functionality to translate calls to the buildman API? My concern is that we'll get people complaining about things not being mapped back exactly right. For example, MAKEALL am335x_evm builds one board, am335x_evm_config but buildman am335x_evm builds the whole family of configs. For a build test bisect run, that's fine (even if not optimal in that it'll build more than required). In fact if I read things right (Simon?) buildman is bad for a single board/config. If we map out MAKEALL's -m/-M to just fail and say use get_maintainer.pl I think we can "good enough" map out everything else. With perhaps an echo to please use buildman directly when possible?
Dear Tom, In message <20141022171908.GC25506@bill-the-cat> you wrote: > > My concern is that we'll get people complaining about things not being > mapped back exactly right. For example, MAKEALL am335x_evm builds one > board, am335x_evm_config but buildman am335x_evm builds the whole family > of configs. For a build test bisect run, that's fine (even if not > optimal in that it'll build more than required). In fact if I read > things right (Simon?) buildman is bad for a single board/config. This is one of my open questions with buildman, too. Simon? > If we map out MAKEALL's -m/-M to just fail and say use get_maintainer.pl > I think we can "good enough" map out everything else. With perhaps an > echo to please use buildman directly when possible? Sounds good enough to me. Thanks! Best regards, Wolfgang Denk
Hi Wolfgang, On 22 October 2014 11:37, Wolfgang Denk <wd@denx.de> wrote: > Dear Tom, > > In message <20141022171908.GC25506@bill-the-cat> you wrote: >> >> My concern is that we'll get people complaining about things not being >> mapped back exactly right. For example, MAKEALL am335x_evm builds one >> board, am335x_evm_config but buildman am335x_evm builds the whole family >> of configs. For a build test bisect run, that's fine (even if not >> optimal in that it'll build more than required). In fact if I read >> things right (Simon?) buildman is bad for a single board/config. > > This is one of my open questions with buildman, too. Simon? Yes it does a substring match. I'm open to suggestions on this though. It actually supports regular expressions. > >> If we map out MAKEALL's -m/-M to just fail and say use get_maintainer.pl >> I think we can "good enough" map out everything else. With perhaps an >> echo to please use buildman directly when possible? > > Sounds good enough to me. > > Thanks! Regards, Simon
Dear Simon, In message <CAPnjgZ2ZmGiQoi-mKQxK0vNPCs3hhqgk=z5CxbfSUm8LjU2kNA@mail.gmail.com> you wrote: > > >> My concern is that we'll get people complaining about things not being > >> mapped back exactly right. For example, MAKEALL am335x_evm builds one > >> board, am335x_evm_config but buildman am335x_evm builds the whole family > >> of configs. For a build test bisect run, that's fine (even if not > >> optimal in that it'll build more than required). In fact if I read > >> things right (Simon?) buildman is bad for a single board/config. > > > > This is one of my open questions with buildman, too. Simon? > > Yes it does a substring match. I'm open to suggestions on this though. > It actually supports regular expressions. So something like buildman '^am335x_evm$' would work? Best regards, Wolfgang Denk
Hi Wolfgang, On 22 October 2014 11:56, Wolfgang Denk <wd@denx.de> wrote: > Dear Simon, > > In message <CAPnjgZ2ZmGiQoi-mKQxK0vNPCs3hhqgk= > z5CxbfSUm8LjU2kNA@mail.gmail.com> you wrote: > > > > >> My concern is that we'll get people complaining about things not being > > >> mapped back exactly right. For example, MAKEALL am335x_evm builds one > > >> board, am335x_evm_config but buildman am335x_evm builds the whole > family > > >> of configs. For a build test bisect run, that's fine (even if not > > >> optimal in that it'll build more than required). In fact if I read > > >> things right (Simon?) buildman is bad for a single board/config. > > > > > > This is one of my open questions with buildman, too. Simon? > > > > Yes it does a substring match. I'm open to suggestions on this though. > > It actually supports regular expressions. > > So something like > > buildman '^am335x_evm$' > > would work? > Yes: $ ./tools/buildman/buildman -s am335x_evm -n boards.cfg is up to date. Nothing to do. Dry run, so not doing much. But I would do this: Building current source for 5 boards (4 threads, 1 job per thread) Build directory: ../current am335x_evm : 5 boards Total boards to build for each commit: 5 $ ./tools/buildman/buildman -s am335x_evm$ -n boards.cfg is up to date. Nothing to do. Dry run, so not doing much. But I would do this: Building current source for 1 boards (1 thread, 4 jobs per thread) Build directory: ../current am335x_evm$ : 1 boards Total boards to build for each commit: 1 Regards, Simon
Dear Simon, In message <CAPnjgZ3doDTiju1zJ5WQR-hBx5JkEtm=e7qLsym+q2zSp56R0Q@mail.gmail.com> you wrote: > > > So something like > > buildman '^am335x_evm$' > > would work? > > Yes: Thanks a lot! Best regards, Wolfgang Denk
Hi Wolfgang, On 22 October 2014 12:13, Wolfgang Denk <wd@denx.de> wrote: > Dear Simon, > > In message <CAPnjgZ3doDTiju1zJ5WQR-hBx5JkEtm=e7qLsym+q2zSp56R0Q@mail.gmail.com> you wrote: >> >> > So something like >> > buildman '^am335x_evm$' >> > would work? >> >> Yes: > > Thanks a lot! I hope/think that we are getting through most of the use cases now. The main issue I'm aware of is getting tool chains. Regards, Simon
On Thu, Aug 28, 2014 at 09:43:46AM -0600, Simon Glass wrote: > Since buildman now includes most of the features of MAKEALL it is probably > time to talk about deprecating MAKEALL. > > Comments welcome. > > Signed-off-by: Simon Glass <sjg@chromium.org> Applied to u-boot/master, thanks!
diff --git a/MAKEALL b/MAKEALL index 392ea8d..2321df0 100755 --- a/MAKEALL +++ b/MAKEALL @@ -60,6 +60,14 @@ usage() exit ${ret} } +deprecation() { + echo "** Note: MAKEALL is deprecated - please use buildman instead" + echo "** See tools/buildman/README for details" + echo +} + +deprecation + SHORT_OPTS="ha:c:v:s:b:lmMCnr" LONG_OPTS="help,arch:,cpu:,vendor:,soc:,board:,list,maintainers,mails,check,continue,rebuild-errors" @@ -849,6 +857,8 @@ print_stats() { kill_children fi + deprecation + exit $RC }
Since buildman now includes most of the features of MAKEALL it is probably time to talk about deprecating MAKEALL. Comments welcome. Signed-off-by: Simon Glass <sjg@chromium.org> --- Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: - Remove already-applied patches from the series - Add the deprecation message at the end of the build also - Drop the 'colour' patch sadly Changes in v6: None Changes in v5: - Drop patch to search for *cc instead of *gcc for the compiler MAKEALL | 10 ++++++++++ 1 file changed, 10 insertions(+)