LLVMVERSION itself wasn't being dropped, only the PREFERRED_VERSION setting
that uses it.

But I'd agree with the broader point; it's better for devtool to print a
warning on upgrades that PREFERRED_VERSION needs to be adjusted (if it's
set) before any further steps.

Alex

On Wed, 14 Jul 2021 at 19:36, Khem Raj <raj.khem@gmail.com> wrote:

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