Peter Eisentraut wrote: > 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. <kew>Great! Configuration was sorely needed.
> 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.) <kew>I agree -- good first step. > 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. <kew>I don't remember why all of the options were needed. Some of them might be more historical than others. The good news is that the fork/exec stuff can be compiled and tested on Linux. Just run with -x on the command line. > 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. <kew>The ones I wrote should be portable to *nix (by replacing CopyFile, etc). However, I've heard others talk about it being a good idea to re-write the scripts in c to use libpq directly. Mine mimic the shell scripts without attempting to improve on the functionality. > Two quick questions: Why PG_WIN32 and not just WIN32? <kew>To differentiate from the #ifdef WIN32's that were already in the code (psql is an example). I didn't want to break existing code in any way by adding my stuff. >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)? <kew> ConsoleApp is written in C++ for two reasons: 1) By instantiating a class inheriting from CWinApp, we get a lot of initialization for free. This is especially important when the windows are created. (The window is so we have a target to which messages (i.e. signals) are sent intra- and inter-process.) 2) Critical Sections (mutex's in the *nix world). By implementing the use of critical sections within the constructor/destructor of a stack variable, I am ensuring that there is no way to exit a scope without unlocking what was locked. This includes sigjmp, breaks, and early returns. Without this, the chances are pretty good that the proceess will hang on an error because something will stay locked when it shouldn't. Hope this answers your questions, Katie ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
