Patchwork kernel-yocto.bbclass: Force do_diffconfig depends to ${PN}

login
register
mail settings
Submitter Nathan Rossi
Date Feb. 21, 2014, 5:37 a.m.
Message ID <98dd26f3-a46a-451d-a445-93e8b1862377@VA3EHSMHS040.ehs.local>
Download mbox | patch
Permalink /patch/67083/
State New
Headers show

Comments

Nathan Rossi - Feb. 21, 2014, 5:37 a.m.
Commit 07e59b5ff659bde6e6a60c4781c0a2deb406c667 added the task
dependency of 'virtual/kernel:do_kernel_configme' for the do_diffconfig
task. This dependency is only valid for linux recipes that inherit
kernel-yocto (e.g. linux-yocto), however due to virtual/kernel being a
virtual dependency it may not be providing a kernel which inherits
kernel-yocto in which case the do_kernel_configme task might not exist.

In the case where virtual/kernel is provided by a non kernel-yocto
recipe an error is thrown in relation to the dependency, e.g.

	ERROR: Task do_diffconfig in linux-yocto-tiny_3.8.bb depends
	upon non-existent task do_kernel_configme in linux.bb

Changing the dependency to use '${PN}:do_kernel_configme' forces the
dependency to only depend on the recipe which inherits
kernel-yocto.bbclass.

Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
---
This effects the linux-xlnx recipe in meta-xilinx, causing the above error to be
shown when building the linux-xlnx recipe with PREFERRED_PROVIDER_virtual/kernel
 = "linux-xlnx".

I am not sure if this change is entirely correct, there may be a reason for the
dependence on virtual/kernel that I am not aware of, In which case I have cc'd
all parties involved in the commit which added this dependency.

I did however do a test of the diffconfig feature with this dependency change
in place, no regressions are apparent with the linux-yocto recipe.
---
 meta/classes/kernel-yocto.bbclass |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Chris Larson - Feb. 28, 2014, 9:26 p.m.
On Thu, Feb 20, 2014 at 10:37 PM, Nathan Rossi <nathan.rossi@xilinx.com>wrote:

> Commit 07e59b5ff659bde6e6a60c4781c0a2deb406c667 added the task
> dependency of 'virtual/kernel:do_kernel_configme' for the do_diffconfig
> task. This dependency is only valid for linux recipes that inherit
> kernel-yocto (e.g. linux-yocto), however due to virtual/kernel being a
> virtual dependency it may not be providing a kernel which inherits
> kernel-yocto in which case the do_kernel_configme task might not exist.
>
> In the case where virtual/kernel is provided by a non kernel-yocto
> recipe an error is thrown in relation to the dependency, e.g.
>
>         ERROR: Task do_diffconfig in linux-yocto-tiny_3.8.bb depends
>         upon non-existent task do_kernel_configme in linux.bb
>
> Changing the dependency to use '${PN}:do_kernel_configme' forces the
> dependency to only depend on the recipe which inherits
> kernel-yocto.bbclass.
>
> Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
>

It looks like any machine which has a kernel-yocto recipe parsed and not
skipped, but whose virtual/kernel is not kernel-yocto, will see this. The
beagleboard machine gets build breaks due to this, for example, if you
include both meta-yocto-bsp and meta-ti in your BBLAYERS.

This is a little weird, both the original implementation and this patch. We
already have an API for adding internal inter-task dependencies, it's
called 'addtask' ;) That said, I think I can see the intent, but there are
a couple of alternatives, and I really don't like either this or the
original version, personally.

I'm guessing that the idea was to add a dependency from diffconfig to
kernel_configme whether or not diffconfig even exists, in order to be able
to support a use case where kernel-yocto is inherited but cml1 is not, but
I'd question the validity of such a use case, personally. I think either we
should consider one of these options:

    1) Programmatically add the dependency with bb.build.addtask based on
the availability of do_diffconfig
    2) Use addtask to express the dependency in linux-yocto.inc, where
do_kernel_configme gets added as a task. Having do_diffconfig depend on
do_kernel_configme for a recipe that doesn't include linux-yocto.inc would
result in breakage anyway unless they explicitly addtask do_kernel_configme
in that recipe.

Thoughts?

Does anyone know if the intent was that kernel-yocto.bbclass would be
useful without cml1?
Chris Larson - Feb. 28, 2014, 9:33 p.m.
On Fri, Feb 28, 2014 at 2:26 PM, Chris Larson <clarson@kergoth.com> wrote:

> I'm guessing that the idea was to add a dependency from diffconfig to
> kernel_configme whether or not diffconfig even exists, in order to be
> able to support a use case where kernel-yocto is inherited but cml1 is not,
> but I'd question the validity of such a use case, personally. I think
> either we should consider one of these options:
>
>     1) Programmatically add the dependency with bb.build.addtask based on
> the availability of do_diffconfig
>

https://gist.github.com/kergoth/9280305 shows what this one looks like,
which is the most versatile, but does add additional processing at the end
of parse time, though not much. I think this is probably our best bet as it
still supports the use cases implied by the way kernel-yocto.bbclass and
linux-yocto.inc are structured.


>     2) Use addtask to express the dependency in linux-yocto.inc, where
> do_kernel_configme gets added as a task. Having do_diffconfig depend on
> do_kernel_configme for a recipe that doesn't include linux-yocto.inc would
> result in breakage anyway unless they explicitly addtask do_kernel_configme
> in that recipe.
>

https://gist.github.com/kergoth/9280352 shows this version, which would
mean that anyone using kernel-yocto.bbclass and cml1.bbclass but not
linux-yocto.bbclass wouldn't get the diffconfig -> kernel_configme
dependency set

Patch

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index fab5d4c..ad80621 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -412,4 +412,4 @@  OE_TERMINAL_EXPORTS += "GUILT_BASE KBUILD_OUTPUT"
 GUILT_BASE = "meta"
 KBUILD_OUTPUT = "${B}"
 
-do_diffconfig[depends] += "virtual/kernel:do_kernel_configme"
+do_diffconfig[depends] += "${PN}:do_kernel_configme"