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

On Mon, Nov 3, 2025 at 7:14 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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?

Good questions. Sounds plausible and probably more conventional. It
doesn't work right now but probably only for superficial reasons. But
I also worry about hiding current or future problems and generally
being too blunt. But that's also true of -Dextra_XXX.

> --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.

Yeah. I for one cargo-culted that configure habit across to the new
world, but you can actually build without -Dextra_XXX on FreeBSD and
maybe macOS + MacPorts too with -Dnls=disabled, as long as your $PATH
contains pkg-config (FreeBSD: yes by default, macOS: probably yes if
you can type "meson"). NetBSD handles even -Dnls=enabled thanks to
its built-in libintl, as CI already demonstrates. So I wonder if we
have this only because out-of-libc libintl and pkg-config have some
unresolved beef[1][2]...? Know of any other complications in our
universe or libraries that I might be overlooking?

If that really is the last reason we need this on typical
package-managed non-Linux environments (not sure!)... here's an
experimental patch that probes the conventional paths relative to
msgfmt to hunt for them. They were all compiled from the same source
package by the same packaging pipeline so I think it has pretty good
odds. It's not quite $PATH -> pkg-config -> .pc -> exact results, but
it's ... well, something vaguely similar, instead of nothing. Too
crazy an overreaching assumption, or friendly out-of-the-box support
for lots of common systems including Macs? It passes on all CI OSes.
No loss if it guesses wrong on your DeathStation 9000: you can still
supply -Dextra_XXX as before.

On the flip side, if you stop using a "catch-all" include path, you
have to declare dependencies accurately or some combinations might
break, for example that gssapi I had to add, because the CI macOS task
found Apple's base system OpenSSL and then didn't think it needed any
extra includes, because we forgot to say that libpq_oauth_st also
depends on gssapi. That's an example of a "broad"
-Dextra_include_dirs hiding something that is technically incorrect,
or being forgiving depending on your perspective...

First two patches as before, except for a couple of unnecessary hunks
I deleted based on an off-list review from Bilal.

[1] https://lists.gnu.org/archive/html/bug-gettext/2012-03/msg00022.html
[2] https://lists.nongnu.org/archive/html/bug-gettext/2019-10/msg00003.html