Re: [PATCH] Fix COMPATIBLE_MACHINE for -native recipe variants.

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2018-01-12 at 18:45 +0100, Paulo Neves wrote:
> From: Paulo Neves <paulo.de_sousa_neves@nokia.com>
> 
> Hello I am having a problem where I want a recipe, along
> with its -native version to only be available when allowed
> by compatible machine.
> 
> In the non native case, COMPATIBLE_MACHINE is correctly
> honored. But in the -native version the COMPATIBLE_MACHINE
> is not honored because in the native.bbclass there is:
> 
> MACHINEOVERRIDES = ""
> 
> This change was introduced in
> d09e6d883042e5d094cd08d829327c4bbbfae135.
> While the explanation provided by the commit is accurate for
> specific case mentioned it also breaks the
> COMPATIBLE_MACHINE mechanism which relies on the
> MACHINEOVERRIDES variable.
> 
> Further evidence that this was not intended is that the
> exception text is false:
> 
> ERROR: Nothing PROVIDES 'x-filter-native'
> x-filter-native was skipped: incompatible with machine m1
> (not in COMPATIBLE_MACHINE)
> 
> And the x-filter-native'.bb recipe header contains:
> 
> COMPATIBLE_MACHINE = "^m1$"
> 
> So the exception uses ${MACHINE} to report that a
> ${MACHINEOVERRIDE} was not matched with the
> COMPATIBLE_MACHINE, which is a false statement.

This will cause other problems and there is actually a reason this is
breaking. Native recipes should be completely target independent and
not depend on MACHINE at all.

Why can't you always have the native version available? It will only
get built if something actually depends on it...

FWIW I think your change will add a MACHINE dependency to the code and
then trigger sstate tests to fail (which check native recipes don't
depend on machine).

Cheers,

Richard