[poky] [PATCH 1/1] curl: fix native dependency
Richard Purdie
rpurdie at linux.intel.com
Thu Dec 9 07:16:12 PST 2010
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
>
More information about the poky
mailing list