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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
