Skip site navigation (1) Skip section navigation (2)

Re: fix for windows breakage in regression script

From: Reini Urban <rurban(at)x-ray(dot)at>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: fix for windows breakage in regression script
Date: 2005-01-15 17:24:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Andrew Dunstan schrieb:
> Tom Lane wrote:
>> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>>> Tom Lane said:
>>>> [ scratches head... ]  Why isn't the #undef in pg_config_manual.h
>>>> firing on Cygwin?
>>> But on Cygwin, WIN32 is only defined if windows.h has been included (See
>>> previous discussion - I recall advocating NOT using WIN32 as a marker 
>>> for
>>> just this reason).
>> Urgh ... so it's only because windows.h isn't included till later that
>> it works properly.
> It's a lot more subtle than that :-( .  In most cases we end up 
> including windows.h _only_ if WIN32 is already defined, as it is for us 
> by the compiler on MinGW.
> see: 
> and
> w.r.t. Cygwin / unix sockets, the test is in port/cygwin.h, and says:
> #endif
> I don't know how old that is.

This is a perfectly good logic.

>> I'm not sure that we need the code in pg_config_manual.h anymore anyway
>> --- the configure test should be covering this.  But just before release
>> is no time to be fooling with such things.

> agreed.
>> I did add cygwin to the unix_socket=no case in pg_regress, and I'm
>> inclined to leave it that way because it's really the minimal change
>> from the script's previous behavior on cygwin.  Do you see a strong
>> reason for undoing that?
> Well, nothing seems broken - see buildfarm. And if it ain't broke .../

Without sockets it's just a bit slower. Otherwise I don't care.
It should work on Cygwin with and without.
Reini Urban

In response to

pgsql-patches by date

Next:From: Euler Taveira de OliveiraDate: 2005-01-15 22:05:13
Subject: FAQ update: pt_BR
Previous:From: Devrim GUNDUZDate: 2005-01-15 13:51:31
Subject: Latest Turkish translation updates

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group