| Message ID | 1403886360-32033-1-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Accepted |
| Headers | show |
Hi Alexey, On Fri, Jun 27, 2014 at 6:26 PM, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > The use of MAKE1 for uClibc dates back 10 years: > > commit 8e5fb3fb4ab09b4dc04fe7cb3f7becce6514117b > Author: Eric Andersen <andersen@codepoet.org> > Date: Sat Dec 11 13:01:10 2004 +0000 > > Add initial BR2_JLEVEL support, with some exceptions for apps that > have broken 'make -j' support > > Since that time there were lots of improvements in uClibc that seem to allow > parallel building of libs finally. > > Unfortunately uClibc tests have dependences on previously built files, > that's why tests left with MAKE1. > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > > Cc: Anton Kolesov <akolesov@synopsys.com> > Cc: Peter Korsgaard <peter@korsgaard.com> > Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > --- > In v2 uClibc tests are left with MAKE1 because there're strict > dependences. > --- > package/uclibc/uclibc.mk | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk > index b42fe55..28a8a08 100644 > --- a/package/uclibc/uclibc.mk > +++ b/package/uclibc/uclibc.mk > @@ -494,13 +494,13 @@ endef > endif > > define UCLIBC_BUILD_CMDS > - $(MAKE1) -C $(@D) \ > + $(MAKE) -C $(@D) \ > $(UCLIBC_MAKE_FLAGS) \ > PREFIX= \ > DEVEL_PREFIX=/ \ > RUNTIME_PREFIX=/ \ > all > - $(MAKE1) -C $(@D)/utils \ > + $(MAKE) -C $(@D)/utils \ > PREFIX=$(HOST_DIR) \ > HOSTCC="$(HOSTCC)" hostutils > $(UCLIBC_BUILD_TEST_SUITE) There are other occurrences of MAKE1 in uclibc.mak: for the oldconfig step (in SETUP_DOT_CONFIG), configure commands, installation commands, and menuconfig step. I think these should be replaced by MAKE too (and tested, of course). Best regards, Thomas
Hi Thomas, > There are other occurrences of MAKE1 in uclibc.mak: for the oldconfig > step (in SETUP_DOT_CONFIG), configure commands, installation commands, > and menuconfig step. > I think these should be replaced by MAKE too (and tested, of course). I did notice there're many more MAKE1 in use. But knowing unfortunate fate of uClibc in terms of parallel building I wanted to do minimal changes that still make significant difference in Buildroot usage (i.e. make building faster). The most time consuming process is uClibc building itself and I made it parallel - that shortens uClibc significantly. As for other invocations of MAKE1 IMHO there's not much sense in use of parallel make for configuration like "oldconfig" and friends (not much things here are compiled) or "install" (where we only have file copy operations and that's why I don't expect any gain in speed if we run them in parallel). So I'd prefer to proceed with incremental changes. Once parallel build is proven for all arches by autobuilder (which may disclose issues on arches I haven't try the change yet - I did tests for ARC and x86) we may consider more changes (note I already found that built-in tests won't build in parallel). What do you think? -Alexey
Dear Alexey Brodkin, On Fri, 27 Jun 2014 20:26:00 +0400, Alexey Brodkin wrote: > The use of MAKE1 for uClibc dates back 10 years: > > commit 8e5fb3fb4ab09b4dc04fe7cb3f7becce6514117b > Author: Eric Andersen <andersen@codepoet.org> > Date: Sat Dec 11 13:01:10 2004 +0000 > > Add initial BR2_JLEVEL support, with some exceptions for apps that > have broken 'make -j' support > > Since that time there were lots of improvements in uClibc that seem to allow > parallel building of libs finally. > > Unfortunately uClibc tests have dependences on previously built files, > that's why tests left with MAKE1. > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Applied, thanks! Thomas
Hi Alexey, On Sun, Jun 29, 2014 at 11:59 AM, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > Hi Thomas, > >> There are other occurrences of MAKE1 in uclibc.mak: for the oldconfig >> step (in SETUP_DOT_CONFIG), configure commands, installation commands, >> and menuconfig step. >> I think these should be replaced by MAKE too (and tested, of course). > > I did notice there're many more MAKE1 in use. > > But knowing unfortunate fate of uClibc in terms of parallel building I wanted to do minimal changes that still make significant difference in Buildroot usage (i.e. make building faster). > The most time consuming process is uClibc building itself and I made it parallel - that shortens uClibc significantly. > > As for other invocations of MAKE1 IMHO there's not much sense in use of parallel make for configuration like "oldconfig" and friends (not much things here are compiled) or "install" (where we only have file copy operations and that's why I don't expect any gain in speed if we run them in parallel). > > So I'd prefer to proceed with incremental changes. Once parallel build is proven for all arches by autobuilder (which may disclose issues on arches I haven't try the change yet - I did tests for ARC and x86) we may consider more changes (note I already found that built-in tests won't build in parallel). > > What do you think? Sure, we can wait a short while before enabling $(MAKE) for the other targets. But I think we should certainly do it, because the buildroot default is $(MAKE) not $(MAKE1). So using $(MAKE1) should only be done if there are good reason. One particular reason that I want to go for $(MAKE) is for the menuconfig target, as I'm working on a kconfig-package infrastructure that will line up the kconfig handling in busybox, uclibc, linux, ... Since uclibc uses MAKE1 here, it deviates from the other packages using kconfig, posing a problem for commonalization in kconfig-package. Best regards, Thomas
Hi Thomas, On Sun, 2014-06-29 at 14:43 +0200, Thomas De Schampheleire wrote: > > Sure, we can wait a short while before enabling $(MAKE) for the other > targets. But I think we should certainly do it, because the buildroot > default is $(MAKE) not $(MAKE1). So using $(MAKE1) should only be done > if there are good reason. > > One particular reason that I want to go for $(MAKE) is for the > menuconfig target, as I'm working on a kconfig-package infrastructure > that will line up the kconfig handling in busybox, uclibc, linux, ... > Since uclibc uses MAKE1 here, it deviates from the other packages > using kconfig, posing a problem for commonalization in > kconfig-package. Makes perfect sense! If this topic is important for you may I ask you to remind me about it in a while if I forget to do/test/post mentioned changes in coming weeks? It's not a rocket science but mostly a matter of testing how changes impact building. Even with this patch (which is already applied - kudos to Thomas P) I faced troubles trying to build uClibc tests: for x86 due to pretty old uClibc I had to find and apply this patch: ==== test: tls: fix build with newer binutils http://git.uclibc.org/uClibc/commit/test?id=931e8391565323ed2e589c83b83a7345813a5514 ==== -Alexey
Dear Alexey Brodkin, On Fri, 27 Jun 2014 20:26:00 +0400, Alexey Brodkin wrote: > The use of MAKE1 for uClibc dates back 10 years: > > commit 8e5fb3fb4ab09b4dc04fe7cb3f7becce6514117b > Author: Eric Andersen <andersen@codepoet.org> > Date: Sat Dec 11 13:01:10 2004 +0000 > > Add initial BR2_JLEVEL support, with some exceptions for apps that > have broken 'make -j' support > > Since that time there were lots of improvements in uClibc that seem to allow > parallel building of libs finally. > > Unfortunately uClibc tests have dependences on previously built files, > that's why tests left with MAKE1. > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> This patch apparently breaks the build on AVR32, which uses an old (0.9.31) version of uClibc. So maybe we should use $(MAKE) instead of $(MAKE1) only for uClibc >= 0.9.33 ? See http://jenkins.free-electrons.com/job/buildroot/config=atstk100x_defconfig/298/consoleText for the build log. Both AVR32 defconfigs failed to build tonight, and the only patch I can think of that was applied yesterday in relation to uClibc is the parallel build one. Thanks, Thomas Petazzoni
Hi Thomas, On Mon, 2014-06-30 at 09:24 +0200, Thomas Petazzoni wrote: > This patch apparently breaks the build on AVR32, which uses an old > (0.9.31) version of uClibc. So maybe we should use $(MAKE) instead of > $(MAKE1) only for uClibc >= 0.9.33 ? > > See > http://jenkins.free-electrons.com/job/buildroot/config=atstk100x_defconfig/298/consoleText > for the build log. Both AVR32 defconfigs failed to build tonight, and > the only patch I can think of that was applied yesterday in relation to > uClibc is the parallel build one. Thanks for this. Let me look at this issue on AVR32. Frankly I'd prefer to escape conditions withing "uclibc.mk" - this condition will remain for many years until somebody tries to do another round of clean-up. I'll try to find an upstream patch that fixes disclosed issue and put it in "package/uclibc/0.9.31.1". What do you think of this approach? -Alexey
Dear Alexey Brodkin, On Mon, 30 Jun 2014 07:29:50 +0000, Alexey Brodkin wrote: > Thanks for this. > Let me look at this issue on AVR32. > > Frankly I'd prefer to escape conditions withing "uclibc.mk" - this > condition will remain for many years until somebody tries to do another > round of clean-up. > > I'll try to find an upstream patch that fixes disclosed issue and put it > in "package/uclibc/0.9.31.1". > > What do you think of this approach? I personally think it's OK to use $(MAKE) for uClibc >= 0.9.33 and $(MAKE1) for older versions. We only have 0.9.31 to support AVR32, and since it's an obsolete architecture, I believe we might propose to deprecate it during the 2014.08 cycle, so I don't think it's worth spending time on issues relevant only to 0.9.31. If that's done, then we'll be able to get rid of 0.9.31 and 0.9.32. I don't think it makes sense to support such old uClibc releases. Best regards, Thomas
diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk index b42fe55..28a8a08 100644 --- a/package/uclibc/uclibc.mk +++ b/package/uclibc/uclibc.mk @@ -494,13 +494,13 @@ endef endif define UCLIBC_BUILD_CMDS - $(MAKE1) -C $(@D) \ + $(MAKE) -C $(@D) \ $(UCLIBC_MAKE_FLAGS) \ PREFIX= \ DEVEL_PREFIX=/ \ RUNTIME_PREFIX=/ \ all - $(MAKE1) -C $(@D)/utils \ + $(MAKE) -C $(@D)/utils \ PREFIX=$(HOST_DIR) \ HOSTCC="$(HOSTCC)" hostutils $(UCLIBC_BUILD_TEST_SUITE)
The use of MAKE1 for uClibc dates back 10 years: commit 8e5fb3fb4ab09b4dc04fe7cb3f7becce6514117b Author: Eric Andersen <andersen@codepoet.org> Date: Sat Dec 11 13:01:10 2004 +0000 Add initial BR2_JLEVEL support, with some exceptions for apps that have broken 'make -j' support Since that time there were lots of improvements in uClibc that seem to allow parallel building of libs finally. Unfortunately uClibc tests have dependences on previously built files, that's why tests left with MAKE1. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- In v2 uClibc tests are left with MAKE1 because there're strict dependences. --- package/uclibc/uclibc.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)