Yes, that's true. There are also some changes to support general
cross-compilation.
Some more details:
configure.in: if you not using system timezone data,
src/timezone/Makefile builds a zic executable and then runs it to
generate tzdata files. If you are cross compiling this won't work so I
added an option to identify the build system's zic command and use that
instead. You need this for a mingw32 cross compile since there is no
system tzdata on Windows. tzdata files are architecture independent.
The alternative would be to build a host system zic alongside or instead
of the target system zic but that seemed more complex since the
configure script would need to set up for local and target compilation.
src/bin/pgevent/Makefile: fix source and include path for vpath mingw32
compilation.
src/interfaces/ecpg/test/Makefile: use pwd -W if the build system is
mingw32, as opposed to the target system being win32.
src/interfaces/libpq/Makefile: fix include path for vpath mingw32
compilation (to find pthread-win32.h).
src/Makefile.global.in: set ZIC and BUILD_OS variables (the latter to
test for cross-compilation).
src/makefiles/Makefile.win32: fix windres include path for vpath mingw32
compilation.
src/Makefile.shlib: fix value of DLL_DEFFILE so that .def file is
generated in the build tree, not the source tree.
src/timezone/Makefile: use system zic command when cross-compiling
Richard
> Peter Eisentraut wrote:
>
>> On Tuesday 30 December 2008 17:49:16 Richard Evans wrote:
>>
>>> I've taken a look at the current development snapshot ane made a new
>>> patch. This is against the snapshot source dated 2008-12-30.
>>>
>> Half of this patch appears to attempt to fix not cross-compilation problems,
>> but out-of-tree builds (vpath builds). Considering that other developers
>> regularly exercise this, it looks a bit suspicious. Can you clarify your
>> intent?
>>
>
> Hmm, but does anyone test the VPATH build on mingw? It looks like the
> rules being modified are part of that port exclusively.
>
>
