autotools: Improve configure dependency code for finding m4 files

We have an open bug about the warnings issues in builds from an sstate cache when something like glib-2.0 gets rebuilt. The issue is that sstate is "clever" and prunes unneeded dependencies out the tree.

For example is X depends on pkgconfig-native but we've already build X and installed it from sstate, it will not get installed when you build Y which depends on X.

This patch changes the logic to match the sstate behaviour and prune out unnecessary dependencies from the scope of aclocal. This in turn removes the warning about missing manifest files.

The issue is that this patch exposes holes in our DEPENDS in recipes, specifically that some native tools are not listed, specifically, and problematically, pkgconfig, gtk-doc and intltool-native in particular.

I've sent out patches against OE-Core that address the bulk of the issues there however I'm conscious this is probably going to a bug issue in other layers and may be too annoying to consider at this point. The other alternative is simply to turn the warning into a debug statement.

I appreciate the code below has commented blocks, this is simply debug I've left around for now. It will be cleaned from any final version.

Signed-off-by Richard Purdie <[email protected]>

meta/classes/autotools.bbclass +38 -2

index 0dc1e6b..34d432e 100644
@@ -142,15 +142,51 @@ python autotools_copy_aclocals () {
             return
 
     taskdepdata = d.getVar("BB_TASKDEPDATA", False)
+    #bb.warn(str(taskdepdata))
     pn = d.getVar("PN", True)
     aclocaldir = d.getVar("ACLOCALDIR", True)
     oe.path.remove(aclocaldir)
     bb.utils.mkdirhier(aclocaldir)
+    start = None
     configuredeps = []
+
     for dep in taskdepdata:
         data = taskdepdata[dep]
-        if data[1] == "do_configure" and data[0] != pn:
-            configuredeps.append(data[0])
+        if data[1] == "do_configure" and data[0] == pn:
+            start = dep
+            break
+    if not start:
+        bb.fatal("Couldn't find ourself in BB_TASKDEPDATA?")
+
+    # We need to find configure tasks which are either from <target> -> <target>
+    # or <native> -> <native> but not <target> -> <native> unless they're direct
+    # dependencies. This mirrors what would get restored from sstate.
+    done = [dep]
+    next = [dep]
+    while next:
+        new = []
+        for dep in next:
+            data = taskdepdata[dep]
+            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
+                new.append(datadep)
+                if taskdepdata[datadep][1] == "do_configure":
+                    configuredeps.append(taskdepdata[datadep][0])
+        next = new
+
+    #configuredeps2 = []
+    #for dep in taskdepdata:
+    #    data = taskdepdata[dep]
+    #    if data[1] == "do_configure" and data[0] != pn:
+    #        configuredeps2.append(data[0])
+    #configuredeps.sort()
+    #configuredeps2.sort()
+    #bb.warn(str(configuredeps))
+    #bb.warn(str(configuredeps2))
 
     cp = []
     for c in configuredeps:

Quoted 12 lines · Richard Purdie

We have an open bug about the warnings issues in builds from an sstate cache when something like glib-2.0 gets rebuilt. The issue is that sstate is "clever" and prunes unneeded dependencies out the tree.

For example is X depends on pkgconfig-native but we've already build X and installed it from sstate, it will not get installed when you build Y which depends on X.

This patch changes the logic to match the sstate behaviour and prune out unnecessary dependencies from the scope of aclocal. This in turn removes the warning about missing manifest files.

Quoted 8 lines

The issue is that this patch exposes holes in our DEPENDS in recipes, specifically that some native tools are not listed, specifically, and problematically, pkgconfig, gtk-doc and intltool-native in particular.

I've sent out patches against OE-Core that address the bulk of the issues there however I'm conscious this is probably going to a bug issue in other layers and may be too annoying to consider at this point. The other alternative is simply to turn the warning into a debug statement.

I'm fine with new warning like this, because I would say that fixing this has higher priority than e.g. QA warnings we have, so it's annoying, but easy to fix.

If you wait +- a week I can do test run on my world builds and report how many warnings it shows.