pg_config.h.win32

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

It's pretty painful and risky to
change pg_config.h.win32 and the original pg_config.h.
How about including pg_config.h.win32 in pg_config.h e.g.

What? I thought pg_config.h.win32 was a substitute pg_config.h
to use for native-windows builds (where you can't run autoconf).
Under cygwin I think you should just run configure and expect it
to produce a correct pg_config.h by itself. If it doesn't, we
need to fix the configure script.

regards, tom lane

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

Must I double the source tree for cygwin and native
Windows ? I'm using the common source tree for ODBC
and there's no problem for compilation.

What? I don't quite follow what the problem is.

regards, tom lane

Tom Lane wrote:

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

It's pretty painful and risky to
change pg_config.h.win32 and the original pg_config.h.
How about including pg_config.h.win32 in pg_config.h e.g.

What? I thought pg_config.h.win32 was a substitute pg_config.h
to use for native-windows builds (where you can't run autoconf).
Under cygwin I think you should just run configure and expect it
to produce a correct pg_config.h by itself. If it doesn't, we
need to fix the configure script.

Must I double the source tree for cygwin and native
Windows ? I'm using the common source tree for ODBC
and there's no problem for compilation. It seems
pretty absurd to have the whole source tree only
for native-windows clients but it's pretty annoying
to download only necessary files.

regards,
Hiroshi Inoue

Tom Lane wrote:

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

Must I double the source tree for cygwin and native
Windows ? I'm using the common source tree for ODBC
and there's no problem for compilation.

What? I don't quite follow what the problem is.

pg_config.h generated under cygwin doesn't fit
in with native-windows. Of cource pg_config.h.win32
doesn't fit in with cygwin either.

regards,
Hiroshi Inoue

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

pg_config.h generated under cygwin doesn't fit
in with native-windows. Of cource pg_config.h.win32
doesn't fit in with cygwin either.

Should it? I'm quite content to regard them as separate platforms.
I don't expect LinuxPPC and Mac OSX to share a pg_config.h, even
though I run them on the same box.

I'm also not seeing why #including one file in the other would make
that problem better?

regards, tom lane

Tom Lane wrote:

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

pg_config.h generated under cygwin doesn't fit
in with native-windows. Of cource pg_config.h.win32
doesn't fit in with cygwin either.

Should it? I'm quite content to regard them as separate platforms.
I don't expect LinuxPPC and Mac OSX to share a pg_config.h, even
though I run them on the same box.

Yes but the current native-windows stuff doesn't seem
valuable to keep a separate source tree.

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

There's no problem to compile under both cygwin
and native-windows. It's much safer than replacing
pg_config.h.win32 and the original pg_config.h each
time.

regards,
Hiroshi Inoue

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

Tom Lane wrote:

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

I see. I'm not responsible for libpq.dll and psql.exe anyway.
Someone would check it as before.

regards,
Hiroshi Inoue