Re: pg_config.h.win32 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_config.h.win32
Date
Msg-id 9744.1006544099@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_config.h.win32  (Hiroshi Inoue <Inoue@tpf.co.jp>)
List pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Tom Lane wrote:
>> I'm also not seeing why #including one file in the other would make
>> that problem better?

> ??? I'm changing my pg_config.h locally in reality
> like as follows.

> #ifdef WIN32
> #include "pg_config.h.win32"
> #else
> .
> . (the original content of pg_config.h)
> .
> #endif /* WIN32 */

Hmm.  This would only help if you'd successfully run configure (so that
pg_config.h has been created from pg_config.h.in) and then you wanted to
use that same source tree to compile for native Windows, *without* doing
a "make distclean" which is normally considered a required step before
using a source tree to build for a different platform.

That seems like an ugly way to proceed.  Even if it works today, I would
not want to make a commitment that it will continue to work in future.
I'd rather not uglify pg_config.h.in for all platforms in service of
a one-platform-pair hack that I'd call unsupported anyway...

Out of curiosity, how much difference is there between pg_config.h built
on Cygwin/Windows and pg_config.h.win32?  Obviously the one is a lot
bigger, but if you simply used the Cygwin pg_config.h to build the stuff
that works on native Windows, how far is it from working?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: v7.2b3 packages rebuilt ...
Next
From: "Marc G. Fournier"
Date:
Subject: Re: v7.2b3 packages rebuilt ...