On Wed, Jul 21, 2021 at 1:53 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Tue, Jul 20, 2021 at 02:54:35PM -0700, Linus Torvalds wrote: > > But there are other things that stick around. In particular, I have > > considered simply using git config variables for that. > > > > Something like this in the main Makefile: > > > > ARCH=$(shell git config build.arch) > > CC=$(shell git config --default=gcc build.cc) > > > > would actually be optimal for what _I_ do. Then for my clang build tree, I'd do > > > > git config build.cc clang > > > > and it would stick in that tree. If you don't set the option, it would use gcc. > > > > Maybe that would be an acceptable model these days? We've used git > > long enough that non-git worries aren't a big deal any more, and I > > guess people could use the old-fashioned > > I still this only papers around the fact that the architecture is > fundamentally part of the kernel config In fact, I am the person who did it in U-boot several years ago. In U-Boot Kconfig, the architecture is selected by a Kconfig choice: https://github.com/u-boot/u-boot/blob/v2021.07/arch/Kconfig#L22 (but, if you look at Makefiles and Kconfigs of U-Boot, you will notice they are uglier than the kernel's ones.) Theoretically, yes, it is possible to make ARCH as part of the .config in the kernel as well, but we need careful consideration to make it robust, clean, and efficient. In the current model, the Kconfig stage would be even slower because Kconfig would end up with a bunch of unrelated cc-option from other architectures. For example, arch/s390/Kconfig has so many cc-option. If we allow Kconfig to choose "ARCH', all Kconfig files of all architectures must be parsed. If you intend to build the x86 kernel, you might think that parsing the expensive arch/s390/Kconfig is pointless. > and should come from .config, > and the toolchain probably as well. > > I for one do have a few different tree for different projects, but > need to try cross compiles in each of them. And unfortunately sometimes > with clang (nothing against clang itself [1], just that having to deal > with multiple toolchains is a pain) > > [1] well, except for the sometimes idiotic diagnostics.. -- Best Regards Masahiro Yamada
