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@partin.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)