Hi,
On 2026-02-17 18:40:59 +0100, Álvaro Herrera wrote:
> On 2026-Feb-17, Andres Freund wrote:
>
> > I also think that eventually we should do what you alluded to in a comment,
> > namely make headerscheck an explicit part of the build system, with proper
> > support for dependencies and parallelism.
>
> How would that work? I imagine that there would be a script or program
> that takes a single .h file as argument and returns OK or fail for it;
> then meson knows to run that script once for every .h file in the tree.
Something like that, yes.
Instead of generating a .c file to include the .h, I'd probably try to go for
something like
${CC|CXX} ... -fsyntax-only -include {postgres.h|c.h|postgres_fe.h} -include
header/to/test.h
so that we don't have to generate a gazillion files.
> How to construct the list of files might also be a separate simple
> script that just does "git ls-files *.h" then filters out the files we
> know can't pass the compile.
One disadvantage with doing something like git ls-files at configure is that
meson can't know to rerun that when a new header is added. That's probably
not a huge issue, but worth thinking about.
I have wondered if we should just make it an explicit list of headers that are
to be installed in the source tree that could then be used by both meson/make
install and things like headerscheck. But it might be too much of a pain.
I also wonder if we should deal with things like files known to not be C++
safe by putting some annotation in the header, rather than tracking that in a
script? Might also be used to actually output a more readable error message if
somebody were to include such a header from c++.
> Would it make sense to split our current script into a bunch of smaller
> ones that each does one of these things, so that they can be reused by
> a Meson target in a way that's more convenient? In Make we would just
> call some wrapper script that simply calls the others to do the full job
> in a single pass, the way it is now.
Yes.
Greetings,
Andres Freund
