On Mon, Aug 17, 2009 at 11:05 PM, Johannes Schindelin<Johannes.Schindelin@xxxxxx> wrote: > 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. Sorry, but I'm a bit lost now. What maintainer are we talking about now? Junio? As I would be providing a turn-key CMake build system, the only burden I would be putting on the maintainer would be learning CMake. Given that I'm providing a comprehensive (100+ slides) CMake tutorial ( http://www.elpauer.org/stuff/learning_cmake.pdf ) , which I use in my CMake workshops, I think I'm making that burden a bit lighter. If the next git conference is somewhere in Europe, I could also fly there and we'd have a CMake tutorial, if people would feel more comfortable that way. > 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. Again, I'm a bit lost. What '/src/cmake/release.sh' are we talking about now? Would that be part of CMake or git ? If you want to build CMake from scratch, you only need to download the source from http://cmake.org/cmake/resources/software.html , then run "./bootstrap" in the source directory. That's true for every platform but Visual C++, which requires you to download a pre-built CMake binary to build CMake. If you mean you want to bootstrap git (i. e. download the git tarball, which would include the CMake sources, then bootstrap CMake, then build git using the CMake build system), I'd say that makes no sense at all. That would be like saying you want to include the autotools sources, the OpenSSL sources, the curl sources, the Subversion sources, etc in the git tarball. Insane. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html