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: pgsql-patches@postgresql.org > 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 basic > 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 also > pretty horrible on win32. > > > Unlike the previous stuff we do with VC++ this one doesn't use separate > Makefiles. Instead I have a script that generates complete Visual Studio > solution and project files by parsing the existing Makefiles. This build > script isn't completed yet, there are a few too many things hardcoded in > it. But it *works*, and the produced binary passes all regression tests > 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 (VS > 2005). It's only a very few places that used the two parameter version, > 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. Storing > the second 0.0 in a variable makes this work. I made the change for all > platforms to avoid #ifdef, but if that's not acceptable it can of course > easily be made inside a #ifdef. > > *) Cleanup incorrect definitions of several WINAPI functions. They were > simply wrong, but mingw/gcc accepted it anyway.. > > *) Sync up pg_config.h.win32 to be a mingw-configure-output version with > a couple of minor changes (listed). This is the largest part of the > patch... > > *) Add s_lock implementation based on InterlockedCompareExchange instead > of assembly code (gcc style asm not supported, and this should probably > be about as fast from what I hear) > > *) It also updates the old Visual C++ makefiles to still work. I expect > 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 I > didn't forget anything... > > //Magnus ---------------------------(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
