Hello Linus, Thanks for giving me some more homeworks. On Thu, Mar 23, 2023 at 1:56 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Mar 22, 2023 at 9:40 AM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: > > > > You have to pass `make LLVM=1` in any case... to `oldconfig` or when > > adding any MAKEFLAGS like -j${number-of-available-cpus}. > > I actually think we should look (again) at just making the compiler > choice (and the prefix) be a Kconfig option. > > That would simplify *so* many use cases. > > It used to be that gcc was "THE compiler" and anything else was just > an odd toy special case, but that's clearly not true any more. > > So it would be lovely to make the kernel choice a Kconfig choice - so > you'd set it only at config time, and then after that a kernel build > wouldn't need special flags any more, and you'd never need to play > games with GNUmakefile or anything like that. Presumably, this is the right direction. To achieve it, Kconfig needs to have some mechanism to evaluate shell commands dynamically. If a user switches the toolchain set between GCC and LLVM while running the Kconfig, $(cc-option) in Kconfig files must be re-calculated. Currently, Kconfig cannot do it. All macros are static - they are expanded in the parse stage, and become constant strings. Ulf Magnusson and I discussed the dynamic approach a few years back, but I adopted the static way since it is much simpler. We need to reconsider the dynamic approach to do this correctly. I do not think it is too difficult technically. We just need to come up with a decent syntax. > Yes, you'd still use environment variables (or make arguments) for > that initial Kconfig, but that's no different from the other > environment variables we already have, like KCONFIG_SEED that kconfig > uses internally, but also things like "$(ARCH)" that we already use > *inside* the Kconfig files themselves. > > I really dislike how you have to set ARCH and CROSS_COMPILE etc > externally, and can't just have them *in* the config file. > > So when you do cross-compiles, right now you have to do something like > > make ARCH=i386 allmodconfig > > to build the .config file, but then you have to *repeat* that > ARCH=i386 when you actually build things: > > make ARCH=i386 > > because the ARCH choice ends up being in the .config file, but the > makefiles themselves always take it from the environment. > > There are good historical reasons for our behavior (and probably a > number of extant practical reasons too), but it's a bit annoying, and > it would be lovely if we could start moving away from this model. > > Linus Moving ARCH into the .config file needs careful thoughts, I think. Not all targets include the .config file. For example, "make clean", "make help", etc. It is unclear which targets require explicit ARCH= option. One solution is to move "archhelp", "CLEAN_FILES" etc. from arch/*/Makefile to the top Makefile. We will lose per-arch splitting in several places, though. U-Boot adopts this model - 'ARCH' is determined in the Kconfig time, so users do not need to give ARCH= option from the command line. https://github.com/u-boot/u-boot/blob/v2023.01/arch/Kconfig#L44 You may get a quick idea of what it will look like. I will take a look at this direction (the compiler choice in Kconfig first), but it will not happen soonish due to the limited time for upstream work. -- Best Regards Masahiro Yamada