mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Julian Braha <julianbraha@gmail.com>
To: Erkan Erdem <hexvalid@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier <nsc@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] docs: kconfig: fix shell function syntax in caveats
Date: Sat, 5 Sep 2026 16:03:01 +0100	[thread overview]
Message-ID: <54814f0e-d36e-428f-9255-3c7c2c09b39a@gmail.com> (raw)
In-Reply-To: <20260905124045.42713-1-hexvalid@gmail.com>

Hi Erkan,

Thanks for the patch!

On 9/5/26 13:40, Erkan Erdem wrote:
> Kconfig separates a function name from its arguments with a comma, but
> the caveats section uses Make-style whitespace in its shell calls.
> These expressions expand as undefined variables rather than invoking
> the shell function, so the supposedly working CC_HAS_ENDIAN_FLAG
> example fails to parse.
> 
> Add the missing commas to the shell calls in this section. Keep the
> Make examples unchanged.
> 
> Fixes: 316d55d55f49 ("Documentation: kconfig: document a new Kconfig macro language")
> Assisted-by: LLM
> Signed-off-by: Erkan Erdem <hexvalid@gmail.com>
> ---
> 
> The issue was found and this patch and changelog were prepared with an AI
> coding assistant after a request to find a small, verifiable Linux fix.
> The assistant also prepared and ran the verification described below.
> 
> Validation:
> - Built the current Kconfig conf tool on macOS with Clang, Bison and Flex,
>   using -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror.
> - Extracted the documented working CC_HAS_ENDIAN_FLAG example into a
>   minimal Kconfig, with a test gcc-check-flag helper returning y for either
>   endian flag. Before: syntax errors and no helper invocations for either
>   CPU endianness. After: both probes execute and CC_HAS_ENDIAN_FLAG=y.
> - Built the changed page alone with Sphinx, treating warnings as errors.
>   The complete kernel documentation set and kernel were not built.
> 
>  Documentation/kbuild/kconfig-macro-language.rst | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/kbuild/kconfig-macro-language.rst b/Documentation/kbuild/kconfig-macro-language.rst
> index 6163467f..e15af278 100644
> --- a/Documentation/kbuild/kconfig-macro-language.rst
> +++ b/Documentation/kbuild/kconfig-macro-language.rst
> @@ -225,7 +225,7 @@ not work::
>              $(MY_TYPE) "foo"
>              default y
>  
> -Obviously from the design, $(shell command) is expanded in the textual
> +Obviously from the design, $(shell,command) is expanded in the textual
>  substitution phase. You cannot pass symbols to the 'shell' function.
>  
>  The following does not work as expected::
> @@ -236,12 +236,12 @@ The following does not work as expected::
>              default "-mlittle-endian" if CPU_LITTLE_ENDIAN
>  
>      config CC_HAS_ENDIAN_FLAG
> -            def_bool $(shell $(srctree)/scripts/gcc-check-flag ENDIAN_FLAG)
> +            def_bool $(shell, $(srctree)/scripts/gcc-check-flag ENDIAN_FLAG)

Here, the space after the comma is actually included in the argument.

Checking the tree, I found 20 instances of this, but none of them use
whitespace after the comma. It may be harmless in most (all?) cases, but
we probably want to exclude it when documenting ideal usage, anyway.

I think you got it right in your earlier '$(shell,command)' example.
>  
>  Instead, you can do like follows so that any function call is statically
>  expanded::
>  
>      config CC_HAS_ENDIAN_FLAG
>              bool
> -            default $(shell $(srctree)/scripts/gcc-check-flag -mbig-endian) if CPU_BIG_ENDIAN
> -            default $(shell $(srctree)/scripts/gcc-check-flag -mlittle-endian) if CPU_LITTLE_ENDIAN
> +            default $(shell, $(srctree)/scripts/gcc-check-flag -mbig-endian) if CPU_BIG_ENDIAN
> +            default $(shell, $(srctree)/scripts/gcc-check-flag -mlittle-endian) if CPU_LITTLE_ENDIAN
> 
> base-commit: 4d7d9486c04d917265f64c55bd23b2cc4fe7749c

Same thing here.

- Julian Braha


      reply	other threads:[~2026-09-05 15:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-05 12:40 Erkan Erdem
2026-09-05 15:03 ` Julian Braha [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54814f0e-d36e-428f-9255-3c7c2c09b39a@gmail.com \
    --to=julianbraha@gmail.com \
    --cc=corbet@lwn.net \
    --cc=hexvalid@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®