mirror of
https://git.yoctoproject.org/poky
synced 2026-02-09 10:13:03 +01:00
9155e70299
multiconfig dependencies should be excluded from BB_TASKDEPDATA.
However in thud, multiconfig filtering on task dependencies doesn't
happen until after deps has already been added to taskdepdata.
One manifestation of this results in multiconfig dependencies leaking
into staging processing.
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:extend_recipe_sysroot(d)
0003:
File: '/home/user/thud/meta/classes/staging.bbclass', lineno: 344, function: extend_recipe_sysroot
0340: #bb.note(" start is %s" % str(start))
0341:
0342: # Direct dependencies should be present and can be depended upon
0343: for dep in set(start):
*** 0344: if setscenedeps[dep][1] == "do_populate_sysroot":
0345: if dep not in configuredeps:
0346: configuredeps.append(dep)
0347: bb.note("Direct dependencies are %s" % str(configuredeps))
0348: #bb.note(" or %s" % str(start))
Exception: KeyError: 'multiconfig:musl:/home/user/thud/meta/recipes-kernel/linux/linux-yocto_4.18.bb:do_deploy'
This can be reproduced on thud by backporting the multiconfig.MultiConfig.test_multiconfig
test and mcextend bbclass from warrior.
d22b6e03a5 mcextend: Add helper class useful for multiconfig
d9018a3d9c selftest: Add multiconfig test
Flipping the ordering to match warrior's behavior fixes the test case.
(Bitbake rev: b690030efc87850951e8e3ecf4ae3c1dd1dc9b63)
Signed-off-by: Kyle Russell <bkylerussell@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>