Re: [OE-core] [PATCH v3] tcmode-default.inc: do not set PREFERRED_VERSION for toolchain items

["Khem Raj" <raj.khem@gmail.com>]

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
> 
> 
> 
> 
>