[oe] Question about OVERRIDES precedence

Maupin, Chase chase.maupin at ti.com
Wed Oct 13 21:30:17 UTC 2010


> -----Original Message-----
> From: openembedded-devel-bounces at lists.openembedded.org
> [mailto:openembedded-devel-bounces at lists.openembedded.org] On Behalf Of
> Chris Larson
> Sent: Wednesday, October 13, 2010 4:22 PM
> To: openembedded-devel at lists.openembedded.org
> Subject: Re: [oe] Question about OVERRIDES precedence
> 
> 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.

Chris,

That was my thought as well but I can consistently cause this issue.  I have tested a quick change that seems to fix the issue by reversing the list before it is used in the for loop.  My change was:

diff --git a/lib/bb/data.py b/lib/bb/data.py
index f424ac7..b3bd8b9 100644
--- a/lib/bb/data.py
+++ b/lib/bb/data.py
@@ -480,7 +480,7 @@ def update_data(d):
     #print "Append/Prepend %s" % d._special_values
     #print "Overrides      %s" % d._seen_overrides
 
-    overrides = (getVar('OVERRIDES', d, 1) or "").split(':') or []
+    overrides = (getVar('OVERRIDES', d, 1) or "").split(':')[::-1] or []
 
     #
     # Well let us see what breaks here. We used to iterate

If you agree with this change I'll submit a patch.  Should I submit it to this list or another one?

> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel




More information about the Openembedded-devel mailing list