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

[Tian, Kevin]

>From: Chris Larson
>Sent: Monday, November 29, 2010 11:25 PM
>
>On Mon, Nov 29, 2010 at 5:25 AM, Richard Purdie <rpurdie at linux.intel.com> 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...
>
>Hmm, this isn't what I'd expect either.  It's certainly not what was
>originally intended -- _append_<foo> and _prepend_<foo> were always
>supposed to act like normal _append/_prepend, just conditional ones.

I guess it's related to below lines (from finalize()):

                    # maybe the OVERRIDE was not yet added so keep the append
                    if (o and o in overrides) or not o:
                        self.delVarFlag(append, "_append")
                    if o and not o in overrides:
                        continue

FOO_append = "B" is parsed into ("B", NONE)
FOO_append_virtclass-native = "C" is parsed into ("C", virtclass-native)

If ("C", virtclass-native) is enumerated first, the result is desired: "C" is appended
to FOO with ("B", NONE) simply removed.

If ("B", NONE) is enumerated first, then the rest appendixes are removed too which
is not desired.

The net effect is that the 1st appendix always takes effect over the rest unless it
has an override which hasn't been found yet.

Besides this problem, there's also no consideration about override priority. It can't
handle multiple overrides on same FOO_append.

To solve it, we still need to iterate override list from highest priority to lowest end,
and then choose the value from the one firstly matching an override. My remote 
machine is down now and thus unable to verify it though.

Thanks
Kevin