On Tue, 2010-08-10 at 16:38 -0700, Natalie Tasman wrote: > Hi Ralf, > > I think this is a great idea and would be interested in hearing your > plans for moving forward. I've invested a lot of time in an autotools > build system that works on *nix and mingw (and cross-compiling to > mingw from linux!) and I do think this would be interesting to see > this work on mingw shell with MSVC's build system, as you propose. > > Although, to be honest, I have recently been taking another look at > other build systems such as cmake, which does generate full > MSVC-native project files, which is very attractive. I'm sure this is > heresay, but I'll at least voice my interest in a dream solution: > autotools with Visual Studio project file generation.
Part of the problem with Visual Studio project file generation is the frequency with which the file format changes--sometimes a little, sometimes a lot. But every couple of years or so, something's likely to change. msbuild (of which I understand modern project file formats to be a subset) might be a better target. The long term stability of the file format doesn't have much of a track record yet; but one can choose to be optimistic. It does deliver a command line build without a Bourne shell, which I'm guessing is the major attraction of nmake. But unlike nmake, it has quite a few modern features. > A related, possibly basic question: if mingw's gcc builds > msvc-compatible DLLs, etc, what do people see as the benefit to using > a mingw/sh-driven MSVC build? Good enough for C; but if you wants to build a DLL with C++ interface features, you generally still need to use the same compiler as other code you're playing with. -- Braden McDaniel <bra...@endoframe.com>
