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 <alex.kanavin@gmail.com>
>> ---
>> 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
>
>
>
>
>