Re: RDEPENDS_${PN} and virtclass-native

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

On Wed, 2011-05-25 at 17:11 -0700, Chris Larson wrote:
> On Wed, May 25, 2011 at 5:00 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 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...
> 
> Just need to add another event at the appropriate place. I wonder
> where RecipeParsed fits into that ordering.

Of course its not that simple. I just discovered:

OVERRIDES = "z"
DEPENDS_prepend = "a "
DEPENDS = "b"
DEPENDS_z = "c"

d.update_data()
d.getVar("DEPENDS") gives "a c"
d.update_data()
d.getVar("DEPENDS") gives "c"

since the _prepend is lost after the update_data(), the _z override is
not and so the second call overwrites all of DEPENDS.

We've talked before how overrides should really renameVar, not just copy
contents. Obviously there are a lot of subtleties to this though and we
can't just switch due to backwards compatibility :/

Depending on the number of update_data() calls is truly horrible
behaviour though :(

Cheers,

Richard