bitbake.conf, module.bbclass: Support opting out of legacy EXTRA_OEMAKE

meta/conf/bitbake.conf export BUILD_STRIP = "${BUILD_PREFIX}strip" · line 481

Quoted 6 lines · Mike Crowe

export MAKE = "make"

meta/conf/bitbake.conf +2 -1

-EXTRA_OEMAKE = "-e MAKEFLAGS="
+EXTRA_OEMAKE_LEGACY = "-e MAKEFLAGS="
+EXTRA_OEMAKE = "${EXTRA_OEMAKE_LEGACY}"

may be this should be a weak assignment.

Quoted 8 lines

meta/conf/bitbake.conf export BUILD_STRIP = "${BUILD_PREFIX}strip" · line 481

Quoted 6 lines

export MAKE = "make"

meta/conf/bitbake.conf +2 -1

-EXTRA_OEMAKE = "-e MAKEFLAGS="
+EXTRA_OEMAKE_LEGACY = "-e MAKEFLAGS="
+EXTRA_OEMAKE = "${EXTRA_OEMAKE_LEGACY}"

may be this should be a weak assignment.

That's the habit, but this is bitbake.conf. Anything a recipe does will be long after this.

Give recipes and classes the ability to opt out of EXTRA_OEMAKE containing the legacy value without removing other recipe-specific or local additions.

The default value of EXTRA_OEMAKE="-e MAKEFLAGS=" is unfortunate. It causes breakage and unintended behaviour in various recipes.

It is particularly toxic when variables are passed on the command line to make since they then don't survive calling into a submake.

In particular this breaks building modules when LD=gold since the overridden LD=${KERNEL_LD} is lost by the time the kernel's Makefile is invoked.

This solution isn't pretty either, but it may be a good small first step towards a future utopia where EXTRA_OEMAKE needn't contain "-e MAKEFLAGS=" by default at all.

Signed-off-by Mike Crowe <[email protected]>

Acked-by Phil Blundell <[email protected]>

---
 meta/classes/module.bbclass | 4 ++++
 meta/conf/bitbake.conf      | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

meta/classes/module.bbclass +4 -0

index 0952c0c..4913aac 100644
@@ -4,6 +4,10 @@ addtask make_scripts after do_patch before do_compile
 do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
 do_make_scripts[depends] += "virtual/kernel:do_shared_workdir"
 
