Re: [RFC PATCH 0/7] Kconfig: add new special property shell= to test compiler options in Kconfig
Hi Linus, 2018-02-09 2:19 GMT+09:00 Linus Torvalds : > On Thu, Feb 8, 2018 at 8:19 AM, Masahiro Yamada > wrote: >> This was prompted by the email from Linus today's morning. > > Thanks. > >> I implmented this in a rush today, so there are still many TODOs, >> but I put it here to start discussion. >> >> I think it is working, but as you notice, it is tedious to repeat something >> like follows: >> >> config CC_HAS_STACKPROTECTOR >> bool >> option shell="$CC -Werror -fstack-protector -c -x c /dev/null" > > Yeah. > > I do think we want to have the "shell" thing as a generic escape for > other things too, but *realistically*, the primary target for this is > compiler flags, and I think we should target that specifically with a > shorthand. > > Doing some statistics, and looking for > > flag = $(call xyz ...) > > patterns in our makefiles (ignoring single uses), it really is > cc-option that dominates: > > 2 name-fix > 2 try-run > 3 __cc-option > 3 grep-libs > 3 strip-libs > 4 flags > 4 get-executable > 4 ld-option > 4 logo-cfiles > 5 as-option > 5 cc-cross-prefix > 6 cc-ldoption > 6 cc-supports > 7 cc-option-yn > 7 tune > 9 cc-ifversion > 30 as-instr > 48 cc-disable-warning > 239 cc-option > > so I think that's the one that we want to special-case. > > If we then have a _usable_ - but perhaps not wonderful "shell" escape > to do any random thing (including scripts etc), that will take care of > the rest, but cc-option is so common that I think it's worth making a > special Kconfig syntax for them. For all I know, the others aren't > even worth Kconfig options at all. > >> I was thinking of something like follows: >> >> config CC_STACKPROTECTOR >> bool >> option shell="$(CC_OPTION -fstack-protector)" > > I think we should go even further, and just make it be > > config CC_STACKPROTECTOR > bool > option cc_option="-fstack-protector" > > and actually have the Kconfig language itself have this special-cased. > > And obviously that "option cc_option" would be *implemented* as just > "option shell", with just some stupid string substitution. So it > really would be purely a shorthand for readability. > > What do you think? OK, I will try this way. > And btw, the patches look nice. What I like in particular is that they > don't even seem to add a lot of lines: the new shell option code is > almost balanced out by the Kconfig script simplifications. And maybe > it's just that I read C a lot better than I read GNU Makefile magic, > but I think it's more understandable too. I am glad you like it. :) -- Best Regards Masahiro Yamada
Re: [RFC PATCH 0/7] Kconfig: add new special property shell= to test compiler options in Kconfig
On Thu, Feb 8, 2018 at 8:19 AM, Masahiro Yamada wrote: > This was prompted by the email from Linus today's morning. Thanks. > I implmented this in a rush today, so there are still many TODOs, > but I put it here to start discussion. > > I think it is working, but as you notice, it is tedious to repeat something > like follows: > > config CC_HAS_STACKPROTECTOR > bool > option shell="$CC -Werror -fstack-protector -c -x c /dev/null" Yeah. I do think we want to have the "shell" thing as a generic escape for other things too, but *realistically*, the primary target for this is compiler flags, and I think we should target that specifically with a shorthand. Doing some statistics, and looking for flag = $(call xyz ...) patterns in our makefiles (ignoring single uses), it really is cc-option that dominates: 2 name-fix 2 try-run 3 __cc-option 3 grep-libs 3 strip-libs 4 flags 4 get-executable 4 ld-option 4 logo-cfiles 5 as-option 5 cc-cross-prefix 6 cc-ldoption 6 cc-supports 7 cc-option-yn 7 tune 9 cc-ifversion 30 as-instr 48 cc-disable-warning 239 cc-option so I think that's the one that we want to special-case. If we then have a _usable_ - but perhaps not wonderful "shell" escape to do any random thing (including scripts etc), that will take care of the rest, but cc-option is so common that I think it's worth making a special Kconfig syntax for them. For all I know, the others aren't even worth Kconfig options at all. > I was thinking of something like follows: > > config CC_STACKPROTECTOR > bool > option shell="$(CC_OPTION -fstack-protector)" I think we should go even further, and just make it be config CC_STACKPROTECTOR bool option cc_option="-fstack-protector" and actually have the Kconfig language itself have this special-cased. And obviously that "option cc_option" would be *implemented* as just "option shell", with just some stupid string substitution. So it really would be purely a shorthand for readability. What do you think? And btw, the patches look nice. What I like in particular is that they don't even seem to add a lot of lines: the new shell option code is almost balanced out by the Kconfig script simplifications. And maybe it's just that I read C a lot better than I read GNU Makefile magic, but I think it's more understandable too. Linus
Re: [RFC PATCH 0/7] Kconfig: add new special property shell= to test compiler options in Kconfig
On Fri, Feb 09, 2018 at 01:19:05AM +0900, Masahiro Yamada wrote: > This was prompted by the email from Linus today's morning. > > I implmented this in a rush today, so there are still many TODOs, > but I put it here to start discussion. > > I think it is working, but as you notice, it is tedious to repeat something > like follows: > > config CC_HAS_STACKPROTECTOR > bool > option shell="$CC -Werror -fstack-protector -c -x c /dev/null" > > One possiblity is to put this ugly code into script like follows, > > config CC_STACKPROTECTOR > bool > option shell="$srctree/scripts/cc-option.sh $CC -fstack-protector" > > ... but this is longer. But it's easier to remember and cut/paste from :) > I was thinking of something like follows: > > config CC_STACKPROTECTOR > bool > option shell="$(CC_OPTION -fstack-protector)" Sure, that would be even nicer, if possible. Is it? Anyway, very nice work. I like moving the cache stuff to the .config file, that makes a lot of sense and will be even nicer to see in the /proc/config.gz output for when we are curious as to what the build options really were. thanks, greg k-h
