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