Re: meson's in-tree libpq header search order vs -Dextra_include_dirs - Mailing list pgsql-hackers

On Wed, Nov 5, 2025 at 8:55 AM Andres Freund <andres@anarazel.de> wrote:
> The problem is caused by us adding extra_include_dirs to postgres_inc_d, which
> does not include the private include dir for e.g. libpq. As it is added to
> frontend_code etc as a flat list, there's no way for meson to know that
> src/interfaces/libpq should be added earlier in the commandline.

Check.

> The position we add extra_include_dirs right now also seems wrong on windows,
> leaving libpq aside, as it's added *before* src/include/port/win32 etc.

Yeah.

> The easiest way to fix that seems to be to simply not extra_include_dirs to
> postgres_inc_d, but instead either add it to cppflags (the meson variable, not
> the environment) or add it to the project C flags.

I see.  Similar to what Tristan said except higher level than having
the human write command line arguments -I/foo/bar as C/CPP flags.  I
actually tried to do something like that myself early on, but I
couldn't figure out how to expand include directories to command line
arguments using meson machinery, as it does for dependencies.  I had a
notion that raw -I strings weren't OK, but I see that we already do
that while probing perl.

> It seems that with autoconf we add the --with-includes to the pg_config
> --cppflags, but we don't today with meson. Adding it to the cppflags variable
> would take care of that too.

Right!

To experience a problem I suppose you'd need meson-built PostgreSQL, an
extension running pg_config, and a PostgreSQL header that wants to
include something from an external package on a platform that puts
them outside the base system, and that hasn't come up in the wild yet.
Meson adoption in the relevant packaging projects may not be happening
yet.

> A quick prototype of that is attached.

I think where cc.find_library() probe headers, we need
s/header_include_directories: postgres_inc/header_args: test_c_args/.
Otherwise for example the libintl probe fails on my system, and in
that particular case it doesn't seem necessary to probe the header
anyway so that can just be removed.

Similarly, cc.has_function() and cc.has_header() could probably drop
include_directories as they already have test_c_args, as long as they
are probing external libraries.

Some probes do still need postgres_inc, though: I think it's the
category that is testing OS headers, but we've interposed a bunch of
wrappers on Windows eg sockets.  Maybe that's confusing enough that we
should just leave postgres_inc everywhere but supplement it with
header_args: test_c_args where it's missing, or should we add
postgres_inc to test_c_args?

With extra_include_dirs in cpp_flags, bitcode_cflags also needs to be
reordered, or else:

... clang ... -I/usr/local/include -I./src/include
-I./src/backend/utils/misc -I../src/include
../src/include/c.h:113:9: warning: 'pg_restrict' macro redefined
[-Wmacro-redefined]
  113 | #define pg_restrict restrict
      |         ^
/usr/local/include/pg_config.h:806:9: note: previous definition is here
  806 | #define pg_restrict __restrict
      |         ^

I have some rough patches for those changes...

I think there might be a fundamental problem with this though.
Although it fixes my original complaint today, all it would take to
make it break again would be something to appear with "dependencies:
[<something-found-by-pkg-config> libpq]", or libintl with the v4-0003
patch I posted yesterday (which finds the headers and declares the
dependency, an extended fuzzy version of the sort of thing meson does
inside dependency(...) IIUC,  the point of my patch being to make it
so that you don't need -Dextra_include_dirs at all on Macs and *BSD).
In other words, this problem isn't really just about
extra_include_dirs, it's also about paths produced by dependencies,
which can bring external libpq-fe.h back into visibility.  Hence my
attempt to engage with the dependency system.