[PATCH] Fix COMPATIBLE_MACHINE for -native recipe variants.

[PATCH] Fix COMPATIBLE_MACHINE for -native recipe variants.

[Paulo Neves]

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 fix attempts to correct the issue with minimal
changes.

Change-Id: If5085e4e92550b8154033dd56149eb4e358ef266
---
 meta/classes/base.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index d95afb7..d1c31c2 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -488,7 +488,7 @@ python () {
     need_machine = d.getVar('COMPATIBLE_MACHINE')
     if need_machine:
         import re
-        compat_machines = (d.getVar('MACHINEOVERRIDES') or "").split(":")
+        compat_machines = (d.getVar('MACHINEOVERRIDES') or d.getVar('MACHINE')).split(":")
         for m in compat_machines:
             if re.match(need_machine, m):
                 break
-- 
2.7.4

✗ patchtest: failure for Fix COMPATIBLE_MACHINE for -native recipe variants.

[Patchwork]

== Series Details ==

Series: Fix COMPATIBLE_MACHINE for -native recipe variants.
Revision: 1
URL   : https://patchwork.openembedded.org/series/10521/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch            Fix COMPATIBLE_MACHINE for -native recipe variants.
 Issue             Shortlog does not follow expected format [test_shortlog_format] 
  Suggested fix    Commit shortlog (first line of commit message) should follow the format "<target>: <summary>"

* Patch            Fix COMPATIBLE_MACHINE for -native recipe variants.
 Issue             Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fix    Sign off the patch (either manually or with "git commit --amend -s")



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines:     https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite:     http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[Richard Purdie]

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

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

[Richard Purdie]

On Mon, 2018-01-15 at 09:01 +0100, Paulo De Sousa Neves (Nokia -
PL/Wroclaw) wrote:
> Hello Richard,
> 
> My problem is that I have the PV expansion happens on the recipe, at 
> parsing time regardless of it being on the dependency chain or not.
> On 
> the other hand, the PV is not expanded if the COMPATIBLE_MACHINE is 
> honored. This makes my build significantly faster also, as it avoids 
> other expansions altogether.
> 
> Coming back to our issue, this means that with the
> COMPATIBLE_MACHINE 
> being honored, my recipes work for all cases except when they are in 
> native mode.

Native recipes should not be machine dependent so using
COMPATIBLE_MACHINE for this isn't an option.

The good news is its trivial to add your own anonymous python fragment
which does the same thing. Your layer will not pass the layer
compatibility tests should you do that though.

Cheers,

Richard