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
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; firstname.lastname@example.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
> > 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
> script work, though, I think we can accept that.
> We'll need a VC buildfarm member in place to catch us anytime we
> 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