[poky] [PATCH 1/1] curl: fix native dependency

Tian, Kevin kevin.tian at intel.com
Sun Dec 5 01:43:30 PST 2010


>From: He, Qing
>Sent: Tuesday, November 30, 2010 9:44 AM
>
>On Mon, 2010-11-29 at 20:25 +0800, Richard Purdie wrote:
>> On Sun, 2010-11-28 at 22:53 -0700, Chris Larson wrote:
>> > On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian at intel.com> wrote:
>> > > This also confuses me a bit. When virtclass-native is expanded,
>EXTRA_OECONF_append
>> > > is simply a variable. In that case the expanded value should override the 1st
>assignment
>> > > of EXTRA_OECONF_append, and then we should get:
>> > >
>> > > EXTRA_OECONF_append = " --without-gnutls "
>> > >
>> > > and then that's what we expect.
>> > >
>> > > I guess I may still overlook something here, and really appreciate your explanation
>> > > on the whole flow which is helpful. :-)
>> >
>> > No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
>> > operations, not part of the name.  The value gets set aside in a list
>> > of appends for that variable.  One _append cannot override/replace
>> > another on the same variable, its always cumulative.
>>
>> Right.
>>
>> Interestingly though, if I add this to curl*.bb:
>>
>> FOO = "A"
>> FOO_append = "B"
>> FOO_append_virtclass-native = "C"
>>
>> and then "bitbake curl-native -e | grep FOO" (he recipe has a
>> BBCLASSEXTEND native) what should I see?
>>
>> I see FOO = "AB" which is not what I thought it would do...
>
>This is very interesting, I didn't see "AC" when preparing the patch
>so went the other way. After seeing your experiment, I also tried this:
>
>FOO = "A"
>FOO_virtclass-native = "B"
>FOO_virtclass-native_append = "C"
>
>Then for curl-native, FOO = "BC", and there is an explicit variable
>FOO_virtclass-native = "BC", this does not exist in RP's test.
>So it's more clear to me now what "*_append is never a variable" means.
>
>
>However, the gut feeling is that this construct introduces some
>inconsistency. If "_append" is never a variable, but "_virtclass-native"
>is, how is bitbake supposed to handle FOO_append_virtclass-native and
>translate it into a FOO_virtclass-native variable?

See finalize() in data_smart.py. the override for _append/_prepend is handled
specifically which is different from normal overrides tweak. There's some bug
though which I described in another mail. In a nutshell, FOO_append_virtclass-native
is parsed into a flag for FOO, with name as 'append', the value as ("C", virtclass-native).
when finalize() handles _append/_prepend, "C" is appended to FOO directly and
thus there's no FOO_virtclass-native being generated in the middle.

I'm not sure whether FOO_virtclass-native_append = "C" is a valid usage though.
At least it's not in current design. As in your example, finally a new variable
is created (FOO_virtclass-native) with value as 'BC'. Though override is handled
before _append/_prepend, finalize() may be invoked multiple times. The 1st time
will give you:

FOO = "A"
FOO_virtclass-native = "BC"

and then later invocations will get:

FOO = "BC"
FOO_virtclass-native = "BC"

This though gives a right result in the end, it's dangerous as its value is volatile
in the middle.

>
>To be more specific, if append is to be handled earlier than virtclass,
>FOO may not be able to be evaluated at the time when append/prepend is
>processed, as the following test case:
>
>FOO = "A"
>FOO_virtclass-native = "B"
>FOO_append = "C"
>FOO_append_virtclass-nativesdk = "D"
>
>How should it be handled?
>

The expected result will be:

a) if you build pkgname, you'll get FOO = "AC" as the effect of _append

b) if you build pkgname-native, you'll get FOO = "BC" because overrides are
handled before _append/_prepend

a) if you build pkgname-nativesdk, you'll get FOO = "AD" because override
appendix is used

Thanks
Kevin



More information about the poky mailing list