Re: Simplify passing of configure arguments to pg_config - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Simplify passing of configure arguments to pg_config
Date
Msg-id c05b3907-8187-5e9c-2db8-6f9abaecf884@2ndquadrant.com
Whole thread Raw
In response to Re: Simplify passing of configure arguments to pg_config  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Simplify passing of configure arguments to pg_config  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 2019-12-04 11:30, Peter Eisentraut wrote:
> On 2019-12-03 06:03, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> Currently, configure puts the configure args into the makefiles and
>>> then have the makefiles pass them to the build of pg_config.  That looks
>>> like an unnecessary redirection, and indeed that method was
>>> put in place when pg_config was a shell script.  We can simplify that
>>> by having configure put the value into pg_config.h directly.  This
>>> also makes the standard build system match how the MSVC build system
>>> already does it.
>>
>> I dunno, is this really an improvement?  It makes the handling of
>> VAL_CONFIGURE different from every other one of the values passed
>> into pg_config, and I don't see any countervailing addition of
>> some other regularity.
> 
> The other values come from the makefiles, so we have to do it that way.
> The configure args come from configure, so why make them go through the
> makefile?  (PG_VERSION also comes in that way. ;-) )
> 
> There is also the weird difference with how the MSVC build system
> handles it.  It appends VAL_CONFIGURE to pg_config.h instead of passing
> it on the command line.

Here is an updated version of the patch after the removal of 
pg_config.h.win32.  It's easier to see now how this helps unify the 
handling of this between the two build systems.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Philippe BEAUDOIN
Date:
Subject: Re: proposal: schema variables
Next
From: Tom Lane
Date:
Subject: Avoiding a small risk of failure in timestamp(tz) regression tests