Hi Linus, 2017-11-20 3:02 GMT+09:00 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>: > 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 OK, probably this is the right direction. Embedded folks need to agree to give CROSS_COMPILE to the Kconfig phase. -- Best Regards Masahiro Yamada -- 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
