core: don't reset MAKEOVERRIDES when re-entering make
PATCH 1/2 core: don't reset MAKEOVERRIDES when re-entering make
We reset MAKEOVERRIDES to avoid passing down variables that are overridden on the command line to the package build systems. Indeed, the variables overridden on the command line will be Buildroot variables and not relevant to the package build system. In particular the O option is used by some packages and the value passed in on the command line is plain wrong for the individual package.
However, in commit 916e614b, MAKEOVERRIDES was moved earlier and it was reset _before_ re-entering make in the cases when something has to be fixed up (incorrect umask, non-absolute paths in O or CURDIR). Therefore, if make is re-entered, any command line overrides are lost.
This particularly bites the autobuilders, because they use O=<relative path> to specify the output directory, and they add BR2_JLEVEL=... to avoid starting too many jobs in parallel. The BR2_JLEVEL override is lost.
---
I have a little worry, because there are two other places where we re- enter top-level make and those are not handled: silentoldconfig and external-deps. BR2_JLEVEL is not relevant for those, but other command- line overridden options may be. However, this hasn't changed from before commit 916e614b so I guess it's OK.
--- Makefile | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
Makefile +7 -5
@@ -35,11 +35,6 @@ SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ ifneq ("$(origin O)", "command line") O := $(CURDIR)/output else -# Other packages might also support Linux-style out of tree builds -# with the O=<dir> syntax (E.G. BusyBox does). As make automatically -# forwards command line variable definitions those packages get very -# confused. Fix this by telling make to not do so. -MAKEOVERRIDES := # Strangely enough O is still passed to submakes with MAKEOVERRIDES # (with make 3.81 atleast), the only thing that changes is the output # of the origin function (command line -> environment).
@@ -155,6 +150,13 @@ else ifneq ($(filter-out $(nobuild_targets),$(MAKECMDGOALS)),) BR_BUILDING = y endif +# We call make recursively to build packages. The command-line overrides that +# are passed to Buildroot don't apply to those package build systems. In +# particular, we don't want to pass down the O=<dir> option for out-of-tree +# builds, because the value specified on the command line will not be correct +# for packages. +MAKEOVERRIDES := + # Include some helper macros and variables include support/misc/utils.mk
Signature · 1 line
2.9.3
PATCH 2/2 core: remove redundant "override O := $(O)"
The top-level Makefile contains an "override O := $(O)" statement that is purportedly required to make sure the O flag doesn't leak into the environment of sub-makes. However, since commit 173135d, there is already an "override O := ..." a few lines down. Therefore, the first override is redundant.
---
I haven't been able to reproduce the issue mentioned in the comment (tested by printing the value of $(O) in a dummy package) with make 4.1. I therefore removed the comment completely.
--- Makefile | 7 ------- 1 file changed, 7 deletions(-)
Makefile +0 -7
@@ -34,13 +34,6 @@ SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ # build by preventing it from being forwarded to sub-make calls. ifneq ("$(origin O)", "command line") O := $(CURDIR)/output -else -# Strangely enough O is still passed to submakes with MAKEOVERRIDES -# (with make 3.81 atleast), the only thing that changes is the output -# of the origin function (command line -> environment). -# Unfortunately some packages don't look at origin (E.G. uClibc 0.9.31+) -# To really make O go away, we have to override it. -override O := $(O) endif # Check if the current Buildroot execution meets all the pre-requisites.
Signature · 1 line
2.9.3
PATCH 2/2 core: remove redundant "override O := $(O)"
Quoted 7 lines · Arnout Vandecappelle (Essensium/Mind)
The top-level
Makefilecontains an "override O := $(O)" statement that is purportedly required to make sure the O flag doesn't leak into the environment of sub-makes. However, since commit 173135d, there is already an "override O := ..." a few lines down. Therefore, the first override is redundant.
Regards,
Signature · 1 line
Samuel
PATCH 1/2 core: don't reset MAKEOVERRIDES when re-entering make
In reply to Arnout Vandecappelle (Essensium/Mind)Quoted 20 lines · Arnout Vandecappelle (Essensium/Mind)
We reset MAKEOVERRIDES to avoid passing down variables that are overridden on the command line to the package build systems. Indeed, the variables overridden on the command line will be Buildroot variables and not relevant to the package build system. In particular the O option is used by some packages and the value passed in on the command line is plain wrong for the individual package.
However, in commit
916e614b, MAKEOVERRIDES was moved earlier and it was reset _before_ re-entering make in the cases when something has to be fixed up (incorrect umask, non-absolute paths in O or CURDIR). Therefore, if make is re-entered, any command line overrides are lost.This particularly bites the autobuilders, because they use O=<relative path> to specify the output directory, and they add BR2_JLEVEL=... to avoid starting too many jobs in parallel. The
BR2_JLEVELoverride is lost.Cc Samuel Martin <[email protected]>Cc Yann E. MORIN <[email protected]>
Quoted 6 lines
---
I have a little worry, because there are two other places where we re- enter top-level make and those are not handled: silentoldconfig and external-deps.BR2_JLEVELis not relevant for those, but other command- line overridden options may be. However, this hasn't changed from before commit916e614bso I guess it's OK.
Regards,
Signature · 1 line
Samuel
PATCH 1/2 core: don't reset MAKEOVERRIDES when re-entering make
Quoted 40 lines · Samuel Martin
Quoted 20 lines · Arnout Vandecappelle (Essensium/Mind)
We reset MAKEOVERRIDES to avoid passing down variables that are overridden on the command line to the package build systems. Indeed, the variables overridden on the command line will be Buildroot variables and not relevant to the package build system. In particular the O option is used by some packages and the value passed in on the command line is plain wrong for the individual package.
However, in commit
916e614b, MAKEOVERRIDES was moved earlier and it was reset _before_ re-entering make in the cases when something has to be fixed up (incorrect umask, non-absolute paths in O or CURDIR). Therefore, if make is re-entered, any command line overrides are lost.This particularly bites the autobuilders, because they use O=<relative path> to specify the output directory, and they add BR2_JLEVEL=... to avoid starting too many jobs in parallel. The
BR2_JLEVELoverride is lost.Cc Samuel Martin <[email protected]>Cc Yann E. MORIN <[email protected]>Quoted 6 lines
---
I have a little worry, because there are two other places where we re- enter top-level make and those are not handled: silentoldconfig and external-deps.BR2_JLEVELis not relevant for those, but other command- line overridden options may be. However, this hasn't changed from before commit916e614bso I guess it's OK.Reviewed-by Samuel Martin <[email protected]>Regards,
--
Samuel
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
PATCH 1/2 core: don't reset MAKEOVERRIDES when re-entering make
In reply to Arnout Vandecappelle (Essensium/Mind)Hello,
Quoted 26 lines · Arnout Vandecappelle (Essensium/Mind)
We reset MAKEOVERRIDES to avoid passing down variables that are overridden on the command line to the package build systems. Indeed, the variables overridden on the command line will be Buildroot variables and not relevant to the package build system. In particular the O option is used by some packages and the value passed in on the command line is plain wrong for the individual package.
However, in commit
916e614b, MAKEOVERRIDES was moved earlier and it was reset _before_ re-entering make in the cases when something has to be fixed up (incorrect umask, non-absolute paths in O or CURDIR). Therefore, if make is re-entered, any command line overrides are lost.This particularly bites the autobuilders, because they use O=<relative path> to specify the output directory, and they add BR2_JLEVEL=... to avoid starting too many jobs in parallel. The
BR2_JLEVELoverride is lost.Cc Samuel Martin <[email protected]>Cc Yann E. MORIN <[email protected]>---
I have a little worry, because there are two other places where we re- enter top-level make and those are not handled: silentoldconfig and external-deps.BR2_JLEVELis not relevant for those, but other command- line overridden options may be. However, this hasn't changed from before commit916e614bso I guess it's OK.
Quoted 3 lines
--- Makefile | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
Both applied, thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com