Thread: pg_config.h.win32

Hi

I examined multibyte psql.exe and libpq.dll Yesterday
according to the bug report from Hiroshi Saito.
At first the compilation didn't work at all and I found
the following in src/win32.mak though it's irrelevant to
the bug report.

ALL:  cd include  if not exist pg_config.h copy pg_config.h.win32 pg_config.h

Currently I'm working under cygwin environment mainly and
the above script doesn't work well after the configure of
cygwin (un??)fortunately. 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.

#ifdef WIN32
#include "pg_config.h.win32"
#else
.
.

?

Comments ?

regards,
Hiroshi Inoue

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

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

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