multilib_script.bbclass was unable to work correctly in the case where
e.g. a PACKAGECONFIG removed the script that it was intended to rename
(as an example, the "trace" PACKAGECONFIG in cairo). The way to fix this
would be to do something like:
MULTILIB_SCRIPTS = "${@bb.utils.contains('PACKAGECONFIG', 'trace', '${PN}-perf-utils:${bindir}/cairo-trace', '', d)}"
but this is not possible because the variable is not expanded before
being split.
To fix this, change the class to expand the variable before splitting.
There are two cases to be considered that could possibly break:
1) If the RHS of the ":" contains a ":", which is accounted for by
limiting the splitting to 1 split, which will leave the ":" in the
RHS in tact. Of note, this works because ":" isn't valid in a
package name
2) If the RHS of the ":" contained whitespace, however this would have
broken the mv command written to multilibscript_rename(), so this
isn't occurring in practice.
(From OE-Core rev: b9c992e69f3f44051610386ce4f743e224750694)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* e.g. mozjs from meta-oe contains major version from PV in the script name
but currently cannot use a variable there because it would be unexpanded
in the varflag name as shown in bitbake -e (lib32-curl included for comparison)
env.lib32-curl:# $ALTERNATIVE_TARGET [2 operations]
env.lib32-curl-# set oe-core/meta/conf/documentation.conf:66
env.lib32-curl-# [doc] "Used by the alternatives system to create default link locations for duplicated commands."
env.lib32-curl-# set multilib_script.bbclass:37 [__anon_40_oe_core_meta_classes_recipe_multilib_script_bbclass]
env.lib32-curl-# [curl-config] "${bindir}/curl-config-${MULTILIB_SUFFIX}"
env.lib32-curl-# pre-expansion value:
env.lib32-curl-# "None"
--
env.lib32-mozjs-115:# $ALTERNATIVE_TARGET [2 operations]
env.lib32-mozjs-115-# set oe-core/meta/conf/documentation.conf:66
env.lib32-mozjs-115-# [doc] "Used by the alternatives system to create default link locations for duplicated commands."
env.lib32-mozjs-115-# set multilib_script.bbclass:37 [__anon_40_oe_core_meta_classes_recipe_multilib_script_bbclass]
env.lib32-mozjs-115-# [js${MAJ_VER}-config] "${bindir}/js${MAJ_VER}-config-${MULTILIB_SUFFIX}"
env.lib32-mozjs-115-# pre-expansion value:
env.lib32-mozjs-115-# "None"
--
env.lib32-mozjs-115-escript:# $ALTERNATIVE_TARGET [2 operations]
env.lib32-mozjs-115-escript-# set oe-core/meta/conf/documentation.conf:66
env.lib32-mozjs-115-escript-# [doc] "Used by the alternatives system to create default link locations for duplicated commands."
env.lib32-mozjs-115-escript-# set multilib_script.bbclass:38 [__anon_41_oe_core_meta_classes_recipe_multilib_script_bbclass]
env.lib32-mozjs-115-escript-# [js115-config] "/usr/bin/js115-config-${MULTILIB_SUFFIX}"
env.lib32-mozjs-115-escript-# pre-expansion value:
env.lib32-mozjs-115-escript-# "None"
Otherwise log.do_package shows that apply_update_alternative_renames first
renames the js115-config to js115-config.mozjs-115 (default ALTERNATIVE_TARGET suffix is '.${BPN}')
and multilibscript_rename later fails:
DEBUG: Executing python function apply_update_alternative_renames
NOTE: mozjs-115: Rename /usr/bin/js115-config -> /usr/bin/js115-config.mozjs-115
DEBUG: Python function apply_update_alternative_renames finished
DEBUG: Executing shell function multilibscript_rename
mv: cannot stat 'BUILD/work/mach-oemllib32-linux-gnueabi/lib32-mozjs-115/115.2.0/package/usr/bin/js115-config': No such file or directory
WARNING: exit code 1 from a shell command.
I wonder if we actually need multilibscript_rename as apply_update_alternative_renames seems
to do the rename already.
(From OE-Core rev: d07bfddba023a1c92491b261c9f9c25ec1a0ef57)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>