Re: [OE-core] [PATCH v3 01/13] toolchain: Provide abstraction for choosing per-recipe toolchain

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2025-05-22 at 20:52 -0700, Khem Raj via lists.openembedded.org wrote:
> This implements a toolchain selection mechanism with existing defaults
> unchanged.
> 
> It introduces a variable called TOOLCHAIN, which denotes the familiar
> name for toolchain e.g. "gcc" which selects GNU compiler + binutils
> as default C/C++ toolchain or "clang" which will use LLVM/Clang Compiler
> 
> Additionally build-gcc is used for selecting native compiler
> 
> TOOLCHAIN variable has a global fallback to "gcc" in configuration
> metadata. A distro can switch to using say "clang" as default system
> compiler by defining
> 
> TOOLCHAIN ?= "clang"
> 
> In local.conf or other distro specific global configuration metadata
> 
> It is also selectable at recipe scope, since not all packages are
> buildable with either clang or gcc, a recipe can explicitly demand
> a given toolchain e.g. glibc can not be built with clang therefore
> glibc recipe sets.
> 
> TOOLCHAIN = "gcc"
> 
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
>  meta/classes-global/base.bbclass                   |  4 ++++
>  meta/classes-recipe/cross-canadian.bbclass         |  1 +
>  meta/classes-recipe/cross.bbclass                  |  1 +
>  meta/classes-recipe/crosssdk.bbclass               |  1 +
>  meta/classes-recipe/native.bbclass                 |  1 +
>  meta/classes-recipe/nativesdk.bbclass              |  1 +
>  meta/classes/toolchain/clang-native.bbclass        | 28 ++++++++++++++++++++++
>  .../clang.inc => classes/toolchain/clang.bbclass}  |  8 +++----
>  .../toolchain/gcc-native.bbclass}                  |  1 -
>  .../gcc.inc => classes/toolchain/gcc.bbclass}      |  1 -
>  meta/conf/bitbake.conf                             |  5 ++--
>  11 files changed, 43 insertions(+), 9 deletions(-)
> 
> diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
> index 8215969c7bb37c1a1b91e260cd31714fee2db87c..1e7d6fe9b6ac34c17820d9f6378a5aa50f00dff4 100644
> --- a/meta/classes-global/base.bbclass
> +++ b/meta/classes-global/base.bbclass
> @@ -19,6 +19,10 @@ PACKAGECONFIG_CONFARGS ??= ""
>  
>  inherit metadata_scm
>  
> +inherit toolchain/gcc-native
> +inherit toolchain/gcc
> +inherit_defer ${@oe.utils.ifelse(d.getVar('TOOLCHAIN') == 'clang', 'toolchain/clang', '')}

The fact we can't conditionally inherit gcc is bothering me quite a
bit. I did experiment a bit locally and I can certainly see the
challenge. The trouble is that even with the approach in this patch, I
think we're going to run into trouble as soon as we want to use clang
for native or sdk recipes.

The big problem is the ordering of the two deferred inherits (e.g.
native and toolchain/gcc) and how that interacts with class overrides.
You couldn't do something like:

TOOLCHAIN = "clang"
TOOLCHAIN:class-native = "gcc"

for example, since the class-native override isn't set until after
TOOLCHAIN is expanded in the deferred inherit.

I'll continue to give this some thought but I wanted to at least give a
headsup warning that this isn't going to scale as we might need it to.

Cheers,

Richard