Jan Wieck writes:
> We focused on porting the programs. The goal was to have PostgreSQL
> running native on Win32 for a user. Having a nice and easy maintainable
> cross platform config, build and test environment for the developers is
> definitely something that still needs to be done (hint, hint).
I have prepared a little patch that makes room for a native Windows build
in our existing build framework. The Cygwin port would be renamed to
"cygwin" and the new port takes over the "win" name. I have prepared the
port specific template and makefile and extracted the dynaloader from your
patch, so that you can at least run configure under Cygwin or MinGW
successfully.
Then I suggest we merge in the obvious parts of your patch, especially the
renaming of various token constants, the shmem implementation, some
library function reimplementations. In some cases I would like a bit more
abstraction so that we don't have so many #ifdef's. (For example, we
could have a IsAbsolutePath() that works magically for all platforms.)
Then there are the hairy pieces. You add a bunch of command-line options
that interact in puzzling way to communicate information about the fake
fork. I think some of these are redundant, but it's hard to tell.
The reimplementation of various shell scripts in C is something that would
be a good idea on Unix as well for a number of reasons. Unfortunately,
the ones you wrote have no chance of compiling under Unix, so we'll have
to do it again. But that can happen in parallel to the other stuff.
Two quick questions: Why PG_WIN32 and not just WIN32? Can the ConsoleApp
thing be written in C so we don't have to get an extra C++ compiler for
one file (for those who don't want to use the Microsoft toolchain)?
--
Peter Eisentraut peter_e@gmx.net