Re: RDEPENDS_${PN} and virtclass-native

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2011-05-26 at 00:02 +0100, Richard Purdie wrote:
> I think we need to fix native.bbclass. I dread to think what this is
> doing to the dependency tree at present. We did remove most references
> to RDEPENDS directly so I think that makes this a high priority to fix.
> 
> I'd note that the rewriting code is fraught with ordering/expansion
> issues which is why that code plays games with the variables like it
> does.
> 
> DEPENDS is horrible and it looks like we needed to do something similar
> for RDEPENDS. Better solutions to the ordering problems would be very
> welcome. It problem was the use of DEPENDS_prepend in places iirc.

I just reminded myself of the problem with DEPENDS.

Imagine the recipe says:

DEPENDS = "foo"
inherit autotools

Behind the scenes, autotools (amongst other thinsg) does a:

DEPENDS_prepend = "autoconf-native"

The trouble comes when you try:

DEPENDS_virtclass-native = ""

since you want to drop the foo dependency. The dependencies being added
by autotools.bbclass are still wanted but they get overwritten. At this
point I had to remember bitbake's finalize ordering. It does:

finalize()
<call anonymous python>
finalize()

The first call to finalize() expands the _prepend/_append before we see
them. We then lose the ability to see what was added though the classes
vs. what was in the recipe. The second finalize can then only clobber
the data.

If we could get our function called before the first finalize(), we
would remove the need to play the games we do which is looking very very
attractive.

I suspect its time to extend the anonymous python to indicate more
specifically when it would like to be run...

Cheers,

Richard