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

[Richard Purdie]

On Wed, 2010-12-08 at 11:12 +0800, Qing He wrote:
> 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

This is a tricky one. It would be interesting to see if this applies
with other overrides such as MACHINE. The reason I say that is the way
the virtclass-native override is added (see native.bbclass).

> > > 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.

Right, there are cases it will matter like patch application but we just
need to be sensitive to that when writing metadata.

> > 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.

I'd also actually thought the code worked differently to how it does
before I looked at it!

> 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"

This looks reasonable. In python you should used "True" and "False"
instead of "1" and "0".

I've just mentally been asking myself what if this was a variable like
SRC_URI where the name contains an "_" but since we don't allow
overrides to contain the character, I think we're safe.

I also think you can simplify the logic slightly to be:

+                            for override in o.split('_'):
+                                if not override in overrides:
+                                    keep.append((a ,o)) 
+                                    continue

?

Cheers,

Richard

> ---
> 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
>