Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vFnqF-001LXa-C2 for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Nov 2025 06:14:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vFnqD-00HV9g-Vm for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Nov 2025 06:14:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vFnqD-00HV9X-Lf for pgsql-hackers@lists.postgresql.org; Mon, 03 Nov 2025 06:14:56 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vFnqA-005hFR-15 for pgsql-hackers@postgresql.org; Mon, 03 Nov 2025 06:14:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5A36Em78230129; Mon, 3 Nov 2025 01:14:48 -0500 From: Tom Lane To: "Tristan Partin" cc: "Thomas Munro" , "pgsql-hackers" Subject: Re: meson's in-tree libpq header search order vs -Dextra_include_dirs In-reply-to: References: Comments: In-reply-to "Tristan Partin" message dated "Mon, 03 Nov 2025 05:43:58 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <230127.1762150488.1@sss.pgh.pa.us> Date: Mon, 03 Nov 2025 01:14:48 -0500 Message-ID: <230128.1762150488@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Tristan Partin" 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 not sure that the meson crew have learned all that yet. But this does not suggest to me that they know more than we do. regards, tom lane