Re: meson's in-tree libpq header search order vs -Dextra_include_dirs

On Mon Nov 3, 2025 at 12:14 AM CST, Tom Lane wrote:
> "Tristan Partin" <tristan(at)partin(dot)io> writes:
>> What is the benefit of -Dextra_include_dirs when you could use -Dc_flags
>> or CFLAGS to specify extra include directories? If you tried either of
>> those as an alternative, would they fix the issue? The existence of the
>> option goes all the way back to the initial commit of the meson port, so
>> I presume it exists to mirror --with-includes, but why does that exist?
>
> --with-includes, and likewise --with-libs, exist because there are
> platforms that require it. For example, on pretty much any
> BSD-derived system, the core /usr/include and /usr/lib files are very
> limited and you'll need to point at places like /usr/pkg/include or
> /opt/local/include or whatever to pull in non-core packages.
>
> I see your point about putting -I flags into CFLAGS, but what you
> are missing is that the order of these flags is unbelievably critical,
> so "just shove it into CFLAGS" is a recipe for failure, especially
> if you haven't even stopped to think about which end to add it at.
> We've learned over decades of trial-and-error with the makefile system
> that treating -I and -L flags specially is more reliable. (See for
> example all the logic in our autoconf scripts to forcibly separate
> -I and -L out of sources like pkg-config. Tracing that stuff back to
> the originating commits and mail discussions would be a constructive
> learning exercise.)

I'm well aware of ordering dependencies, and how annoying they can be.
The perils of C will outlive us all! Given your message and Thomas's
patch, I decided to take a look at the autotools build on PG 16 (since
that is what I had checked out, but maybe also maybe useful as the
original Meson build) and how it compared. Thomas has this hunk in his
patch:

diff --git a/src/test/isolation/meson.build b/src/test/isolation/meson.build
index a180e4e2741..660b11eff8b 100644
--- a/src/test/isolation/meson.build
+++ b/src/test/isolation/meson.build
@@ -35,7 +35,7 @@ pg_isolation_regress = executable('pg_isolation_regress',
isolation_sources,
c_args: pg_regress_cflags,
include_directories: pg_regress_inc,
- dependencies: [frontend_code, libpq],
+ dependencies: [libpq, frontend_code],
kwargs: default_bin_args + {
'install_dir': dir_pgxs / 'src/test/isolation',
},
@@ -52,7 +52,7 @@ endif
isolationtester = executable('isolationtester',
isolationtester_sources,
include_directories: include_directories('.'),
- dependencies: [frontend_code, libpq],
+ dependencies: [libpq, frontend_code],
kwargs: default_bin_args + {
'install_dir': dir_pgxs / 'src/test/isolation',
},

Taking a look, specifically, at isolationtester, I get the following
final compilation line for isolationtester.o (please forgive the macOS garbage):

gcc -Wall -Wmissing-prototypes -Wpointer-arith \
-Wdeclaration-after-statement -Werror=vla \
-Werror=unguarded-availability-new -Wendif-labels \
-Wmissing-format-attribute -Wcast-function-type \
-Wformat-security -fno-strict-aliasing -fwrapv \
-fexcess-precision=standard -Wno-unused-command-line-argument \
-Wno-compound-token-split-by-macro -Wno-format-truncation \
-Wno-cast-function-type-strict -O2 -I. \
-I/Users/tristan.partin/Projects/work/postgres/build-autotools/../src/test/isolation \
-I/Users/tristan.partin/Projects/work/postgres/build-autotools/../src/interfaces/libpq \
-I/Users/tristan.partin/Projects/work/postgres/build-autotools/../src/test/isolation/../regress \
-I../../../src/include \
-I/Users/tristan.partin/Projects/work/postgres/build-autotools/../src/include \
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX26.0.sdk \
-c -o isolationtester.o \
/Users/tristan.partin/Projects/work/postgres/build-autotools/../src/test/isolation/isolationtester.c

The first include directory that isn't the source or build directory is
the in-tree libpq headers. I assume that is controlled by:

override CPPFLAGS := -I. -I$(srcdir) -I$(libpq_srcdir) \
-I$(srcdir)/../regress $(CPPFLAGS)

Thomas's patch seemingly makes the meson build equivalent to the
autotools build. Just for good measure, following --with-includes, the
include directories in that configure argument end up in CPPFLAGS:

CPPFLAGS="$CPPFLAGS $INCLUDES"

where INCLUDES is:

#
# Include directories
#
ac_save_IFS=$IFS
IFS="${IFS}${PATH_SEPARATOR}"
# SRCH_INC comes from the template file
for dir in $with_includes $SRCH_INC; do
if test -d "$dir"; then
INCLUDES="$INCLUDES -I$dir"
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: *** Include directory $dir does not exist." >&5
$as_echo "$as_me: WARNING: *** Include directory $dir does not exist." >&2;}
fi
done
IFS=$ac_save_IFS

From my perspective, it looks like the autotools build has just been
_lucky_ to avoid this problem. I don't see anything that inherently
prevents the problem that Thomas ran into. In my opinion Thomas's patch
is just a parity patch. It's incredible that it took this long to find.

--
Tristan Partin
Databricks (https://databricks.com)