| Summary: | @contains does not create vardep automatically | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Martin Jansa <Martin.Jansa> |
| Component: | core | Assignee: | Richard Purdie <richard.purdie> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | meta.mr.watcher, meta.watcher, ross.burton |
| Version: | unspecified | ||
| Target Milestone: | 1.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
This one is simpler for sure..
(the same as base_contains without first line to getVar(variable))
${@val_contains("${DISTRO_FEATURES}", 'bar', 'man', '', d)}
Other ideas?
See how this works:
diff --git a/bitbake/lib/bb/codeparser.py b/bitbake/lib/bb/codeparser.py
index 979e6bd..78f82e1 100644
--- a/bitbake/lib/bb/codeparser.py
+++ b/bitbake/lib/bb/codeparser.py
@@ -101,6 +101,7 @@ class BufferedLogger(Logger):
class PythonParser():
getvars = ("d.getVar", "bb.data.getVar", "data.getVar", "d.appendVar", "d.prependVar")
+ containsfuncs = ("bb.utils.contains", "base_contains", "oe.utils.contains")
execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
def warn(self, func, arg):
@@ -119,7 +120,7 @@ class PythonParser():
def visit_Call(self, node):
name = self.called_node_name(node.func)
- if name in self.getvars:
+ if name in self.getvars or name in self.containsfuncs:
if isinstance(node.args[0], ast.Str):
self.var_references.add(node.args[0].s)
else:
For some reason this isn't enough, bitbake-diffsigs does not show new dependency and task checksum is the same with or without bar in DISTRO_FEATURES. I did some experimentation. I can't make it work properly with base_contains since it doesn't track the variable reference properly however if I instead do: --- a/meta/recipes-kernel/latencytop/latencytop_0.5.bb +++ b/meta/recipes-kernel/latencytop/latencytop_0.5.bb @@ -15,7 +15,7 @@ SRC_URI = "http://www.latencytop.org/download/latencytop-${PV}.tar.gz \ SRC_URI[md5sum] = "73bb3371c6ee0b0e68e25289027e865c" SRC_URI[sha256sum] = "9e7f72fbea7bd918e71212a1eabaad8488d2c602205d2e3c95d62cd57e9203ef" -EXTRA_OEMAKE_X = "${@base_contains('DISTRO_FEATURES', 'x11', 'HAS_GTK_GUI=1', '', d)}" +EXTRA_OEMAKE_X = "${@oe.utils.contains('DISTRO_FEATURES', 'x11', 'HAS_GTK_GUI=1', '', d)}" CFLAGS += "${LDFLAGS}" then this does track the reference properly with the patch I attached. I'm tempted just to remove base_contains since it is just an old wrapper... A further update - there is a cache issue here. The patch does work and *does* need the base_contains. You need to rm tmp/cache/bb_codeparser.dat for the changes to be visible though since the cache gets in the way. Fixed with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f966c544aa4da61a19bc0d751c2bbf0f66028791 (now including cache version bump) Confirmed on my use-case with base_contains. Thanks! Is this something we can backport to danny? cc'd to the danny maintainer. We need to test this in master a while first but in theory the patch would apply easily enough. Probably some other bitbake fixes we could pull onto the stable branch I guess. Only concern is this will change all the sstate checksums but we've probably changed enough in the point release anyway to make that a lesser consideration... (In reply to comment #9) > cc'd to the danny maintainer. We need to test this in master a while first > but in theory the patch would apply easily enough. Probably some other > bitbake fixes we could pull onto the stable branch I guess. > > Only concern is this will change all the sstate checksums but we've probably > changed enough in the point release anyway to make that a lesser > consideration... Ross, can you cherry-pick 767b4751232f4ee3979deb4d3f733fcf9ee2bd44 0b9d117631ce909312d53b93289e61defc6be01c to bitbake-1.16? Richard has to do the bitbake cherry-picking. cherry-picked to 1.16 |
tested with all 3 "contains" variants oe.utils.contains base_contains (calls oe.utils.contains) bb.utils.contains (same code as oe.utils.contains) When I use FOO="${@oe.utils.contains('BAR', '1', 'YES', 'NO')}" it would be convenient to automatically detect FOO dependency on BAR as variable. Real world example: foo.bb: RDEPENDS_${PN} = "${@oe.utils.contains('DISTRO_FEATURES', 'bar', 'man', '', d)}" This scenario currently works very badly: 1) do_package checksum is not changed when DISTRO_FEATURES gets or loose 'bar', because expression looks the same and foo.do_package does not depend on DISTRO_FEATURES variable 2) do_package_write checksum is changed, because new deptask is found as reported by bitbake-diffsigs: Dependency on task man.do_packagedata was added with hash deadcafe so user sees do_package_write and e.g. do_package_write_ipk executed, but 'Depends' field in .ipk is the same, because do_packagedata/emit_pkgdata wasn't reexecuted to write new RDEPENDS value. There is simple work around to add explicit vardep RDEPENDS_foo[vardep] += "DISTRO_FEATURES" but that's not really intuitive, easy to forget and hard to find out later when you just notice on target that some incremental builds behave different then other. Also RDEPENDS_${PN}[vardep] += "DISTRO_FEATURES" does not seem to work. Can we record this dependency somehow automatically? I can probably add something like def append_contains(variable, checkvariable, checkvalues, truevalue, falsevalue, d): d.appendVar(variable, base_contains(checkvariable, checkvalues, truevalue, falsevalue, d) d.appendVarFlag(variable, 'vardeps', checkvariable) or def base_contains_with_vardep(variable, checkvariable, checkvalues, truevalue, falsevalue, d): d.appendVarFlag(variable, 'vardeps', checkvariable) base_contains(checkvariable, checkvalues, truevalue, falsevalue, d) RDEPENDS_${PN} = "${@base_contains_wit_vardep('RDEPENDS_foo', 'DISTRO_FEATURES', 'bar', 'man', '', d)}" But I hope there is better simpler solution :).