[oe] [PATCH (v2)] Reverse the order of OVERRIDES

[Maupin, Chase]

> -----Original Message-----
> From: openembedded-devel-bounces at lists.openembedded.org
> [mailto:openembedded-devel-bounces at lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Wednesday, November 10, 2010 10:29 AM
> To: openembedded-devel at 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.kooi at student.utwente.nl>wrote:
> >>
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> On 15-10-10 17:41, Chris Larson wrote:
> >>>> From: Chris Larson <chris_larson at 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.maupin at ti.com>
> >>>> Signed-off-by: Chris Larson <chris_larson at mentor.com>
> >>> Acked-by: Koen Kooi <k-kooi at 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel