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
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 |