I've done a similar thing myself (building the complete backend with
Visual Studio 2005). I got it to basically work, but stopped due to
lack of interest in the PostgreSQL community.
But, I'd be happy to help out your effort in any way I can.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:pgsql-patches-
> [EMAIL PROTECTED] On Behalf Of Magnus Hagander
> Sent: Sunday, April 23, 2006 1:11 PM
> To: email@example.com
> Subject: [PATCHES] Building with Visual C++
> I've been working on getting the full backend to compile and run using
> Visual C++ instead of mingw/gcc, and have made some good progress.
> First, why do this? A couple of reasons:
> 1) MS VC++ is a significantly faster compiler, so rebuilding is much
> faster ;)
> 2) MS VC++ supposedly has a better optimiser. I haven't got any pg
> figures for this, but I've heard it from many other projects.
> 3) MS VC++ generates debug symbols in a way that's compatible with a
> Windows debugger - such as the one in Visual Studio, but also the
> WinDbg debuggers that are the "standard windows debuggers". gdb is
> horrible on win32.
> 4) It should also work with Visual Studio profiler tools. gprof is
> pretty horrible on win32.
> Unlike the previous stuff we do with VC++ this one doesn't use
> Makefiles. Instead I have a script that generates complete Visual
> solution and project files by parsing the existing Makefiles. This
> script isn't completed yet, there are a few too many things hardcoded
> it. But it *works*, and the produced binary passes all regression
> except one (more on this in a separate mail in a minute or two). With
> this it should also build fine with Visual C++ Express (free download
> from MS), also not tested yet.
> Turns out the changes are pretty small - most of the needed stuff was
> implemented in /port already, and just needed activation for win32.
> The attached patch makes some changes in the code required to work for
> this, and some clenaups. A summary of the changes is:
> *) WIN32_CLIENT_ONLY was a very bad name for a macro, since it pretty
> much meant "visual c++". In a lot of places, it's just removed (need
> removed by changing headers), in the few places where it's relevant we
> instead use _MSC_VER which properly indicates Visual C++.
> *) Change all open() commands to use the three parameter version. This
> is because Visual C++ didn't support variadic macros until version 8
> 2005). It's only a very few places that used the two parameter
> so I think it's fine to make this change for all platforms.
> *) Change where NaN is generated. Using 0.0/0.0 doesn't work in VC++
> because it detects it as a divide-by-zero at the compile stage.
> the second 0.0 in a variable makes this work. I made the change for
> platforms to avoid #ifdef, but if that's not acceptable it can of
> easily be made inside a #ifdef.
> *) Cleanup incorrect definitions of several WINAPI functions. They
> simply wrong, but mingw/gcc accepted it anyway..
> *) Sync up pg_config.h.win32 to be a mingw-configure-output version
> a couple of minor changes (listed). This is the largest part of the
> *) Add s_lock implementation based on InterlockedCompareExchange
> of assembly code (gcc style asm not supported, and this should
> be about as fast from what I hear)
> *) It also updates the old Visual C++ makefiles to still work. I
> them to go away once I'm done with the buildscript, but for now they
> needed some small updates.
> Finally, a couple of files are added to the tree:
> src/include/port/win32vc/* - stub include files the same way
> src/include/port/win32 is used already.
> src/port/dirent.c - opendir/readdir/closedir implementation for win32,
> that doesn't even have the bugs mingw had in it ;)
> Hmm. That mail turned out longer than intended. Let's hope that means
> didn't forget anything...
---------------------------(end of broadcast)---------------------------
TIP 1: 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