Re: headerscheck warnings with late-model gcc

Hi,

On 2025-08-07 10:58:56 -0400, Tom Lane wrote:
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> > kwlist_d.h doesn't show up in my run, probably because I'm using a
> > separate build directory, which headerscheck doesn't handle? Another
> > thing to fix.
>
> Yeah, as it stands headerscheck is really only meant for in-tree
> builds. We will definitely have to do something about that to make
> it handle built headers in meson builds, and I guess it'd be nice if
> VPATH works that way as well. One idea could be to redefine it as
> searching the installation include-file tree instead of the source
> tree, so that the build process washes out of the matter.

One thing I dislike rather intensely about cpluspluscheck/headerscheck is that
they're abominally slow and thus can't just be executed as part of normal
compile-test-edit cycles. That's obviously due to a) not being incremental b)
not being parallel.

The reason I bring that up here is that the fix for that would be to move the
iteration over all headers from headerscheck to the build system, which then
could perform the check only if headers changed and in parallel. That'd
obviously also address VPATH / meson builds.

The challenge with that is the buildsystem needs to be aware of the list of
headers. However, if we had that awareness, we'd gain two additional benefits:

1) The compile_commands.json that meson generates would provide the
information necessary to compile headers, which would allow editors to do
auto-completion etc for header files.

2) We'd be able to install headers with meson using an explicit list, rather
than the install_subdir(), which has issues with editor files as mentioned
in src/include/meson.build

It's possible to do this by globing for files at configure time, but that
wouldn't detect adding new headers (which would need to trigger a
re-configure). Whether that's an issue worth caring about I'm a bit on the
fence about.

Greetings,

Andres Freund