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:tgl@sss.pgh.pa.us]
> 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" <mha@sollentuna.net> 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
