[oe] Metadata Q/A (was: Another weird case of PACKAGES_DYNAMIC and task deps, it seems)

[Richard Purdie]

On Mon, 2008-01-07 at 23:52 +0100, Michael 'Mickey' Lauer wrote:
> Richard Purdie wrote:
> > On Mon, 2008-01-07 at 20:44 +0000, Richard Purdie wrote:
> >> My money is on:
> >> 
> >> DEPENDS_collie += "bc-native"
> >> 
> >> in linux-rp.inc. Try removing that...
> 
> > Confirmed and fixed in 00610b176af0e4f4563f78fb71dc1219c777d13e.
> 
> > Let me stress once again, += and overrides do not do what you expect. It
> > adds "bc_native" to the variable named "DEPENDS_collie", not "DEPENDS".
> 
> > DEPENDS_append_collie = " bc-native" 
> 
> > is a very different thing and corrects this problem...
> 
> Can we
> 
> a) forbid variable assignment to foo_bar in general (when bar is not
> in {append, prepend, <override>} ?

Like SRC_URI = "" ?

We have a lot of variables with _ in the names since it generally looks
better than SRC-URI. I think we do need a policy on this though since it
will:

a) Bite us at some point
b) It slows bitbake down (although I've never confirmed that)

I actually have a idea rolling around the back of my head here. All our
overrides are lowercase (I think). A lot of our variable names are upper
case. I'm wondering if we'd get a speedup from allowing only lowercase
overrides since bitbake could tell from inspection that "URI" would
never be an override.

This lets us keep the large number of uppercase variables with _ in the
name and we can conceivably rename the lowercase ones since there are a
lot less of them.

> b) have an extra Q/A class that scans the metadata for those kinds of
> problems?

If and only if we have some rules that tell us what the valid cases are.
We'd probably need an exhaustive list of permitted overrides too.

Cheers,

Richard