kernel-yocto: fix diffconfig/kernel_configme breakage
PATCH 1/1 kernel-yocto: fix diffconfig/kernel_configme breakage
The bbclass did the following:
do_diffconfig[depends] += "virtual/kernel:do_kernel_configme"
This clearly introduces a cross-kernel task dependency if the recipe inheriting this class isn't the preferred provider of virtual/kernel, which is obviously wrong, but further, will break the build if a kernel-yocto based kernel is parsed and not skipped, but virtual/kernel refers to
a non-kernel-yocto recipe, which would not have the do_kernel_configme task.
Work around this by adding the in-recipe task dep programmatically with bb.build.addtask when do_diffconfig exists.
--- meta/classes/kernel-yocto.bbclass | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +7 -1
@@ -263,6 +263,8 @@ do_kernel_configme() { echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config } +addtask kernel_configme after do_patch + python do_kernel_configcheck() { import re, string, sys
@@ -407,4 +409,8 @@ OE_TERMINAL_EXPORTS += "GUILT_BASE KBUILD_OUTPUT" GUILT_BASE = "meta" KBUILD_OUTPUT = "${B}" -do_diffconfig[depends] += "virtual/kernel:do_kernel_configme" +python () { + # If diffconfig is available, ensure it runs after kernel_configme + if 'do_diffconfig' in d: + bb.build.addtask('do_diffconfig', None, 'do_kernel_configme', d) +}
Signature · 1 line
1.8.3.4
Quoted 23 lines · Christopher Larson
The bbclass did the following:
do_diffconfig[depends] += "virtual/kernel:do_kernel_configme"This clearly introduces a cross-kernel task dependency if the recipe inheriting this class isn't the preferred provider of virtual/kernel, which is obviously wrong, but further, will break the build if a kernel-yocto based kernel is parsed and not skipped, but virtual/kernel refers to
a non-kernel-yocto recipe, which would not have thedo_kernel_configmetask.Work around this by adding the in-recipe task dep programmatically with bb.build.addtask when
do_diffconfigexists.Signed-off-by Christopher Larson <[email protected]>--- meta/classes/kernel-yocto.bbclass | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +0
-0
meta/classes/kernel-yocto.bbclass do_kernel_configme() { · line 267
Quoted 5 lines
meta/classes/kernel-yocto.bbclass +2
-0@@ -263,6 +263,8 @@ do_kernel_configme() { echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config } +addtask kernel_configme after do_patch +
linux-yocto.inc already has:
addtask kernel_configme before do_configure after do_patch
So we should be able to avoid adding the task to the class, right ? I suppose the task could move into the class, but it was always a per recipe include in the past, I just don't want any unintended issues to happen from the double task add.
meta/classes/kernel-yocto.bbclass OE_TERMINAL_EXPORTS += "GUILT_BASE KBUILD_OUTPUT" · line 416
Quoted 13 lines
meta/classes/kernel-yocto.bbclass +5
-1python do_kernel_configcheck() { import re, string, sys@@ -407,4 +409,8 @@ OE_TERMINAL_EXPORTS += "GUILT_BASE KBUILD_OUTPUT" GUILT_BASE = "meta" KBUILD_OUTPUT = "${B}" -do_diffconfig[depends] += "virtual/kernel:do_kernel_configme" +python () { + # If diffconfig is available, ensure it runs after kernel_configme + if 'do_diffconfig' in d: + bb.build.addtask('do_diffconfig', None, 'do_kernel_configme', d) +}
Thanks for the fixup!
Bruce
Quoted 7 lines
--
1.8.3.4_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 7 lines · Bruce Ashfield
meta/classes/kernel-yocto.bbclass do_kernel_configme() { · line 267
Quoted 2 lines · Christopher Larson
meta/classes/kernel-yocto.bbclass +2
-0+addtask kernel_configme after do_patch +linux-yocto.inc already has:
Quoted 7 lines
addtask
kernel_configmebeforedo_configureafterdo_patchSo we should be able to avoid adding the task to the class, right ? I suppose the task could move into the class, but it was always a per recipe include in the past, I just don't want any unintended issues to happen from the double task add.
It depends on whether there's a need to support the use of the class without the .inc. If not, there are probably a number of bits in the .inc that belong in the class :) But it's never harmful to have multiple addtask lines, it just adds the specified deps to the existing task. I just wanted to make sure one couldn't get into a state where do_diffconfig depends on a function which isn't a task, as I would expect (though couldn't say with 100% certainty) that bitbake would yell about that :)
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 19 lines · Chris Larson
Quoted 8 lines · Bruce Ashfield
meta/classes/kernel-yocto.bbclass do_kernel_configme() { · line 267
Quoted 2 lines · Christopher Larson
meta/classes/kernel-yocto.bbclass +2
-0+addtask kernel_configme after do_patch +linux-yocto.inc already has:
Quoted 6 lines
addtask
kernel_configmebeforedo_configureafterdo_patchSo we should be able to avoid adding the task to the class, right ? I suppose the task could move into the class, but it was always a per recipe include in the past, I just don't want any unintended issues to happen from the double task add.
Quoted 7 lines
It depends on whether there's a need to support the use of the class without the .inc. If not, there are probably a number of bits in the .inc that belong in the class :) But it's never harmful to have multiple addtask lines, it just adds the specified deps to the existing task. I just wanted to make sure one couldn't get into a state where
do_diffconfigdepends on a function which isn't a task, as I would expect (though couldn't say with 100% certainty) that bitbake would yell about that :)
Works for me. Thanks for the explanation.
Bruce
Quoted 6 lines
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"