Re: exposing pg_controldata and pg_config as functions

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Josh berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: exposing pg_controldata and pg_config as functions
Date: 2016-02-19 03:15:37
Message-ID: CAB7nPqQ3rHmi_sGqM23vnBu6WPkcJDSWKiP9F8jTZ2WNqzSryw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 19, 2016 at 11:53 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 2/18/16 12:20 PM, Joe Conway wrote:
>> Just to be clear, AFAIK there is no issue with the committed changes on
>> Windows. If there is please provide a concrete example that we can discuss.
>
> Originally it was mentioned that this feature could be used in the
> regression tests by making certain tests conditional on configure
> options. Which presumably won't work if the build was on Windows.

MSVC code passes VAL_CONFIGURE to pg_config.h by calling
GetFakeConfigure() and make the output of pg_config consistent with
when ./configure is used. So for CONFIGURE I see no issues. Things
like CPPFLAGS or LIBS though become listed as "not recorded" with this
change so the output of pg_config is more verbose when MSVC is used.
This still seems an acceptable trade-off even after reviewing this
patch to make this information available on the backend. And it seems
as well that this would become set, at least partially, when using
cmake build instead of the MSVC cruft in src/tools/msvc.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2016-02-19 03:20:21 Re: about google summer of code 2016
Previous Message Chapman Flack 2016-02-19 02:59:24 Re: about google summer of code 2016