[oe] [PATCH] bitbake.conf: Fix OVERRIDES description (After pb's explanation)

[Phil Blundell]

On Thu, 2009-11-19 at 14:39 +0100, Martin Jansa wrote:
> +# You can use combination ie you can use '<foo>_arm_ramses' to override both '<foo>' and '<foo>_arm'.

This part is not universally true: again, it depends on the order of the
things in ${OVERRIDES}.  The comment as written there is probably true
for the example OVERRIDES but it is a bit misleading in general.

In your particular case, where you had MACHINE before TARGET_ARCH in
overrides, it so happens that stacking up overrides in that fashion is
the easiest way to work around the (arguably wrong) ordering of your
overrides and get the result you were looking for.  But, if the order of
OVERRIDES had been reversed, this trick would cease to work.

To expand a bit on my irc description, what's going on here is the
following:

In your original case you had (effectively)

OVERRIDES = local:ramses:arm

FOO = "1"
FOO_arm = "2"
FOO_ramses = "3"

and bitbake processes the overrides left to right, so it first collapses
FOO_ramses onto FOO (giving FOO = "3") but then also collapses FOO_arm
onto the same variable, overwriting the value that was assigned by the
second override and leaving FOO = "2".

In your modified case you now have FOO_arm_ramses = "3".  In this case
what happens is that bitbake firstly applies the "ramses" overrides and
collapses FOO_arm_ramses onto FOO_arm, leaving FOO = "1" (unchanged thus
far) and FOO_arm = "3".  Then, it moves to processing the "arm"
overrides, collapsing FOO_arm onto FOO and giving you FOO = "3".

All of this stuff is somewhat dependent on internal implementation
details of bitbake and I am not sure to what extent it is safe to assume
that the behaviour will always remain the same.  That'd probably be an
issue that should be addressed in the bitbake user manual if it isn't
already.

p.