Message ID | 20230303124842.2743563-1-Martin.Jansa@gmail.com |
---|---|
State | New |
Headers | show |
Series | [RFC] providers.sh: versionVariableMatch: use the name of provided item instead of pn | expand |
diff --git a/lib/bb/providers.py b/lib/bb/providers.py index e11a4637d..1aa0d1282 100644 --- a/lib/bb/providers.py +++ b/lib/bb/providers.py @@ -124,8 +124,8 @@ def findPreferredProvider(pn, cfgData, dataCache, pkg_pn = None, item = None): preferred_ver = None required = False - required_v = versionVariableMatch(cfgData, "REQUIRED", pn) - preferred_v = versionVariableMatch(cfgData, "PREFERRED", pn) + required_v = versionVariableMatch(cfgData, "REQUIRED", item) + preferred_v = versionVariableMatch(cfgData, "PREFERRED", item) itemstr = "" if item:
* when checking for PREFERRED_VERSION and REQUIRED_VERSION use the name of the preferred item, not the pn of the provider * sending as RFC, because there might be some other uses of this function where the old behavior was better * the case where this seems to work incorrectly is meta-clang clang recipe which correctly says: conf/layer.conf:LLVMVERSION = "15.0.7" conf/layer.conf:PREFERRED_PROVIDER_llvm-native = "clang-native" recipes-devtools/clang/clang_git.bb:PROVIDES:append:class-native = " llvm-native" LLVMVERSION is used by oe-core as: meta/conf/distro/include/tcmode-default.inc:LLVMVERSION ?= "15.%" meta/conf/distro/include/tcmode-default.inc:PREFERRED_VERSION_llvm = "${LLVMVERSION}" meta/conf/distro/include/tcmode-default.inc:PREFERRED_VERSION_llvm-native = "${LLVMVERSION}" meta/conf/distro/include/tcmode-default.inc:PREFERRED_VERSION_nativesdk-llvm = "${LLVMVERSION}" and now this code will cause a warning about 15.0.7 version not being available even when in the end it will use clang-native as a provider with this version: $ bitbake-getvar -r llvm-native PV 2>&1 | tee log.bitbake-getvar.llvm-native-4 WARNING: preferred version 15.0.7 of llvm-native not available (for item llvm-native) WARNING: versions of llvm-native available: 15.0.6 # # $PV [4 operations] # set oe-core/meta/conf/bitbake.conf:239 # "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" # set oe-core/meta/conf/documentation.conf:340 # [doc] "The version of the recipe. The version is normally extracted from the recipe filename." # set oe-core/meta/classes-global/sstate.bbclass:51 # [vardepvalue] "${PV}" # set meta-clang/recipes-devtools/clang/clang.inc:13 # "${MAJOR_VER}.${MINOR_VER}.${PATCH_VER}" # pre-expansion value: # "${MAJOR_VER}.${MINOR_VER}.${PATCH_VER}" PV="15.0.7" the problem is that both llvm-native from oe-core and clang-native are found as possible providers for item llvm-native, but then we call findPreferredProvider for pkg_pn clang-native, we'll check for PREFERRED_VERSION_clang_native not PREFERRED_VERSION_llvm-native then when running findPreferredProvider for pkg_pn llvm-native we find the PREFERRED_VERSION_llvm-native and if it doesn't match with PV we issue the warning, be aware that this issue is reproducible only when they don't happen to match, e.g. with master before: https://git.openembedded.org/openembedded-core/commit/?id=7438f9a9efaf0826f1be13acbc51f0a1134cf175 in dunfell it's triggered as well, with different versions: WARNING: preferred version 14.0.3 of llvm-native not available (for item llvm-native) WARNING: versions of llvm-native available: 13.0.1 * if we agree that this is something worth changing, then the search for available versions should be similarly changed as well, because now in dunfell it shows only 13.0.1 while clang-native-14.0.3 is also available provider for it (and actually gets used in the end). * this might make some sense for llvm-native and clang-native but I can imagine counter example when you have 2 very different providers for something and you want to control their versions independently from which provider is preferred e.g. by MACHINE.conf * this change didn't cause any new warnings in my builds, but other layers might be more creative with P_V/P_P * alternative solution might be to use different variable name in meta-clang/conf/layer.conf to avoid changing llvm-native P_V and depend on P_P to always select clang recipes to provide llvm which might be less controversial than this P_V behavoir change I have a local commit which changes LLVMVERSION to CLANGLLVMVERSION in these 3 meta-clang places: conf/layer.conf:LLVMVERSION = "14.0.3" dynamic-layers/openembedded-layer/recipes-devtools/bcc/bcc_0.24.0.bb: -DLLVM_PACKAGE_VERSION=${LLVMVERSION} \ dynamic-layers/openembedded-layer/recipes-devtools/bpftrace/bpftrace_0.14.1.bb: pvsplit = d.getVar('LLVMVERSION').split('.') Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> --- lib/bb/providers.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)