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

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-02-03T00:28:40Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. ci: Add missing "set -e" to scripts run by su.

  2. Don't put library-supplied -L/-I switches before user-supplied ones.

Attachments

When I use configure/make and --with-includes=/usr/local/include, I
see compile lines like this:

... -I../../src/interfaces/libpq -I../../src/include  -I/usr/local/include ...

That's important, because if I happen to have libpq headers installed
on the system I don't want to be confused by them.  Yet meson's
-Dextra_include_dirs=/usr/local/include compiles like this:

... -I../src/include -I/usr/local/include -Isrc/interfaces/libpq ...

... which gives me errors due to the v16 headers I happen to have installed:

../src/fe_utils/connect_utils.c:164:3: error: unknown type name
'PGcancelConn'; did you mean 'PGcancel'?
  164 |                 PGcancelConn *cancelConn = PQcancelCreate(conn);

I guess this affects Macs, BSDs and a few lesser used Linux distros
that put optional packages outside the base system and default search
paths.  Perhaps you can see this on everything-goes-into-base-system
distros if you redundantly say -Dextra_include_dirs=/usr/include; I
didn't check if that is true, it wouldn't be if meson is opinionated
enough to remove it.

Reordering obvious mentions of libpq, as in the attached, gets past
most of them but I couldn't immediately figure out how to reorder
src/test/isolation/meson.build and gave up and uninstalled the
interfering libpq package for now.  Dumping these observations here as
this is as far as I got with this impediment today.