Re: [PATCH 11/23] kconfig: add 'shell-stdout' function
From: Masahiro Yamada
Date: Wed Feb 21 2018 - 00:00:59 EST
2018-02-20 3:01 GMT+09:00 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>:
> On Mon, Feb 19, 2018 at 9:44 AM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> I do like your "success"/"stdout" more than "shell"/"shell-stdout",
>> because with that naming I don't get the feeling that one should
>> subsume the other.
>
> Hmm. Thinking about it some more, I really would prefer just "$(shell
> ...)" everywhere.
>
> But it would be nice if perhaps the error handling would match the
> context somehow.
>
> I'm wondering if this might tie into the whole quoting discussion in
> the other thread.
>
> Because the rule could be:
>
> (a) unquoted $(shell ) is a bool, and failing is ok (and turns into
> y/n depending on whether successful or failing)
>
> So
>
> config CC_IS_GCC
> bool
> default $(shell $CC --version | grep -q gcc)
>
> works automatically.
>
> (b) but with quoting, $(shell ) is a string, and failing is an error
>
> So
>
> config GCC_VERSION
> int
> default "$(shell-stdout $srctree/scripts/gcc-version.sh $CC
> | sed 's/^0*//')" if CC_IS_GCC
> default 0
>
> would need those quotes, and if the shell-script returns a failure,
> we'd _abort_.
GCC_VERSION is int type.
Setting aside the Kconfig internal, I prefer 50700 to "50700"
According to my common sense, I do not want to quote integers.
IMO, I prefer to use different names for different purpose.
So, 'stdout' and 'success' look good to me.
BTW, I noticed just one built-in function is enough
because 'success' can be derived from 'stdout'.
So, my plan is, implement $(shell ...) as a built-in function.
This returns the stdout from the command.
Then, implement 'success' as a textual shorthand
by using macro, like this:
macro success $(shell ($(1) && echo y) || echo n)
macro can be expanded recursively, so cc-option
can be implemented based on 'success' macro.
--
Best Regards
Masahiro Yamada