On 7/14/21 9:26 AM, Richard Purdie wrote:
On Wed, 2021-07-14 at 16:14 +0200, Alexander Kanavin wrote:
oe-core has not been providing multiple versions for any of these items
for a long time, it's not likely to change anytime soon, and it makes
automated (or semi-automated) versions updates with devtool impossible,
as PREFERRED_VERSION masks the updated recipe in devtool workspace.
Specifically, this was prompted by investigating why automated llvm update
doesn't work; it does now.
v2: GCC is excluded as overriding the version through GCCVERSION is used
across several layers, and the list of things to override is large.
v3: exclude linux-libc-headers too, as that is using a separate update
process without involving devtool.
Signed-off-by: Alexander Kanavin <[email protected]>
---
meta/conf/distro/include/tcmode-default.inc | 36 ---------------------
1 file changed, 36 deletions(-)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 1d4aa1e11f..e655bd85ce 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -18,12 +18,7 @@ PREFERRED_PROVIDER_virtual/gettext ??= "gettext"
GCCVERSION ?= "11.%"
SDKGCCVERSION ?= "${GCCVERSION}"
-BINUVERSION ?= "2.36%"
-GDBVERSION ?= "10.%"
-GLIBCVERSION ?= "2.33"
LINUXLIBCVERSION ?= "5.13%"
-QEMUVERSION ?= "6.0%"
-GOVERSION ?= "1.16%"
# This can not use wildcards like 8.0.% since it is also used in mesa to
denote
# llvm version being used, so always bump it with llvm recipe version bump
LLVMVERSION ?= "12.0.1"
@@ -42,42 +37,11 @@ PREFERRED_VERSION_libgfortran ?= "${GCCVERSION}"
PREFERRED_VERSION_nativesdk-gcc ?= "${SDKGCCVERSION}"
PREFERRED_VERSION_nativesdk-libgcc ?= "${SDKGCCVERSION}"
PREFERRED_VERSION_nativesdk-libgcc-initial ?= "${SDKGCCVERSION}"
-PREFERRED_VERSION_binutils ?= "${BINUVERSION}"
-PREFERRED_VERSION_binutils-native ?= "${BINUVERSION}"
-PREFERRED_VERSION_binutils-cross-${TARGET_ARCH} ?= "${BINUVERSION}"
-PREFERRED_VERSION_binutils-crosssdk-${SDK_SYS} ?= "${BINUVERSION}"
-PREFERRED_VERSION_binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} ?=
"${BINUVERSION}"
-PREFERRED_VERSION_gdb ?= "${GDBVERSION}"
-PREFERRED_VERSION_gdb-cross-${TARGET_ARCH} ?= "${GDBVERSION}"
-PREFERRED_VERSION_gdb-cross-canadian-${TRANSLATED_TARGET_ARCH} ?=
"${GDBVERSION}"
PREFERRED_VERSION_linux-libc-headers ?= "${LINUXLIBCVERSION}"
PREFERRED_VERSION_nativesdk-linux-libc-headers ?= "${LINUXLIBCVERSION}"
-PREFERRED_VERSION_glibc ?= "${GLIBCVERSION}"
-PREFERRED_VERSION_glibc-locale ?= "${GLIBCVERSION}"
-PREFERRED_VERSION_glibc-mtrace ?= "${GLIBCVERSION}"
-PREFERRED_VERSION_glibc-scripts ?= "${GLIBCVERSION}"
-PREFERRED_VERSION_nativesdk-glibc ?= "${GLIBCVERSION}"
-PREFERRED_VERSION_cross-localedef-native ?= "${GLIBCVERSION}"
-
-PREFERRED_VERSION_qemu ?= "${QEMUVERSION}"
-PREFERRED_VERSION_qemu-native ?= "${QEMUVERSION}"
-PREFERRED_VERSION_nativesdk-qemu ?= "${QEMUVERSION}"
# Bootstrap Go using a binary release from golang.org. If you want to
bootstrap
# from source using the C-implemented Go 1.4 (only supports x86-64 hosts)
then use
# go-native.
PREFERRED_PROVIDER_go-native ?= "go-binary-native"
-PREFERRED_VERSION_virtual/${TARGET_PREFIX}go ?= "${GOVERSION}"
-PREFERRED_VERSION_go-cross-${TUNE_PKGARCH} ?= "${GOVERSION}"
-PREFERRED_VERSION_go-crosssdk-${SDK_ARCH} ?= "${GOVERSION}"
-PREFERRED_VERSION_go-cross-canadian-${TRANSLATED_TARGET_ARCH} ?= "${GOVERSION}"
-PREFERRED_VERSION_go ?= "${GOVERSION}"
-PREFERRED_VERSION_go-native ?= "${GOVERSION}"
-PREFERRED_VERSION_go-runtime ?= "${GOVERSION}"
-PREFERRED_VERSION_nativesdk-go ?= "${GOVERSION}"
-PREFERRED_VERSION_nativesdk-go-runtime ?= "${GOVERSION}"
-
-PREFERRED_VERSION_llvm = "${LLVMVERSION}"
-PREFERRED_VERSION_llvm-native = "${LLVMVERSION}"
-PREFERRED_VERSION_nativesdk-llvm = "${LLVMVERSION}"
$ grep LLVMVERSION * -R
classes/meson.bbclass.orig:llvm-config = 'llvm-config${LLVMVERSION}'
classes/meson.bbclass:llvm-config = 'llvm-config${LLVMVERSION}'
which is why we have LLVMVERSION. I'm sure some other layer breaks if we
don't do this.
To be honest I think this starts to look like we can drop qemu and
not much else, the rest have many different related providers and
are pretty toolchain like where it is hard to guess what the form the
variables should take. That was the design purpose of the tcmode
include file. Most of those components wouldn't likely work with
devtool upgrade anyway and would need more careful handling.
honestly, this will cause more pain than what it is solving, eg.
meta-clang also uses LLVMVERSION to override oe-core provided version
and mesa depends on it too. The purpose of these variables was to let
users swap out toolchains which are consisting of multiple different
components/recipes and they may not know the whole chain that needs to
be replaced. This patch takes us back to where we were few years ago. I
would like to understand what issue does this patch solve that we are
willing to break external layers for.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153857):
https://lists.openembedded.org/g/openembedded-core/message/153857
Mute This Topic: https://lists.openembedded.org/mt/84202442/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