+# -e MAKEFLAGS= is toxic when building modules since it will cause
+# none of the variables passed to make on the command line to make it
+# through to submakes.
+EXTRA_OEMAKE_LEGACY = ""
 EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
 
 module_do_compile() {

meta/conf/bitbake.conf +2 -2

index 06971da..93ab02a 100644
@@ -477,7 +477,8 @@ export BUILD_STRIP = "${BUILD_PREFIX}strip"
 export BUILD_NM = "${BUILD_PREFIX}nm"
 
 export MAKE = "make"
-EXTRA_OEMAKE = "-e MAKEFLAGS="
+EXTRA_OEMAKE_LEGACY = "-e MAKEFLAGS="
+EXTRA_OEMAKE = "${EXTRA_OEMAKE_LEGACY}"
 EXTRA_OECONF = ""
 export LC_ALL = "C"
 
--

2.1.4

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 3 lines · Mike Crowe

Give recipes and classes the ability to opt out of EXTRA_OEMAKE containing the legacy value without removing other recipe-specific or local additions.

Isn't this possible already from within a recipe or class by using

EXTRA_OEMAKE = ...

instead of

EXTRA_OEMAKE += ...

ie what autotools.bbclass, kernel.bbclass and many recipes do already.

For the specific case of module.bbclass, changing the EXTRA_OEMAKE assignment to '=' might require some recipes to be tweaked to so that they "inherit module" before adding their own options to EXTRA_OEMAKE, but it seems like a cleaner solution?

Quoted 11 lines · Andre McCurdy

Quoted 3 lines · Mike Crowe

Give recipes and classes the ability to opt out of EXTRA_OEMAKE containing the legacy value without removing other recipe-specific or local additions.

Isn't this possible already from within a recipe or class by using

EXTRA_OEMAKE = ...

instead of

Quoted 8 lines

EXTRA_OEMAKE += ...

ie what autotools.bbclass, kernel.bbclass and many recipes do already.

For the specific case of module.bbclass, changing the EXTRA_OEMAKE assignment to '=' might require some recipes to be tweaked to so that they "inherit module" before adding their own options to EXTRA_OEMAKE, but it seems like a cleaner solution?

It would be, but I was afraid of what I might break. I suspect that there are many unseen third-party and local recipes that inherit module.bbclass.

It would be great to get to the point that EXTRA_OEMAKE is empty by default but I imagine that the experts are already aware of the difficulties with doing this which is why the current value has lasted so long.

Mike.

Signature · 4 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 16 lines · Mike Crowe

Quoted 15 lines · Andre McCurdy

Quoted 3 lines · Mike Crowe

Give recipes and classes the ability to opt out of EXTRA_OEMAKE containing the legacy value without removing other recipe-specific or local additions.

Isn't this possible already from within a recipe or class by using

EXTRA_OEMAKE = ...

instead of

EXTRA_OEMAKE += ...

ie what autotools.bbclass, kernel.bbclass and many recipes do already.

Quoted 7 lines

Quoted 4 lines

For the specific case of module.bbclass, changing the EXTRA_OEMAKE assignment to '=' might require some recipes to be tweaked to so that they "inherit module" before adding their own options to EXTRA_OEMAKE, but it seems like a cleaner solution?

It would be, but I was afraid of what I might break. I suspect that there are many unseen third-party and local recipes that inherit

module.bbclass.

Quoted 2 lines

It would be great to get to the point that EXTRA_OEMAKE is empty by

default

Quoted 2 lines

but I imagine that the experts are already aware of the difficulties with doing this which is why the current value has lasted so long.

Is it really good goal to get rid of "-e"?

I know that the environment used in bitbake tasks is already well defined and controlled, but I still find a bit more control with -e to be useful in many cases.

I know I'll be able to return -e where useful, but what's the main advantage of removing it from default?

Quoted 31 lines · Martin Jansa

Quoted 16 lines · Mike Crowe

Quoted 15 lines · Andre McCurdy

Quoted 3 lines · Mike Crowe

Give recipes and classes the ability to opt out of EXTRA_OEMAKE containing the legacy value without removing other recipe-specific or local additions.

Isn't this possible already from within a recipe or class by using

EXTRA_OEMAKE = ...

instead of

EXTRA_OEMAKE += ...

ie what autotools.bbclass, kernel.bbclass and many recipes do already.

Quoted 7 lines

Quoted 4 lines

For the specific case of module.bbclass, changing the EXTRA_OEMAKE assignment to '=' might require some recipes to be tweaked to so that they "inherit module" before adding their own options to EXTRA_OEMAKE, but it seems like a cleaner solution?

It would be, but I was afraid of what I might break. I suspect that there are many unseen third-party and local recipes that inherit

module.bbclass.

Quoted 2 lines

It would be great to get to the point that EXTRA_OEMAKE is empty by

default

Quoted 2 lines

but I imagine that the experts are already aware of the difficulties with doing this which is why the current value has lasted so long.

Quoted 8 lines

Is it really good goal to get rid of "-e"?

I know that the environment used in bitbake tasks is already well defined and controlled, but I still find a bit more control with -e to be useful in many cases.

I know I'll be able to return -e where useful, but what's the main advantage of removing it from default?

The original goal of the default EXTRA_OEMAKE was to let us keep our recipes as minimal as possible and have as many "Just Work" out of the box as possible. It succeeded in this goal. The problem is the corner cases, and more importantly, it encourages people creating recipes for custom make-based buildsystems to just try building it and hack at it till it works, rather than reading the makefiles, determining which variables to pass in, in what form, and customizing EXTRA_OEMAKE to explicitly pass what's needed in the appropriate ways.

That's my biggest concern with it, other than the aforementioned occasional breakage. It's implicit, automatic, rather than explicit, and tacitly encourages ignorance of the buildsystem in question.

It would be great to get to the point that EXTRA_OEMAKE is empty by default but I imagine that the experts are already aware of the difficulties with doing this which is why the current value has lasted so long.

Quoted 3 lines · Mike Crowe

It would be great to get to the point that EXTRA_OEMAKE is empty by default but I imagine that the experts are already aware of the difficulties with doing this which is why the current value has lasted so long.

I had a go at this. Fewer recipes than I expected seem to be affected.

With bitbake.conf containing EXTRA_OEMAKE = "", the following recipes needed to be changed to explicitly set EXTRA_OEMAKE = "-e MAKEFLAGS=":

meta/recipes-bsp/pciutils/pciutils_3.3.1.bb
meta/recipes-connectivity/openssl/openssl.inc
meta/recipes-core/busybox/busybox.inc

meta/recipes-devtools/perl/perl_5.22.0.bb

for core-image-minimal to build successfully[1].

I tried core-image-sato but got stuck when apr-util-native wouldn't compile for me[2], even with stock master.

So, perhaps the situation isn't quite as bad as I feared and it might be possible to change the default value of EXTRA_OEMAKE.

Mike.

[1] I suspect that perl isn't required by core-image-minimal. That list is my complete set of changes from trying to get core-image-sato to build.

[2] x86_64-linux-libtool: compile: unable to infer tagged configuration --
_______________________________________________
Openembedded-core mailing list [email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core