[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzu8+yaAGvdZMRYJWWZmv_OnFnocnvUiSKcAyNQ1z9kmQ@mail.gmail.com>
Date: Mon, 19 Feb 2018 10:01:49 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ulf Magnusson <ulfalizer@...il.com>
Cc: Masahiro Yamada <yamada.masahiro@...ionext.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
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_.
Which is actually what we want there.
Hmm? Is that too nasty?
Linus
Powered by blists - more mailing lists