On Wed, Feb 18, 2026 at 11:24 PM Andres Freund <[email protected]> wrote:
> 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.
I don't think we can do this without a gazillion files:
1. If you mean using per file custom_targets like the meson bitcode
patch, that would still require generating stamp files for each
execution, so all we would do is to replace the currently empty object
files with similarly sized stamp files
2. Testing that a header compiles in C++ mode requires adding an
extern C block around the include, so "-include" can't be used. I can
work around that by adding a block such as:
extern "C" {
#include FILENAME_MACRO
}
And a -DFILENAME_MACRO=... flag to the compiler.
But I still have to add ~1400 custom targets to meson, and handle the
compiler flag setup manually instead of the currently automated way
with the static library. I'm not sure if the additional complexity of
the implementation is worth it for this, I don't think we would see
any significant execution time difference.
> 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.
Headerscheck currently also checks internal not installed headers, and
skips installed but generated headers. Should we change these rules?
We also shouldn't add the extensions in contrib into the "main" list,
so that adds a bit of complexity if we somehow want to integrate those
into headerscheck, I'll have to think about that part.
(Otherwise this doesn't sounds like a pain, and would be good practice
to use explicit lists instead of globs for installing files, I'll look
into that)
> 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++.
Also sounds like a good idea, but kind of an independent patch with ifdefs.
On Wed, Feb 18, 2026 at 11:35 PM Andreas Karlsson <[email protected]> wrote:
> Is the plan to use the Python scripts also in the Autotools build? E.g.
> by calling them from the bash script?
Are we ok with adding a python dependency to the autotools build? I
used python for the new script because meson already depends on it,
but I don't think make does.
> I feel this could add a substantial performance hit compared to the
> shell script which uses -fsyntax-only, or am I wrong? Also -Wall seems
> to be missing.
Wall is already added by the meson build, we use exactly the same
configuration flags as for the rest of the build, that's the advantage
of using a static library. "-fsyntax-only" saves only ~2% time vs
generating an empty object file in my benchmarks, and the parallel
ninja execution is several times faster than the bash script, so I
don't think this is a significant difference.
> > * Meson before 1.7 ignores this and builds it anyway
>
> Any idea why? Because this sounds like a potential showstopper since
> Meson 1.7 is rather new.
I'm using a different approach, so this doesn't affect the patch now.
