> -----Original Message----- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of > Tom Rini > Sent: Wednesday, November 10, 2010 10:29 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH (v2)] Reverse the order of OVERRIDES > > Richard Purdie wrote: > > On Fri, 2010-10-15 at 12:44 -0700, Chris Larson wrote: > >> On Fri, Oct 15, 2010 at 12:37 PM, Koen Kooi > <k.k...@student.utwente.nl>wrote: > >> > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> On 15-10-10 17:41, Chris Larson wrote: > >>>> From: Chris Larson <chris_lar...@mentor.com> > >>>> > >>>> Given the current implementation of OVERRIDES in bitbake, the > variable is > >>>> expected to contain elements in the order least specific to most > >>> specific, > >>>> however, our current usage of it does not match that. As one example, > >>> "local" > >>>> is supposed to always be the most specific override, yet currently > it's > >>> the > >>>> least specific. As another example, currently the target > architecture is > >>> seen > >>>> as more specific than the machine, which is also clearly wrong. > >>>> > >>>> Big thanks to Chase Maupin for investigating and identifying this > long > >>>> standing issue. > >>>> > >>>> It becomes clear that a reversal of the current value will bring us > to a > >>> more > >>>> sane behavior, and avoids the need for the dual overrides hack > mentioned > >>> in > >>>> the comments, so this implements this reversal, and drops the > unnecessary > >>> and > >>>> confusing comments. > >>>> > >>>> This also introduces a MACHINE_OVERRIDES variable as a generic > mechanism > >>> to > >>>> inject overrides elements which are more specific than the distro but > >>> less > >>>> specific than the machine, which is where things like MACHINE_CLASS > or > >>>> SOC_FAMILY or the like would go. This variable is *space* separated, > to > >>> make > >>>> it easier and more convenient to assemble the variable incrementally. > >>>> > >>>> Reported-by: Chase Maupin <chase.mau...@ti.com> > >>>> Signed-off-by: Chris Larson <chris_lar...@mentor.com> > >>> Acked-by: Koen Kooi <k-k...@ti.com> > >>> > >> This is now in master -- thanks to all for the acks, review, comments - > - let > >> me know if any problems result from this. > > > > You do realise the damage this potentially causes for compatibility of > > metadata between OE and Poky? > > > > This change is pretty serious and potentially alters the handling of any > > double override. Poky uses them a bit more extensively than OE does. Its > > effectively an architecture change to OE yet no discussion was had at > > any TSC meeting :(. > > > > I even asked about this a while back and was *told* that "local" was > > meant to be weak, I therefore added a strong version to Poky, in the > > spirit of maintaining compatibility. > > > > (a) Eeep! and (b) That's pretty much the opposite of what the rest of > the thread / discussion was, which is to say "local is supposed to be > the final winner, why isn't it?" > > Now... what do we do here?
I know this was all posted a while back. Has there been any resolution on this? I didn't notice any additional responses to this thread. > > -- > Tom Rini > Mentor Graphics Corporation > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel