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

[Qing He]

On Tue, 2010-12-07 at 20:37 +0800, Richard Purdie wrote:
> On Tue, 2010-12-07 at 15:55 +0800, Tian, Kevin wrote:
> > >From: Richard Purdie [mailto:rpurdie at linux.intel.com]
> > >http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/bitbake&id=c77410305f
> > >e736aa195ce720c8317b39da057052
> > 
> > yes, that looks a clear fix.
> 
> In the absence of Chris saying no, I've merged this into Poky so it
> doesn't get lost.

Thank you for the fix, I've been looking the smart data section
recently, and the rationale becomes much clearer to me.


However, the following case still has some confusion:

FOO = "A"
FOO_append = "B"
FOO_virtclass-native = "C"

when in virtclass-native, the output is simply "C", instead of "CB"
as I expected

> 
> > 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. :-)
> 
> Right, there is just the question of ordering.
> 
> > 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.
> 
> I think its not something we should worry too much about, just something
> to be aware of.

There is some occasion where the ordering may matter, for example, CFLAGS
(and some other command line options). But even this may avoid the need of
predicatable order if we are careful.

> 
> I do still think we should support FOO_append_OVERA_OVERB_OVERC though
> perhaps we should leave a bug open on that?

This question also arose when I read the code, then I realize that
FOO_append_OVERA_OVERB_OVERC doesn't work in current design. Previously
I expected something like a staged handling, i.e. peeling off the
append/prepend first, and then handling override, but actually they are
not that loosely coupled.

That said, it seems supporting multiple overrides in append is still
ok, I tried to sketch a patch as follow, seems work for
FOO_append_virtclass-native_qemux86 = "C"

---
diff --git a/bitbake/lib/bb/data_smart.py b/bitbake/lib/bb/data_smart.py
index c8cd8f8..116ea10 100644
--- a/bitbake/lib/bb/data_smart.py
+++ b/bitbake/lib/bb/data_smart.py
@@ -160,9 +160,15 @@ class DataSmart:
                 for append in appends:
                     keep = []
                     for (a, o) in self.getVarFlag(append, op) or []:
-                        if o and not o in overrides:
-                            keep.append((a ,o))
-                            continue
+                        if o:
+                            applicable = 1
+                            for override in o.split('_'):
+                                if not override in overrides:
+                                    applicable = 0
+                                    break
+                            if not applicable:
+                                keep.append((a ,o))
+                                continue
 
                         if op is "_append":
                             sval = self.getVar(append, False) or ""
---


Thanks,
Qing