Re: Headerscheck support for meson

From: Andres Freund <andres(at)anarazel(dot)de>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Headerscheck support for meson
Date: 2026-02-18 23:24:30
Message-ID: 33wusv6jgyvm4tqw7ibjsh5vutnh3gyleyerkdzcv4mhf2ijmh@wkirx27m67ku
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-02-18 23:27:14 Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta
Previous Message Andres Freund 2026-02-18 23:12:47 Re: pg_stat_io_histogram