On Sun, Nov 19, 2017 at 2:40 AM, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote: >> >> FWIW, I still think we should probably make the compiler versions etc >> available to the configuration management rather than necessarily >> cache them. > > Do you mean something like this? > > https://lkml.org/lkml/2016/12/9/577 Yes. With the important part not being so much that particular syntax, but the concept of "get some config options from automation". And the most obvious thing to do would be to just initialize a "bool" variable by running a script where the end result is either success or failure. Now, the actual example: config COMPILER_SUPPORTS_XYZ bool option shell="gcc -XYZ" is obviously too simplified to be realistic, because it would have to account for the actual compiler setup, so what you really need is not "just execute a shell command" but the equivalent of the Makefile "cc-option" function. Aes, for "known buggy versions" you might want to also get the actual compiler version into a config option. Even if "cc-option" is the _only_ thing you can do (and not some kind of "generic shell escape"), I think that would be very useful. Wouldn't it be nice to be able to have all those Makefile things as Kcconfig scripts - and be able to very naturally take them into account when offering people some Kconfig options? So you could do all the logic of not only testing what flags the compiler supports, but then use the Kconfig language to _combine_ that knowledge with the build options. Both in the sense of "this kernel config option depends on the compiler supporting flag XYZ" but also in the sense of "the use flag ABC depends on not only compiler support, but also on whether the kernel was configured for profiling" or whatever. Then the actual Makefile parts would be things like CFLAGS-$(CONFIG_CC_SPLIT_DWARF) += -gsplit_dwarf because the Kconfig phase would already have all the logic for whether (a) gcc actually supports -gsplit-dwarf at all and (b) whether the user actually asked for split debug info. And we'd not have the performance issues that made that whole caching thing be an issue, because the actual gcc support testing would only happen at Kconfig time. .. it would also make the caching rules be obvious. It's just a "if you upgraded or changed compilers enough to be noticeable, re-do your config ('make oldconfig')". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
