Re: [PATCH] meson: regenerate config-list.h when Documentation changes

> On 11/02/2026 07:42, Patrick Steinhardt wrote:
> > On Mon, Feb 09, 2026 at 04:50:06PM -0500, D. Ben Knoble wrote:
> > > > On Sat, Feb 07, 2026 at 04:59:17PM -0500, D. Ben Knoble wrote:
> > [snip]
> > > Only, things are behaving oddly. For example:
> > > 
> > >      λ meson setup build2
> > >      λ ninja -C build2
> > > 
> > > works fine, but
> > > 
> > >      λ ls -l build2/config*
> > >      -rw-r--r-- 1 benknoble benknoble 17169  9 févr. 16:39 build2/config-list.h
> > > 
> > > I don't see the dependency file.
> > 
> > > Further, re-building seems to get stuck (I get
> > > similar symptoms if I add or remove a relevant config.adoc file, but let's keep
> > > it simple for now):
> > > 
> > >      λ ninja -C build2
> > >      ninja: Entering directory `build2'
> > >      [1/28] Generating GIT-VERSION-FILE with a custom command (wrapped by meson to set env)
> > 
> > With "stuck" you mean that it doesn't do anything, or that it doesn't
> > actually rebuild?
> > 
> > I guess it kind of makes sense that a new file wouldn't trigger a
> > rebuild, even though I would have expected a removed one to trigger one.
> > After all, the dependency file only tracks the set of _existing_ files
> > so that we know when to rebuild, and of course the dependency file only
> > gets regenerated in case any of those files changes.
> 
> If anyone adds a new file under Documentation/config/ they will need to
> update Documentation/config.adoc which should then trigger the rebuild. That
> rebuld will then add the new file to the list of dependencies. If they
> remove a file we should pick that up with the dependencies that are already
> listed.

> > The thing is that build systems like Meson really want to know the list
> > of files ahead of time so that they can have an optimal build graph. So
> > we could of course list all the files that we actually depend on. But I
> > guess that's something we want to avoid?
> > 
> > There's another, alternative approach: you can have a separate build
> > step that's marked as `build_always_stale: true` that lists all the
> > config files. This step would then always run, and it would only update
> > its target file in case any of the files has changed.
> 
> It would be really nice if we can avoid regenerating the depfile with every
> build.