From: Christopher Larson <chris_lar...@mentor.com>

The logic is supposed to avoid following dependencies when we depend on
a target recipe which depends on a native recipe. The problem is, we were
marking the dep (the native recipe) as already processed when we avoided
traversal, meaning that even when that recipe would be pulled in via
a different dependency, we skipped it there too, and whether it was skipped
entirely depended on the non-deterministic dep processing order. If the first
one to be encountered was via the indirect target dep, it wouldn't end up in
configuredeps, otherwise it would.

As we want to avoid traversing that particular dependency relationship, not
*every* dependency on the native, we should continue, but not add it to done,
so it can be traversed from other avenues.

This fixes an intermittent bug in some of my non-GPLv3 builds, where one
dependency upon gettext-minimal-native was skipped, but others should not have
been, resulting in it being removed from configuredeps entirely, and no
gettext macros being available.

Cc: Richard Purdie <richard.pur...@linuxfoundation.org>
Signed-off-by: Christopher Larson <chris_lar...@mentor.com>
---
 meta/classes/autotools.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 819045a..078f58f 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -168,9 +168,9 @@ python autotools_copy_aclocals () {
             for datadep in data[3]:
                 if datadep in done:
                     continue
-                done.append(datadep)
                 if (not data[0].endswith("-native")) and 
taskdepdata[datadep][0].endswith("-native") and dep != start:
                     continue
+                done.append(datadep)
                 new.append(datadep)
                 if taskdepdata[datadep][1] == "do_configure":
                     configuredeps.append(taskdepdata[datadep][0])
-- 
2.2.1

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to