Re: [PATCH v2 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for LLVM=1 LLVM_IAS=1

[Masahiro Yamada]

On Wed, Jul 21, 2021 at 2:43 AM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jul 20, 2021 at 1:05 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
> >
> > LLVM=1 is a convenient switch to change all the
> > defaults, but yet you can flip each tool individually.
>
> Actually, I'd argue that "LLVM=1" is *not* a convenient switch.
> Neither are the individual other command line settings.
>
> When clang was the odd man out, and special, it all made sense.
> Changing the path to CC was similar to changing the path to AWK. And
> that's obviously why we have what we have.
>
> But clang has become a primary compiler for some kernel communities,
> and I think it might be time to just re-visit that entirely.
>
> In particular, I think we should just make it a Kconfig option. I hate
> the command flag stuff so much, that my clang tree literally has this
> patch in it:
>
>     -CC = $(CROSS_COMPILE)gcc
>     +CC = $(CROSS_COMPILE)clang
>
> so that I can just do the same "make -j128" in both my gcc tree and my
> clang tree.
>
> But each build tree already has its own .config file, so it would be a
> lot more convenient if that was how the compiler was chosen, and then
> "make oldconfig" would just DTRT.
>
> We do most of the other heavy lifting in this area in Kconfig anyway,
> why not add that compiler choice?


This does not work in the current design.

When we moved compiler tests to Kconfig from Makefile at v4.18,
I discussed a lot about the implementation.
Especially 'static' vs 'dynamic'.
(mostly Ulf Magnusson actively gave me feed backs)


static model
    Kconfig is given with a fixed set of toolchains.
    All macros such as cc-option are expanded in the early parse stage
    before proceeding to the configuration stage.


dynamic  model
   Every time a user toggles a CONFIG option, it feeds back to
   cc-option because CONFIG options (such as CONFIG_64BIT)
   might affect cc-option. In this model, CONFIG_CROSS_COMPILE
   works well.




Of course, the dynamic model is much more complex,
and I could not find a sane syntax to achieve it.

So, I implemented the static model; in this model,
$(cc-option ) are all constant values.

So, you cannot do:


  choice
         prompt "Compiler suite"

  config GCC
          "GCC and GNU binutils"

   config LLVM
           "LLVM (clang and llvm tools)"

  endchoice



To achieve this, we need the dynamic model.

Every time a user switches between CONFIG_GCC and CONFIG_LLVM,
all the cc-options must be re-evaluated.
This does not work in the current implementation.






BTW, keeping the command line interface
such as CROSS_COMPILE=...  CC=... LD=...
is useful when the kernel is built from umbrella
projects such as Buildroot, OpenEmbedded, etc.

Such projects build compilers by themselves,
and feed the exact compiler paths to the kernel.

Too long command line is an annoyance when
we build the kernel manually.












>
> Obviously it would be gated by the tests to see which compilers are
> _installed_ (and that they are valid versions), so that it doesn't ask
> stupid things ("do you want gcc or clang" when only one of them is
> installed and/or viable).
>
> Hmm? So then any "LLVM=1" thing would be about the "make config"
> stage, not the actual build stage.
>
> (It has annoyed me for years that if you want to cross-compile, you
> first have to do "make ARCH=xyz config" and then remember to do "make
> ARCH=xyz" for the build too, but I cross-compile so seldom that I've
> never really cared).
>
> Let the flame wars^H^Hpolite discussions ensue..
>
>                         Linus

--
Best Regards
Masahiro Yamada