[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNAT1QNMrHL_JikeEk1ejen-03u_vwkdQmHhHxrxHLtaa0Q@mail.gmail.com>
Date: Wed, 21 Feb 2018 13:59:59 +0900
From: Masahiro Yamada <yamada.masahiro@...ionext.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ulf Magnusson <ulfalizer@...il.com>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>,
Kees Cook <keescook@...omium.org>,
Randy Dunlap <rdunlap@...radead.org>,
Sam Ravnborg <sam@...nborg.org>,
Michal Marek <michal.lkml@...kovi.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 11/23] kconfig: add 'shell-stdout' function
2018-02-20 3:01 GMT+09:00 Linus Torvalds <torvalds@...ux-foundation.org>:
> On Mon, Feb 19, 2018 at 9:44 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> 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
Powered by blists - more mailing lists