Hi, On Mon, 17 Aug 2009, Pau Garcia i Quiles wrote: > On Mon, Aug 17, 2009 at 10:43 PM, Reece Dunn<msclrhd@xxxxxxxxxxxxxx> wrote: > > 2009/8/17 Pau Garcia i Quiles <pgquiles@xxxxxxxxxxx>: > >> On Mon, Aug 17, 2009 at 9:53 PM, Johannes > >> Schindelin<Johannes.Schindelin@xxxxxx> wrote: > >> > >>> Of course, we could have a script that verifies that the .vcproj > >>> files contain reference the appropriate files (which it would know > >>> about by being called from the Makefile and being passed the file > >>> names), maybe even be able to edit the .vcproj file if it is missing > >>> some. Should not be too hard in Perl. > >> > >> You'll need to special-case for Visual C++ 2010, which is different > >> and incompatible with previous versions. Hence my suggestion for > >> CMake: appropriate project files would be generated for the tool the > >> user chooses, be it VC++ 2005, VC++2010, gcc, Borland C++ or anything > >> else. > > > > The problem is that you'd still need the Visual Studio projects (one > > each for 6, 7 (2002), 7.1 (2003), 8 (2005), 9 (2008) and 10 (2010) -- > > yes, there'll need to be one for each version of Visual Studio) as > > people who use Visual Studio tend to primarily use the IDE. CMake > > (which Windows users will need to download & install from somewhere) > > will sit outside this -- unless you mean making the project files be > > the "Makefile project" type and simply use it to invoke CMake and host > > the source files to ease access to them from the IDE? > > If a CMake build system is provided, you will not need a single Visual > Studio project, or the autotools build system, or anything else. Just > CMake and the CMake build system (which are a bunch of CMakeLists.txt > plain text files). You are putting an undue burden on the already overloaded maintainer. Well, let's see if you can provide a /src/cmake/release.sh that compiles CMake from scratch, and _then_ I'll look into CMake again. Ciao, Dscho