[oe] [PATCH] Reverse the order of OVERRIDES

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Fri Oct 15 06:56:44 UTC 2010


2010/10/15 Khem Raj <raj.khem at gmail.com>:
> On Thu, Oct 14, 2010 at 8:36 PM, Chris Larson <kergoth at gmail.com> 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.
>>
>> 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 clean those up as well.
>>
>> 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, and it's
>> then translated to : separated when used in OVERRIDES.
>>
>> Signed-off-by: Chris Larson <chris_larson at mentor.com>
>
> both things look nice to me. We might need to document MACHINE_OVERRIDES though.
>
> Acked-by: Khem Raj <raj.khem at gmail.com>
>
Looks fine to me.
Actually I've wondered several times why local did not have priority
(but I had to do things like X_local).
But before adding an ack, I would like to ask what has been done wrt
testing (as this is potentially quite invasive).

Also is there a way we can detect where the recipes can be simplified
by adding unneeded appendices? (e.g by modifying/extending
recipe_sanity).

Thanks for the patch! Frans




More information about the Openembedded-devel mailing list