The Microsoft VC++ compiler can definitely be driven by gmake (I've done it at previous companies), but that involves a lot of platform-specific knowledge added to the makefiles (.obj instead of .o, .exe instead of no suffix, etc.).
Two downsides: One, is it makes the makefiles ugly, the other is that it removes one benefit of native VC++ support: The ability to use Visual Studio to build and debug in an integrated fashion. Overall, I think an automated makefile to Visual Studio .vcproj conversion can be made to work, and would be better. > -----Original Message----- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Monday, April 24, 2006 1:57 PM > To: Magnus Hagander > Cc: Chuck McDevitt; pgsql-patches@postgresql.org > Subject: Re: [PATCHES] Building with Visual C++ > > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > > The main difference between what I'm trying now from most of what I've > > seen before is that I *don't* want to create a separate build > > environment that needs to be maintained. Instead have a conversion > > script from our current one to a VC compatible one. > > This is definitely the only way that the project will fly --- there's > no way we're going to duplicate our forest of Makefiles in a different > format that has to be hand-maintained. If Magnus can make a conversion > script work, though, I think we can accept that. > > We'll need a VC buildfarm member in place to catch us anytime we change > the Makefiles in a way that the script doesn't understand. Before the > buildfarm existed I'd have been skeptical of whether even the > conversion-script approach would be viable in the long run, but with > timely info about breakages I think it can work. > > BTW, has anyone looked at the possibility of driving VC from gmake, > so that we can continue to use the same Makefiles? Or is that just > out of the question? > > regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
