Re: meson's in-tree libpq header search order vs -Dextra_include_dirs - Mailing list pgsql-hackers

From Andres Freund
Subject Re: meson's in-tree libpq header search order vs -Dextra_include_dirs
Date
Msg-id 2q55w253wxssh42krubzta2f2giakyagcmusie5gpjqy2zjnxs@aaarowf2ab7c
Whole thread Raw
In response to Re: meson's in-tree libpq header search order vs -Dextra_include_dirs  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: meson's in-tree libpq header search order vs -Dextra_include_dirs
List pgsql-hackers
Hi,

On 2025-11-04 18:30:51 +1300, Thomas Munro wrote:
> First two patches as before, except for a couple of unnecessary hunks
> I deleted based on an off-list review from Bilal.

I think there may be a less verbose way to do this:

The problem is caused by us adding extra_include_dirs to postgres_inc_d, which
does not include the private include dir for e.g. libpq. As it is added to
frontend_code etc as a flat list, there's no way for meson to know that
src/interfaces/libpq should be added earlier in the commandline.

The position we add extra_include_dirs right now also seems wrong on windows,
leaving libpq aside, as it's added *before* src/include/port/win32 etc.


The easiest way to fix that seems to be to simply not extra_include_dirs to
postgres_inc_d, but instead either add it to cppflags (the meson variable, not
the environment) or add it to the project C flags.

It seems that with autoconf we add the --with-includes to the pg_config
--cppflags, but we don't today with meson. Adding it to the cppflags variable
would take care of that too.

A quick prototype of that is attached.

Thoughts?

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_plan_advice
Next
From: Tom Lane
Date:
Subject: Re: Add notification on BEGIN ATOMIC SQL functions using temp relations