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

[Tian, Kevin]

>From: Richard Purdie [mailto:rpurdie at linux.intel.com]
>Sent: Monday, December 06, 2010 9:04 AM
>
>On Sun, 2010-12-05 at 17:32 +0800, Tian, Kevin wrote:
>> >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:
>> >> 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.
>
>This is what I'd have expected too.
>
>> 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
>
>Correct, it is these lines that are the problem.
>
>> 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.
>
>This is exactly the problem.
>
>> 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.
>
>Right. I had a play with the code and can confirm a patch as follows
>fixes this problem. I've also made it warn when it finds code that would
>effect behaviour. For Poky its throwing up a warning about EXTRA_OEMAKE
>but its actually fine as whilst there is an unexpanded override, there
>is never any _append or _prepend to trigger this bug (the warning can
>show false positives). It would be nice to see if OE is suffering from
>this problem anywhere before we accept this fix into bitbake upstream.
>I'll also remove this error before this goes into Poky.
>
>http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/bitbake&id=c77410305f
>e736aa195ce720c8317b39da057052

yes, that looks a clear fix.

>
>> 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.
>
>This is a good point but its not a simple one :)
>
>FOO = "A"
>FOO_append_OVERA = "B"
>FOO_append_OVERB = "C"
>
>could result in ABC or ACB depending on whether OVERA was added to
>OVERRIDES late on. There isn't much we can probably do about that
>though.
>
>FOO = "A"
>FOO_append_OVERA_OVERB = "B"
>FOO_append_OVERB_OVERA = "C"
>
>plain won't work at present if I read the code correctly. I'm not sure
>there is an ordering constraint here though as "ABC" is the correct
>answer and either an OVERRIDE is appended or it isn't and priority isn't
>an issue?

Actually my original thought was a little bit different. Atm I thought that only one
appendix should take effect, i.e:

FOO = "A"
FOO_append_OVERA = "B"
FOO_append_OVERB = "C"

If OVERB is higher priority than OVERA, the result would be "AC" then.

Now obviously my earlier thought is wrong. Every _append appends a new
value if the override is valid. :-)

I also thought that there's no ordering constraint in this design. either "A B C"
or "A C B" could work, unless the appendix itself has order constraint, say 
a patch sequence. But I'm not sure whether there's real usage and we need
to handle it or not.

>
>Chris: Any thoughts on any of this?
>
>Cheers,
>
>Richard
>

Thanks
Kevin