From: Ben Knoble Date: Mon, 23 Feb 2026 21:41:48 GMT Subject: Re: [PATCH v6] build: regenerate config-list.h when Documentation changes Message-ID: <8AB2DD1B-FAFA-4510-82FA-BBD76B442676@gmail.com> In-Reply-To: > Le 23 févr. 2026 à 01:55, SZEDER Gábor a écrit : > > On Sat, Feb 21, 2026 at 09:07:17AM -0500, D. Ben Knoble wrote: >> The Meson-based build doesn't know when to rebuild config-list.h, so the >> header is sometimes stale. >> >> For example, an old build directory might have config-list.h from before >> 4173df5187 (submodule: introduce extensions.submodulePathConfig, >> 2026-01-12), which added submodule..gitdir to the list. Without >> it, t9902-completion.sh fails. Regenerating the config-list.h artifact >> from sources fixes the artifact and the test. >> >> Since Meson does not have (or want) builtin support for globbing like >> Make, teach generate-configlist.sh to also generate a list of >> Documentation files its output depends on, and incorporate that into the >> Meson build. >> >> We assume that if a user adds a new file under >> Documentation/config then they will also edit one of the existing files >> to include that new file, and that will trigger a rebuild. Also mark the >> generator script as a dependency. >> >> While we're at it, teach the Makefile to use the same "the script knows >> it's dependencies" logic. >> >> For Meson, combining the following commands helps debug dependencies: >> >> ninja -C -t deps config-list.h >> ninja -C -t browse config-list.h >> >> The former lists all the dependencies discovered from our output ".d" >> file (the config documentation) and the latter shows the dependency on >> the script itself, among other useful edges in the dependency graph. >> >> Helped-by: Patrick Steinhardt >> Helped-by: Phillip Wood >> Signed-off-by: D. Ben Knoble >> --- >> >> Notes (benknoble/commits): >> Changes from v5 (<611a94cd988e3795bc63dba2f1b270aa0d058bd2.1771425395.git.ben.knoble+github@gmail.com>): >> >> • Reword a confusing sentence in the commit message >> >> Makefile | 5 +++-- >> generate-configlist.sh | 11 ++++++++++- >> meson.build | 5 ++++- >> 3 files changed, 17 insertions(+), 4 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index 7f37ad8f58..6f926ffb1f 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -2688,9 +2688,10 @@ $(BUILT_INS): git$X >> cp $< $@ >> >> config-list.h: generate-configlist.sh >> + @mkdir -p .depend >> + $(QUIET_GEN)$(SHELL_PATH) ./generate-configlist.sh . $@ .depend/config-list.h.d >> >> -config-list.h: Documentation/*config.adoc Documentation/config/*.adoc >> - $(QUIET_GEN)$(SHELL_PATH) ./generate-configlist.sh . $@ >> +-include .depend/config-list.h.d > > This breaks the build when something disappears from > Documentation/config/: > > $ git checkout origin/seen > HEAD is now at 57edfa3ce8 Merge branch 'ty/setup-error-tightening' into seen > $ ls -l Documentation/config/hook.adoc > -rw-rw-r-- 1 szeder szeder 3828 Feb 23 07:50 Documentation/config/hook.adoc > $ git grep hook.adoc > Documentation/git-hook.adoc:include::config/hook.adoc[] > Documentation/howto/meson.build: 'rebuild-from-update-hook.adoc', > Documentation/meson.build: 'git-hook.adoc' : 1, > $ make V=1 config-list.h > /bin/sh ./generate-configlist.sh . config-list.h .depend/config-list.h.d > $ git checkout 0aabf70f60 > Previous HEAD position was 57edfa3ce8 Merge branch 'ty/setup-error-tightening' into seen > HEAD is now at 0aabf70f60 build: regenerate config-list.h when Documentation changes > $ ls -l Documentation/config/hook.adoc > ls: cannot access 'Documentation/config/hook.adoc': No such file or directory > $ git grep hook.adoc > Documentation/howto/meson.build: 'rebuild-from-update-hook.adoc', > Documentation/meson.build: 'git-hook.adoc' : 1, > $ make V=1 config-list.h > GIT_VERSION=2.53.0.119.g0aabf70f60 > make: *** No rule to make target 'Documentation/config/hook.adoc', needed by 'config-list.h'. Stop. > $ grep hook.adoc .depend/config-list.h.d > config-list.h: ./Documentation/config/hook.adoc Indeed. This might arise while bisecting, which was my original motivation. Thoughts on a path forward? At least this issue (to me) is clearer than a spurious test failure :)