[OE-core] RDEPENDS_${PN} and virtclass-native

[Khem Raj]

On Wed, May 25, 2011 at 4:02 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2011-05-25 at 18:01 +0100, Phil Blundell wrote:
>> By way of displacement activity to avoid actually fixing my perl
>> compilation problem, it occurred to me to investigate why perl was
>> getting dragged into a micro-base-image build in the first place.  The
>> culprit turns out to be imake, which does:
>>
>> RDEPENDS_${PN} = "perl xproto"
>>
>> and is then BBCLASSEXTENDed to imake-native (which in turn is pulled in
>> by way of prelink-native and transfig-native).
>>
>> Now, leaving aside the question of whether it is reasonable for prelink
>> to be depending on transfig, it is clearly wrong for the -native version
>> of imake to be depending on perl.  It seems that native.bbclass makes
>> some effort to rewrite plain RDEPENDS to the -native version, but it
>> doesn't apply the same tactics to RDEPENDS_${PN} or any such.  (And, in
>> fact, rewriting plain RDEPENDS is probably futile since few if any
>> recipes are going to be setting it.)
>>
>> Obviously I can fix this by just setting RDEPENDS_virtclass-native in
>> the recipe, and that's what I've done in my local tree.  But I wonder if
>> a better solution would be for native.bbclass to be slightly more
>> adventurous about rewriting these things for itself.
>
> 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.
>


while we are talking about fixing native.bbclass on a different
tangent. I think overrides is another thing we need to fix
specially libc overrides. When a recipe inherits
native,cross, or nativesdk then we have to change
the libc override to be always libc-glibc (unless one
is building on a box which is running uclibc)

otherwise we end up with slightly different native
packages and sstate can not use them effectively
it keeps rebuilding and refreshing everytime.

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>