[oe] Question about OVERRIDES precedence

[Chris Larson]

On Wed, Oct 13, 2010 at 1:29 PM, Maupin, Chase <chase.maupin at ti.com> wrote:

> I have been looking into the OVERRIDES setting and it appears to me that
> the OVERRIDES are being handled in least specific to most specific order.
>  Meaning that if I have an override for a particular machine set that it has
> a lower priority than the override for a distro.
>
> My OVERRIDES variable is actually set to evaluate:
> #
> OVERRIDES=local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}:${FEED_ARCH}:${SOC_FAMILY}:libc-glibc${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}
>
> Which translates in my build to:
>
> OVERRIDES="local:am37x-evm:angstrom:linux-gnueabi:arm:build-linux:fail-fast:pn-task-arago-toolchain-tisdk-multimedia-host:armv7a:omap3:libc-glibc:thumb-interwork"
>
> I would expect that if I set an override for am37x-evm that this MACHINE
> specific override should trump the DISTRO specific override or the
> SOC_FAMILY override.
>
> Likewise I would expect that the local override would have the highest
> precedence because I am trying to override something specifically for my
> local copy and that the "thumb-interwork" override would have the lowest
> precedence.
>
> Is my expectation incorrect?
>

Yes, your expectation is correct.  OVERRIDES is intended to essentially give
us a layering mechanism for the metadata, ensuring that the most specific
available information is always used.  So machine should always have higher
priority than target architecture, for example, and local is highest of all.

I assume in your testing you've found that this is not behaving the way it
should?

 If so then can we just reverse the list of overrides in the update_data
> method of <bitbake>/lib/bb/data.py, around line 500 in my version.  My
> bitbake is on version 1.10.  In the master this would be in the finalize
> function of the DataSmart class.
>

I think you're correct, yes, from a quick re-read of the code -- it seems to
be evaluating them from highest to lowest priority, so the latter may
override the former, unless I'm missing something.  This seems like it would
have been an obvious thing -- if overrides aren't working as intended, I'd
have expected it to have been caught before now :\  This code hasn't changed
since the original implementation, it seems -- see
d8b28d544cd7ba8e9c303e72f8ce2ed04ee71b3a.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics