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

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello Richard,

Tuesday, January 8, 2008, 1:14:16 PM, you wrote:

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

  Like module_autoload. Has been on my list for a long time. The
problem, it (ab)uses override-like syntax to do something completely
different. It actually tries to emulate dictionary with sh-like
syntax. So, when it says

module_autoload_evdev = "evdev"

, in developed language it would be module_autoload["evdev"] = "evdev".

  So, it's kinda special case, that's why I didn't get around to doing
something about it, but we probably should, because it's inconsistent.

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

  I also think that such tests are not really effective...

> Cheers,

> Richard




> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com