Thread: Simplify passing of configure arguments to pg_config

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.

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

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.  I'm also a bit suspicious of the ad-hoc
escaping step ...

            regards, tom lane

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.

> I'm also a bit suspicious of the ad-hoc escaping step ...

Hmm, the current way doesn't handle embedded quotes at all, so perhaps 
this wouldn't be necessary.  But it would add some robustness.

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

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

On 2019-12-22 14:56, Peter Eisentraut wrote:
>> 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.

committed

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