search for: cmglobalxcodegenerator

...meone's now written a ninja backend for cmake, although I'm not sure where they put it, so cmake might actually provide an easier way to play with ninja than your new system. Similarly, cmake's xcode generator is nominally open source (http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalXCodeGenerator.cxx;h=32eaef837e2d79c286ea7651d1ee3f69eb5f0f6a;hb=HEAD). How come there's no interest in improving it? Not that I really want to defend cmake. I hate its language as much as anyone. Jeffrey

...ten a ninja backend for cmake, although > I'm not sure where they put it, so cmake might actually provide an > easier way to play with ninja than your new system. Similarly, cmake's > xcode generator is nominally open source > (http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalXCodeGenerator.cxx;h=32eaef837e2d79c286ea7651d1ee3f69eb5f0f6a;hb=HEAD). > How come there's no interest in improving it? I don't generally believe it is tractable to generate great project files for a specific project from a generic configuration language. - Daniel > Not that I really want to def...

I'm going to briefly summarize my responses here. On Fri, Oct 28, 2011 at 9:56 AM, Chris Lattner <clattner at apple.com> wrote: > On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote: >> Anyways, if you wish to avoid duplicating info on both Makefile and >> CMakeLists.txt there is a simple solution: read and parse the Makefile >> from the corresponding CMakeLists.txt.

On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote: > A good measure of how fast a set of Makefile are is to run the build > with all targets up-to-date. Both builds takes a few seconds (3 or so) > on my Linux quad core box. Whatever improvement can be achieved on this > seems pretty insignificant. There are different overheads in different scenarios. The makefiles get really poor