public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: "D. Ben Knoble" <ben.knoble+github@gmail.com>
Cc: git@vger.kernel.org, Phillip Wood <phillip.wood@dunelm.org.uk>,
	Junio C Hamano <gitster@pobox.com>,
	Evan Martin <evan.martin@gmail.com>
Subject: Re: [PATCH v3] meson: regenerate config-list.h when Documentation changes
Date: Thu, 12 Feb 2026 09:06:02 +0100	[thread overview]
Message-ID: <aY2J6lcBC4Gcy-SK@pks.im> (raw)
In-Reply-To: <0a344f1f3ee4a5d95c6f46df030b9936db4354a1.1770853297.git.ben.knoble+github@gmail.com>

On Wed, Feb 11, 2026 at 06:51:02PM -0500, D. Ben Knoble wrote:
> Notes (benknoble/commits):
>     Changes from v2 (<c9ae171eed6bd5b0fa6671b10a5ad0da024f36d0.1770649805.git.ben.knoble+github@gmail.com>):
>     
>     • Pick up (and tweak) Patrick's depfile proposal
>     • Include the script itself as a dependency
>     • Escape output paths (spaces, octothorpes, and backslashes) for Ninja
>     
>     I'm not 100% sure I've actually done the escaping correctly, though,
>     since Ninja's source says that a space preceded by 2N backslashes
>     represents 2N backslashes at the end of a filename, and

I guess you refer to [1], more specifically this quote:

  Rather than implement all of above, we follow what GCC/Clang produces:

      Backslashes escape a space or hash sign.

      When a space is preceded by 2N+1 backslashes, it is represents N
      backslashes followed by space.

      When a space is preceded by 2N backslashes, it represents 2N
      backslashes at the end of a filename.

      A hash sign is escaped by a single backslash. All other
      backslashes remain unchanged.

>         λ printf '%s\n' 'foo\' | sed 's/[# \\]/\\&/g' | xxd
>         00000000: 666f 6f5c 5c0a                           foo\\.
>     
>     So would they interpret that as the filename 'foo\\' instead of 'foo\' ?
>     (Or, no because the 2N slashes aren't followed by a SP, but a NL?)

I think it would be interpreted as "foo\\". I would say that we really
don't need to go too much into detail here. I very much hope that no
sane person would have literal "\ " in their paths. One might wonder
about Windows, where backslashes are common. But filenames cannot start
with a space there, so this is fine.

So I'd say we should only care about quoting ' ' and '#', nothing else.
We can still iterate going forward if we see that we're too naive.

>  generate-configlist.sh | 10 +++++++++-
>  meson.build            |  4 +++-
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/generate-configlist.sh b/generate-configlist.sh
> index 75c39ade20..091efd4564 100755
> --- a/generate-configlist.sh
> +++ b/generate-configlist.sh
> @@ -36,3 +37,10 @@ print_config_list () {
>  	echo
>  	print_config_list
>  } >"$OUTPUT"
> +
> +if test -n "$DEPFILE"
> +then
> +	printf "$OUTPUT: %s\n" "$0" "$SOURCE_DIR"/Documentation/*config.adoc \

I think it's a tiny bit hacky that we output the script itself as a
dependency here, and that it would be cleaner to do this via
`depend_files` in the target itself.

> +	    "$SOURCE_DIR"/Documentation/config/*.adoc |
> +	    sed 's/[# \\]/\\&/g' >"$DEPFILE"
> +fi

From the above rules I would think that we should simply ignore
backslashes here. As the last rule says, "All other backslashes remain
unchanged.".

> diff --git a/meson.build b/meson.build
> index 3a1d12caa4..fb5d7367f5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -720,11 +720,13 @@ endif
>  
>  builtin_sources += custom_target(
>    output: 'config-list.h',
> +  depfile: 'config-list.h.d',
>    command: [
>      shell,
> -    meson.current_source_dir() + '/generate-configlist.sh',
> +    meson.current_source_dir() / 'generate-configlist.sh',
>      meson.current_source_dir(),
>      '@OUTPUT@',
> +    '@DEPFILE@',

I didn't know about `@DEPFILE@`, nice.

Thanks!

Patrick

[1]: https://github.com/ninja-build/ninja/blob/cc60300ab94dae9bb28fece3c9b7c397235b17de/src/depfile_parser.in.cc#L27

  reply	other threads:[~2026-02-12  8:06 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-07 21:59 [PATCH] meson: regenerate config-list.h when Documentation changes D. Ben Knoble
2026-02-07 22:38 ` Ben Knoble
2026-02-09 15:19 ` [PATCH v2] " D. Ben Knoble
2026-02-11 23:51   ` [PATCH v3] " D. Ben Knoble
2026-02-12  8:06     ` Patrick Steinhardt [this message]
2026-02-12 10:29     ` Phillip Wood
2026-02-12 14:14       ` Phillip Wood
2026-02-12 15:56     ` Ben Knoble
2026-02-16 22:28     ` [PATCH v4] " D. Ben Knoble
2026-02-17  0:33       ` Ben Knoble
2026-02-17  7:03         ` Patrick Steinhardt
2026-02-17 13:28           ` D. Ben Knoble
2026-02-17  7:02       ` Patrick Steinhardt
2026-02-17 13:28         ` D. Ben Knoble
2026-02-17 20:24           ` Junio C Hamano
2026-02-17  9:20       ` Phillip Wood
2026-02-17 13:38         ` D. Ben Knoble
2026-02-17 15:11           ` Phillip Wood
2026-02-18 14:37       ` [PATCH v5] build: " D. Ben Knoble
2026-02-19 10:19         ` Phillip Wood
2026-02-19 13:40           ` D. Ben Knoble
2026-02-19 13:56         ` Patrick Steinhardt
2026-02-21 13:58           ` D. Ben Knoble
2026-02-19 15:10         ` Marc Branchaud
2026-02-21 13:58           ` D. Ben Knoble
2026-02-21 14:07         ` [PATCH v6] " D. Ben Knoble
2026-02-23  6:37           ` Patrick Steinhardt
2026-02-23  6:55           ` SZEDER Gábor
2026-02-23 21:41             ` Ben Knoble
2026-02-24  9:58               ` Patrick Steinhardt
2026-02-24 11:00                 ` Phillip Wood
2026-02-24 14:12                   ` D. Ben Knoble
2026-02-24 14:39           ` [PATCH v7] " D. Ben Knoble
2026-02-25 18:45             ` Junio C Hamano
2026-02-26  3:20               ` Ben Knoble
2026-02-09 15:25 ` [PATCH] meson: " Patrick Steinhardt
2026-02-09 21:50   ` D. Ben Knoble
2026-02-11  7:42     ` Patrick Steinhardt
2026-02-11  9:44       ` Phillip Wood
2026-02-11 10:57         ` Phillip Wood
2026-02-11 11:00           ` Patrick Steinhardt
2026-02-11 10:58         ` Patrick Steinhardt
2026-02-11 14:05           ` Phillip Wood
2026-02-11 20:15             ` D. Ben Knoble
2026-02-11 19:58       ` D. Ben Knoble
2026-02-12  8:10         ` Patrick Steinhardt

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=aY2J6lcBC4Gcy-SK@pks.im \
    --to=ps@pks.im \
    --cc=ben.knoble+github@gmail.com \
    --cc=evan.martin@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    /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