Обсуждение: 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