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

On Sat, Nov 1, 2025 at 7:14 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> The patch seems harmless enough to me, no objections to committing it.
> However, I'm worried that we'll soon break it again. The new rule is
> apparently "include libpq first", but we have no way of enforcing it.

Here's a new version of the original approach with fixes for some
copy-and-pastes I'd missed, and a new patch to check the search order
in CI.  It adds a "poisoned" libpq-fe.h header into the search path to
break the build step if you get it wrong in meson or configure (cf
commit 4300d8b6 which fixed a case of this there).  It fails like
this:

[01:45:21.825] In file included from ../src/include/fe_utils/connect_utils.h:15,
[01:45:21.825]                  from ../src/bin/scripts/common.h:13,
[01:45:21.825]                  from ../src/bin/scripts/vacuumdb.c:17:
[01:45:21.825] /tmp/poisoned_headers/libpq-fe.h:1:2: error: #error
"external header hides in-tree header"
[01:45:21.825]     1 | #error "external header hides in-tree header"
[01:45:21.825]       |  ^~~~~

There must surely be a more mesonic way to do this with declarations
rather than the order in a flimsy list that is copied all over the
place (I guess that is probably supposed to be thought of as an
unordered set...?), but I'm not sure I was on the right path with my
v2 as mentioned and it didn't survive this test.  This approach is OK
for now, I think... if someone ever shows up with a patch to tackle it
more fundamentally, the order will presumably become more flexible, so
the new order will still be valid but unimportant.

Will wait another day for a better idea or objection to show up, and
otherwise commit these to 16+.