All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] tcmode-default.inc: do not set PREFERRED_VERSION for toolchain items
@ 2021-07-14 14:14 Alexander Kanavin
  2021-07-14 16:26 ` [OE-core] " Richard Purdie
  0 siblings, 1 reply; 4+ messages in thread
From: Alexander Kanavin @ 2021-07-14 14:14 UTC (permalink / raw)
  To: openembedded-core; +Cc: Alexander Kanavin

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}"
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [OE-core] [PATCH v3] tcmode-default.inc: do not set PREFERRED_VERSION for toolchain items
  2021-07-14 14:14 [PATCH v3] tcmode-default.inc: do not set PREFERRED_VERSION for toolchain items Alexander Kanavin
@ 2021-07-14 16:26 ` Richard Purdie
  2021-07-14 17:36   ` Khem Raj
  0 siblings, 1 reply; 4+ messages in thread
From: Richard Purdie @ 2021-07-14 16:26 UTC (permalink / raw)
  To: Alexander Kanavin, openembedded-core

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.

Cheers,

Richard


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [OE-core] [PATCH v3] tcmode-default.inc: do not set PREFERRED_VERSION for toolchain items
  2021-07-14 16:26 ` [OE-core] " Richard Purdie
@ 2021-07-14 17:36   ` Khem Raj
  2021-07-15  8:13     ` Alexander Kanavin
  0 siblings, 1 reply; 4+ messages in thread
From: Khem Raj @ 2021-07-14 17:36 UTC (permalink / raw)
  To: Richard Purdie, Alexander Kanavin, openembedded-core



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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [OE-core] [PATCH v3] tcmode-default.inc: do not set PREFERRED_VERSION for toolchain items
  2021-07-14 17:36   ` Khem Raj
@ 2021-07-15  8:13     ` Alexander Kanavin
  0 siblings, 0 replies; 4+ messages in thread
From: Alexander Kanavin @ 2021-07-15  8:13 UTC (permalink / raw)
  To: Khem Raj; +Cc: Richard Purdie, OE-core

[-- Attachment #1: Type: text/plain, Size: 6194 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 8091 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-07-15  8:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-14 14:14 [PATCH v3] tcmode-default.inc: do not set PREFERRED_VERSION for toolchain items Alexander Kanavin
2021-07-14 16:26 ` [OE-core] " Richard Purdie
2021-07-14 17:36   ` Khem Raj
2021-07-15  8:13     ` Alexander Kanavin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.