[oe] Question about OVERRIDES precedence

[Phil Blundell]

On Thu, 2010-10-14 at 06:59 -0700, Chris Larson wrote:
> On Thu, Oct 14, 2010 at 6:23 AM, Koen Kooi <k.kooi at student.utwente.nl>wrote:
> > Isn't the definition covered in the bitbake docs? I'm in favour of
> > fixing bitbake instead working around it in OE.
> >
> 
> As far as I can tell:
> 1. The bitbake docs don't cover the ordering.
> 2. The behavior isn't a bug, it's a mismatch between OE's definition and
> bitbake's implementation, and bitbake has been this way since 2003.

Agreed.  And there is plenty of existing code in OE which depends on the
current ordering.  OE's bitbake.conf even has a big comment describing
the behaviour that it expects:

# Overrides are processed left to right, so the ones that are named later take precedence.
# You generally want them to go from least to most specific.
# 
# This means that an envionment variable named '<foo>_arm' overrides an
# environment variable '<foo>' (when ${TARGET_ARCH} is arm).
# an environment variable '<foo>_ramses' overrides '<foo>' but doesn't override
# '<foo>_arm' when ${MACHINE} is 'ramses'. 
# If you use combination ie '<foo>_arm_ramses', then '<foo>_arm_ramses' will override 
# '<foo>_arm' and then '<foo>' will be overriden with that value from '<foo>_arm'.
# And finally '<foo>_local' overrides anything, but with lowest priority.

So, changing the bitbake behaviour at this late stage seems like a very
bad idea.  If the documentation calls for something else then I think
the documentation should be fixed to match the reality, not vice versa.

p.