Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 06.10.2011 21:14, Peter Kümmel wrote: OK, so I think this project is way too small for this test. There is some fixed overhead in the process here, and we are seeing it. We are talking about .5 seconds difference to check a whole build system. If you want to do tests like this, you need a much bigger project. I am sure that CMake will not be 50% slower for a larger project where we are not comparing .5 seconds to 1.1 seconds or .1 seconds. I don't know a bigger project which supports qmake and cmake, Another idea is to down-cock the system: My system runs in a VirtualBox, and I simply don't allow 100% CPU usage: KST: qmake cmake ninja -j1 14s 45s 3s -j2 14s 27s 3s VTK: qmake cmake ninja -j1 130s8s -j4 30s 8s Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
OK, so I think this project is way too small for this test. There is some fixed overhead in the process here, and we are seeing it. We are talking about .5 seconds difference to check a whole build system. If you want to do tests like this, you need a much bigger project. I am sure that CMake will not be 50% slower for a larger project where we are not comparing .5 seconds to 1.1 seconds or .1 seconds. I don't know a bigger project which supports qmake and cmake, but I tried VTK: Time to check when nothing to build: ninja(ms) make(ms) -j1 ~2503600 -j2 ~2502100 -j4 ~2501700 Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 10/6/2011 12:07 PM, Arnaud Gelas wrote: Hi Bill, Here are some timing, I made for ITK to compare ninja vs make (made last month). See results below The difference is not much, especially when you realized that none of the data have been downloaded, and I am not sure that at the end we get the same binary tree... Encouraging matter of fact, it worked on ITK... my 2 cts, Arnaud What happens if you just do a build where nothing builds? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Hi Bill, Here are some timing, I made for ITK to compare ninja vs make (made last month). See results below The difference is not much, especially when you realized that none of the data have been downloaded, and I am not sure that at the end we get the same binary tree... Encouraging matter of fact, it worked on ITK... my 2 cts, Arnaud Starting from scratch $ time make -j12 real18m20.479s user205m51.536s sys8m21.319s $ time ninja -j12 real18m1.246s user205m23.438s sys7m26.392 adding one extra space in itk::Image $ time make -j12 real15m8.004s user166m45.025s sys6m13.991s $ time ninja -j12 real14m54.776s user166m41.377s sys5m31.129s -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 10/5/2011 4:13 PM, Peter Kümmel wrote: On 05.10.2011 20:38, Alexander Neundorf wrote: On Wednesday 05 October 2011, Peter Kümmel wrote: And here some numbers to compare it with Qt's qmake. I've used this project: http://kst-plot.kde.org/ which supports qmake and cmake. Running make/ninja on a fresh compiled project with warm caches (in seconds): qmake cmake Ninja Makefiles makefiles -j1 0.5-0.8 1.6-1.9 0.11-0.14 -j2 0.6-0.8 1.3-1.4 0.11-0.13 -j4 0.6-0.7 1.1-1.4 0.10-0.13 Summary: - Ninja is the fastest - cmake Makefiles are really slow - parallel jobs doesn't help much in this special case OK, so I think this project is way too small for this test. There is some fixed overhead in the process here, and we are seeing it. We are talking about .5 seconds difference to check a whole build system. If you want to do tests like this, you need a much bigger project. I am sure that CMake will not be 50% slower for a larger project where we are not comparing .5 seconds to 1.1 seconds or .1 seconds. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 05.10.2011 20:38, Alexander Neundorf wrote: On Wednesday 05 October 2011, Peter Kümmel wrote: And here some numbers to compare it with Qt's qmake. I've used this project: http://kst-plot.kde.org/ which supports qmake and cmake. Running make/ninja on a fresh compiled project with warm caches (in seconds): qmake cmake Ninja Makefiles makefiles -j10.5-0.8 1.6-1.9 0.11-0.14 -j20.6-0.8 1.3-1.4 0.11-0.13 -j40.6-0.7 1.1-1.4 0.10-0.13 Summary: - Ninja is the fastest - cmake Makefiles are really slow - parallel jobs doesn't help much in this special case and: - qmake makefiles don't have complete dependencies Seriously, if cmakes Makefiles are slower, I am very sure this is because they have complete dependencies. Does this mean also the Ninja build file has complete dependencies, because it is also build by cmake? If this is the case, then in connection with cmake and an existing ninja binary make is not needed any more. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 05.10.2011 21:45, Bill Hoffman wrote: I just tried this on a machine here. "svn co svn://anonsvn.kde.org/home/kde/branches/work/kst/portto4/kst" CMake build: make -j8 real3m19.131s user16m31.866s sys 3m25.289s Qmake build: real2m55.761s user15m15.585s sys 1m58.203s mp/../viewitem.h:92: warning: unused parameter 'f' tmp/../viewitem.h:92: warning: unused parameter 'c' rm -f libkst2app.so.1.0.0 libkst2app.so libkst2app.so.1 libkst2app.so.1.0 linking ../../build/lib/libkst2app.so.1.0.0 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[1]: *** [../../build/lib/libkst2app.so.1.0.0] Error 1 make[1]: Leaving directory `/home/hoffman/kst-qmake/src/libkstapp' make: *** [sub-src-libkstapp-make_default-ordered] Error 2 So, for me the qmake build had a total failure after almost taking as long to build. So, CMake wins because the qmake build never actually finishes... :) BTW, This is an 8 core machine. What are you building on to get .5 minute builds? Something is odd here... 4 real cores and hyper threading with Ubuntu 11.10 and GCC 4.6: 1m15.467s But the build times aren't that interesting. The .5 you mentioned where .5 seconds which it takes to run make on an already build project: $ time make [ 19%] Built target kst2core [ 33%] Built target kst2math [ 43%] Built target kst2widgets [ 90%] Built target kst2app [ 90%] Built target kst2_filters_differentiation [ 92%] Built target kst2_datasource_ascii [ 92%] Built target kst2_datasource_qimagesource [ 93%] Built target kst2_datasource_sampledatasource [ 93%] Built target kst2_dataobject_bin [ 94%] Built target kst2_dataobject_linefit [ 95%] Built target kst2_dataobject_chop [ 96%] Built target kst2_dataobject_phase [ 96%] Built target kst2_dataobject_lockin [ 97%] Built target kst2_dataobject_statistics [ 97%] Built target kst2_dataobject_shift [ 97%] Built target kst2_dataobject_syncbin [ 98%] Built target kst2_dataobject_differentiation [ 98%] Built target kst2_dataobject_crossspectrum [ 98%] Built target kst2_dataobject_effectivebandwidth [ 99%] Built target kst2_dataobject_genericfilter [ 99%] Built target kst2_filters_cumulativesum [100%] Built target kst2_filters_despike [100%] Built target kst2 real0m1.772s user0m1.116s sys 0m0.372s $ How is this called 'clean run'? I hope this measures best the pure make-system speed. Peter -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
I just tried this on a machine here. "svn co svn://anonsvn.kde.org/home/kde/branches/work/kst/portto4/kst" CMake build: make -j8 real3m19.131s user16m31.866s sys 3m25.289s Qmake build: real2m55.761s user15m15.585s sys 1m58.203s mp/../viewitem.h:92: warning: unused parameter 'f' tmp/../viewitem.h:92: warning: unused parameter 'c' rm -f libkst2app.so.1.0.0 libkst2app.so libkst2app.so.1 libkst2app.so.1.0 linking ../../build/lib/libkst2app.so.1.0.0 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[1]: *** [../../build/lib/libkst2app.so.1.0.0] Error 1 make[1]: Leaving directory `/home/hoffman/kst-qmake/src/libkstapp' make: *** [sub-src-libkstapp-make_default-ordered] Error 2 So, for me the qmake build had a total failure after almost taking as long to build. So, CMake wins because the qmake build never actually finishes... :) BTW, This is an 8 core machine. What are you building on to get .5 minute builds? Something is odd here... -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 05.10.2011 20:38, Alexander Neundorf wrote: On Wednesday 05 October 2011, Peter Kümmel wrote: And here some numbers to compare it with Qt's qmake. I've used this project: http://kst-plot.kde.org/ which supports qmake and cmake. Running make/ninja on a fresh compiled project with warm caches (in seconds): qmake cmake Ninja Makefiles makefiles -j10.5-0.8 1.6-1.9 0.11-0.14 -j20.6-0.8 1.3-1.4 0.11-0.13 -j40.6-0.7 1.1-1.4 0.10-0.13 Summary: - Ninja is the fastest - cmake Makefiles are really slow - parallel jobs doesn't help much in this special case and: - qmake makefiles don't have complete dependencies OK, qmake Makefiles are not "complete". Seriously, if cmakes Makefiles are slower, I am very sure this is because they have complete dependencies. Is there a way to run cmake's Makefiles in the (faster) qmake-"mode" ? Peter Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Wednesday 05 October 2011, Peter Kümmel wrote: > And here some numbers to compare it with Qt's qmake. > I've used this project: http://kst-plot.kde.org/ > which supports qmake and cmake. > > Running make/ninja on a fresh compiled project > with warm caches (in seconds): > > qmake cmake Ninja >Makefiles makefiles > > -j10.5-0.8 1.6-1.9 0.11-0.14 > -j20.6-0.8 1.3-1.4 0.11-0.13 > -j40.6-0.7 1.1-1.4 0.10-0.13 > > > Summary: > - Ninja is the fastest > - cmake Makefiles are really slow > - parallel jobs doesn't help much in this special case and: - qmake makefiles don't have complete dependencies Seriously, if cmakes Makefiles are slower, I am very sure this is because they have complete dependencies. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
And here some numbers to compare it with Qt's qmake. I've used this project: http://kst-plot.kde.org/ which supports qmake and cmake. Running make/ninja on a fresh compiled project with warm caches (in seconds): qmake cmake Ninja Makefiles makefiles -j10.5-0.8 1.6-1.9 0.11-0.14 -j20.6-0.8 1.3-1.4 0.11-0.13 -j40.6-0.7 1.1-1.4 0.10-0.13 Summary: - Ninja is the fastest - cmake Makefiles are really slow - parallel jobs doesn't help much in this special case Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 30.09.2011 19:16, Eric Noulard wrote: 2011/9/30 Alexander Neundorf: Summary: builddryrebuild ninja 1m15.8 0m0.10m07.3 make1m19.4 0m1.40m07.9 auto3m19.9 0m2.10m13.0 So only the dry run shows a huge speedup (10-20 times faster) Not to question your numbers, but shouldn't the difference of the dryrun (1.3s) also be present in the rebuild ? 'rebuild' is the time after a 'touch': touch ../trunk/src/LyX.cpp time ninja means compiling one file plus the time for linking. Yes, makes not much sense to measure this time here because compiling and linking is independent of the ninja/make. I mean, this should be the time ninja is faster in checking whether any file changed, and in the rebuild case it has to do that too, and additionally build one file ? How often did you measure this, just once or multiple times ? Cache was warm and the time was a typical one of multiple runs. I was about to comment about this too. If you do test ninja first on a pristine source tree and then make then make will certainly take advantage of the VFS caching almost all source file access. May be it would necessary to untar the source (in different temp dir ) before each test sets. but may you already did this. I did the opposite, measured with a 'warm' cache. Peter Or may be I should just try myself :-] -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
2011/9/30 Alexander Neundorf : >> Summary: >> >> build dry rebuild >> ninja 1m15.8 0m0.1 0m07.3 >> make 1m19.4 0m1.4 0m07.9 >> auto 3m19.9 0m2.1 0m13.0 >> >> So only the dry run shows a huge speedup (10-20 times faster) > > Not to question your numbers, but shouldn't the difference of the dryrun > (1.3s) also be present in the rebuild ? > I mean, this should be the time ninja is faster in checking whether any file > changed, and in the rebuild case it has to do that too, and additionally build > one file ? > > How often did you measure this, just once or multiple times ? I was about to comment about this too. If you do test ninja first on a pristine source tree and then make then make will certainly take advantage of the VFS caching almost all source file access. May be it would necessary to untar the source (in different temp dir ) before each test sets. but may you already did this. Or may be I should just try myself :-] -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Friday 30 September 2011, Peter Kuemmel wrote: > > Tested cmake/ninja with Blender's cmake files, works well, and fast! > > Single file rebuild is 0.97 sec, same on makefiles was 3.7sec. > > I also have some numbers: > > > Building LyX (lyx.org, 676 files): > > LyX has autotools and cmake as build system. > > > > * cmake generated ninja files: > > 1. build > cmake -G Ninja > time ninja > real 1m15.862s > > 2. dry run > ninja > real 0m0.113s > > 3. rebuild one file > touch ../trunk/src/LyX.cpp > time ninja > real 0m7.340s > > > > * cmake generated Makefiles: > > 1. build > cmake ../trunk > time make -j9 > real 1m19.471s > > 2. dry run > time make -j9 > real 0m1.457s > > 3. rebuild one file > touch ../trunk/src/LyX.cpp > time make -j9 > real 0m7.952s > > > > * autotools: > > 1. build > ./configure --enable-build-type=dev (maybe different to cmake > configuration) time make -j9 > real 3m19.988s > > 2. dry run > time make -j9 > real 0m2.165s > > 3. rebuild one file > touch ../trunk/src/LyX.cpp > time make -j9 > real 0m13.087s > > > > > Summary: > > builddryrebuild > ninja 1m15.8 0m0.10m07.3 > make1m19.4 0m1.40m07.9 > auto3m19.9 0m2.10m13.0 > > So only the dry run shows a huge speedup (10-20 times faster) Not to question your numbers, but shouldn't the difference of the dryrun (1.3s) also be present in the rebuild ? I mean, this should be the time ninja is faster in checking whether any file changed, and in the rebuild case it has to do that too, and additionally build one file ? How often did you measure this, just once or multiple times ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
> > Tested cmake/ninja with Blender's cmake files, works well, and fast! > Single file rebuild is 0.97 sec, same on makefiles was 3.7sec. > I also have some numbers: Building LyX (lyx.org, 676 files): LyX has autotools and cmake as build system. * cmake generated ninja files: 1. build cmake -G Ninja time ninja real 1m15.862s 2. dry run ninja real 0m0.113s 3. rebuild one file touch ../trunk/src/LyX.cpp time ninja real 0m7.340s * cmake generated Makefiles: 1. build cmake ../trunk time make -j9 real 1m19.471s 2. dry run time make -j9 real 0m1.457s 3. rebuild one file touch ../trunk/src/LyX.cpp time make -j9 real 0m7.952s * autotools: 1. build ./configure --enable-build-type=dev (maybe different to cmake configuration) time make -j9 real 3m19.988s 2. dry run time make -j9 real 0m2.165s 3. rebuild one file touch ../trunk/src/LyX.cpp time make -j9 real 0m13.087s Summary: builddryrebuild ninja 1m15.8 0m0.10m07.3 make1m19.4 0m1.40m07.9 auto3m19.9 0m2.10m13.0 So only the dry run shows a huge speedup (10-20 times faster) --- And with a bigger project (clang, 1703 files): builddry ninja 8m29.7 0m0.16 make 7m52.9 0m1.42 Also here the dry run is much faster. Used sources: cmake: git://github.com/pcc/CMake/tree/ninja-generator ninja: git://github.com/pcc/ninja.git/tree/outputs-ready -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Thu, Sep 15, 2011 at 03:28:42PM +0200, Andreas Mohr wrote:
> Hi,
>
> On Wed, Sep 14, 2011 at 12:00:05PM -0400, cmake-requ...@cmake.org wrote:
> > Date: Wed, 14 Sep 2011 05:37:20 -0400
> > From: Clifford Yapp
> >
> > Looks like that's working. Running ninja again, I'm seeing another issue:
> >
> > BRL-CAD uses dependency assignment to make sure our build time delta
> > calculator is the last target to be built (and hence actually times the
> > build). With ninja, it doesn't seem to be respecting this, but instead
> > tries to run the delta target immediately. Do custom targets respect
> > dependency information?
Yes, but the dependencies are currently only attached to the target,
not to any of its custom commands. This behaviour is correct for
CMake's built-in targets, such as 'install' and 'test', for which the
commands are attached directly to the target, but add_custom_target
is actually implemented internally using custom commands (the command
given to add_custom_target is stored as a custom command attached to
a dummy source file), so the target dependencies are not currently
attached in the correct place for add_custom_target.
> IOW, from what I'm gathering here, it seems as if scm_sos_pull_db_tree
> lists its _internal_
> target/rule/whatever CMakeFiles/scm_sos_pull_db_tree with same-hierarchy
> priority as scm_sos_setup.
> And that internal target/rule/whatever then gets executed in advance, despite
> scm_sos_setup not having been executed (prepared) yet.
This is a symptom of the behaviour described above.
> IOW, it's a MISTAKE to implement (emulate) add_custom_command() via inner
> targets in Ninja build config,
> since those inner targets don't inherit those dependency constraints
> ("ordering")
> which have been explicitly imposed on their outer targets.
>
> So:
> - either keep custom commands implemented via inner targets - and then make
> sure
> that those inner (internal!) targets do have _all_ dependencies of the
> outer,
> CMake-public target specified
> - or don't implement custom commands via internal, logically disconnected
> targets [better?]
The former is the correct solution. The Ninja generator already
does this for object files to ensure that target dependencies are
built before any object file in the target (one of the build systems
I tested with uses a target dependency to generate a header file used
by some of the target's source files). I now realise this also needs
to happen for custom commands.
Thanks,
--
Peter
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Hi,
On Wed, Sep 14, 2011 at 12:00:05PM -0400, cmake-requ...@cmake.org wrote:
> Date: Wed, 14 Sep 2011 05:37:20 -0400
> From: Clifford Yapp
>
> Looks like that's working. Running ninja again, I'm seeing another issue:
>
> BRL-CAD uses dependency assignment to make sure our build time delta
> calculator is the last target to be built (and hence actually times the
> build). With ninja, it doesn't seem to be respecting this, but instead
> tries to run the delta target immediately. Do custom targets respect
> dependency information?
I'm seeing the same thing here, and I think I semi-nailed it.
I've got:
function(scm_sos_pull_db_tree _pull_target _scm_dir)
if(NOT TARGET scm_sos_pull_db_tree)
# this crap does not work the way it should...
#set(scm_spec "${scm_repo_prefix}/${_scm_dir}")
set(scm_spec "${scm_repo_prefix}")
#set(stamp_file_tree
"${sos_wrapper_stamps_dir}/scm_sos_pull_db_tree_${_pull_target}.stamp")
set(stamp_file_tree "${sos_wrapper_stamps_dir}/scm_sos_pull_db_tree.stamp")
set(db_tree_output "${sos_wrapper_db_file_pathname}")
add_custom_command(OUTPUT "${db_tree_output}"
COMMAND ${sos_wrapper_cmdline_constant_part} "-project ${scm_spec}
-command GetProjectTree"
COMMAND "${CMAKE_COMMAND}" -E touch "${stamp_file_tree}"
# Cannot specify the full ${scm_sos_dependencies} list here
# (we're creating the very database file that it lists).
# And we should avoid adding ${sos_wrapper_script} as a dependency
# here, since a simple update of that script most certainly doesn't
# justify doing the _AWFULLY_ lengthy operation of pulling
# the entire database anew. All other SCM targets _should_ properly
depend on
# SosWrap.bash, however, since they're much cheaper...
DEPENDS "${MASTER_SCM_HAS_BEEN_UPDATED}"
COMMENT "fetching SOS SCM database tree for ${scm_spec}"
VERBATIM
)
add_custom_target(scm_sos_pull_db_tree VERBATIM DEPENDS "${db_tree_output}")
add_dependencies(scm_sos_pull_db_tree scm_sos_setup)
endif(NOT TARGET scm_sos_pull_db_tree)
# add a dependency to make sure that before pulling a file/project we fetch
its project tree
add_dependencies(${_pull_target} scm_sos_pull_db_tree)
endfunction(scm_sos_pull_db_tree _pull_target _scm_dir)
So you can see that I'm clearly adding a dependency of target
scm_sos_pull_db_tree on the
target scm_sos_setup (which is the one to make sure that the SosWrap.bash script
is properly prepared before continuing).
However, what I'm ending up with is:
# Phony custom command for CMakeFiles/scm_sos_pull_db_tree
build CMakeFiles/scm_sos_pull_db_tree: phony
_SCM/sos/database/servers/SERVER/DATABASE.sos
# Utility command for scm_sos_pull_db_tree
build scm_sos_pull_db_tree: phony CMakeFiles/scm_sos_pull_db_tree
_SCM/sos/database/servers/SERVER/DATABASE.sos scm_sos_setup
# Phony custom command for CMakeFiles/scm_sos_setup
build CMakeFiles/scm_sos_setup: phony _SCM/sos/stamps/sos_setup.stamp
# Custom command for _SCM/sos/stamps/sos_setup.stamp
build _SCM/sos/stamps/sos_setup.stamp: CUSTOM_COMMAND
COMMAND = cd [[CMAKE_BINARY_DIR]] && /usr/local/bin/cmake -E make_directory
[[CMAKE_BINARY_DIR]]/_SCM/sos/stamps && /usr/local/bin/cmake -E touch
[[CMAKE_BINARY_DIR]]/_SCM/sos/stamps/sos_setup.stamp
DESC = Generating _SCM/sos/stamps/sos_setup.stamp
# Utility command for scm_sos_setup
build scm_sos_setup: phony CMakeFiles/scm_sos_setup
_SCM/sos/stamps/sos_setup.stamp
copy_prep_file__[[CMAKE_BINARY_DIR]]_SosWrap.bash
IOW, from what I'm gathering here, it seems as if scm_sos_pull_db_tree
lists its _internal_
target/rule/whatever CMakeFiles/scm_sos_pull_db_tree with same-hierarchy
priority as scm_sos_setup.
And that internal target/rule/whatever then gets executed in advance, despite
scm_sos_setup not having been executed (prepared) yet.
And this is most likely because add_custom_command() in Ninja generator
actually gets realised as an inner target of its corresponding CMake
add_custom_target(),
and we then have a logical disconnect since it's the _outer_, CMake-_public_
target
which gets configured a constraint ("scm_sos_setup needs to run first").
IOW, it's a MISTAKE to implement (emulate) add_custom_command() via inner
targets in Ninja build config,
since those inner targets don't inherit those dependency constraints
("ordering")
which have been explicitly imposed on their outer targets.
So:
- either keep custom commands implemented via inner targets - and then make sure
that those inner (internal!) targets do have _all_ dependencies of the outer,
CMake-public target specified
- or don't implement custom commands via internal, logically disconnected
targets [better?]
Or am I missing something?
(I believe my CMake construct is correct - but who knows...)
OK, I should perhaps add a file dependency (DEPENDS) within
add_custom_command() on the
SosWrap.bash script (but that was done _very_ deliberately - see comment in
that
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 9/14/2011 5:37 AM, Clifford Yapp wrote: Looks like that's working. Running ninja again, I'm seeing another issue: BRL-CAD uses dependency assignment to make sure our build time delta calculator is the last target to be built (and hence actually times the build). With ninja, it doesn't seem to be respecting this, but instead tries to run the delta target immediately. Do custom targets respect dependency information? I would think the best think to do would be to focus on the CMake tests. If these are not all passing, then there is a good chance any large project will fail at some point. If all the tests are passing, I would think most anything could be built. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Looks like that's working. Running ninja again, I'm seeing another issue: BRL-CAD uses dependency assignment to make sure our build time delta calculator is the last target to be built (and hence actually times the build). With ninja, it doesn't seem to be respecting this, but instead tries to run the delta target immediately. Do custom targets respect dependency information? Cheers, CY On Tue, Sep 13, 2011 at 9:33 AM, Peter Collingbourne wrote: > > Try using this branch of Ninja: > > https://github.com/pcc/Ninja/tree/restat > > The 'restat' branch is still under development, so this requirement > will go away once 'restat' is merged into the main branch of Ninja. > > Thanks, > -- > Peter > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Tue, Sep 13, 2011 at 08:40:32AM -0400, Clifford Yapp wrote: > On Sun, Sep 11, 2011 at 11:01 PM, Peter Collingbourne wrote: > > > > > > It looks like various custom commands aren't running (some tcl related > > > stuff, docbook documentation generation) - are custom commands currently > > > supported? > > > > Yes, custom commands and targets are supported. There was a bug (which > > is now fixed) that caused custom commands not be built by default. Now > > all targets except those marked EXCLUDE_FROM_ALL are built by default. > > > > With latest pull from this weekend, I'm currently getting: > > ninja cmTryCompileExec > > ninja: error: loading 'build.ninja': line 21, col 9: in 'rules.ninja': > line > 38, col 3: unexpected variable 'restat' Try using this branch of Ninja: https://github.com/pcc/Ninja/tree/restat The 'restat' branch is still under development, so this requirement will go away once 'restat' is merged into the main branch of Ninja. Thanks, -- Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Sun, Sep 11, 2011 at 11:01 PM, Peter Collingbourne wrote: > > > It looks like various custom commands aren't running (some tcl related > > stuff, docbook documentation generation) - are custom commands currently > > supported? > > Yes, custom commands and targets are supported. There was a bug (which > is now fixed) that caused custom commands not be built by default. Now > all targets except those marked EXCLUDE_FROM_ALL are built by default. > With latest pull from this weekend, I'm currently getting: ninja cmTryCompileExec ninja: error: loading 'build.ninja': line 21, col 9: in 'rules.ninja': line 38, col 3: unexpected variable 'restat' Cheers, CY ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Fri, Sep 09, 2011 at 11:52:23AM -0400, Clifford Yapp wrote: > On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne wrote: > > > > > Anyone who is interested in trying the Ninja generator with > > their own projects is welcome to clone my repository at: > > > > https://github.com/pcc/CMake/tree/ninja-generator > > > > and to report any issues encountered. Note that the generator is > > currently only known to work on Linux. To select the Ninja generator > > you can pass the option "-G Ninja" on the cmake command line. > > > > Gave it a whirl with BRL-CAD. You caught me out fair and square on one > unspecified dependency that no other build system has caught, which is kinda > cool. > > It seems to mostly build, but it's not recognizing that it's done (if I > re-run ninja, it redoes most of the build). This could be something I'm not > doing right or expected ninja behavior at this stage, but I thought I'd > mention it. Hopefully this is a known issue, which I'm currently working on. > It looks like various custom commands aren't running (some tcl related > stuff, docbook documentation generation) - are custom commands currently > supported? Yes, custom commands and targets are supported. There was a bug (which is now fixed) that caused custom commands not be built by default. Now all targets except those marked EXCLUDE_FROM_ALL are built by default. > For the core program building though, looks like it succeeded quite handily > - very nice! Unfortunately, my time delta calculation was one of the > targets not built (or at least I don't see its output) so I'm not sure what > the time difference is yet ;-). You could always use the "time" command... Thanks, -- Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Fri, Sep 09, 2011 at 02:55:00PM +, Malfettone, Kris wrote: > Peter, > I am very interested in the ninja generator and gave it a try for one of my > very large projects. Unfortunately, I have approximately 100 targets all > with the same output name(simple) but in CMake I give them all unique target > names(dot separated name built from their place in the directory tree). This > works fine for Makefiles however the ninja generator seems to be adding: > # Shortcut target for the output name. > build simple: phony MD/MDF/Parsers/BX/BLS/v1_1/utils/simple/simple > # Shortcut target for the target name. > build BX.BLS.v1_1.simple: phony simple > Which then causes the following from ninja: > ninja: WARNING: multiple rules generate simple. build will not be > correct; continuing anyway > > Is there a way to disable these shortcut targets? Even changing my target > names to a different format is a possibility if that is necessary. Not currently. There are a few other projects I am aware of that do something similar. I will probably modify the generator to not output shortcut targets for a given basename if more than one target has that basename. Thanks, -- Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Fri, Sep 09, 2011 at 10:42:13AM -0400, Bill Hoffman wrote: > This is very cool work Peter. How well is this generator doing with the > CMake tests? These are the current test results: 89% tests passed, 22 tests failed out of 203 Label Time Summary: Label1= 0.03 sec Label2= 0.03 sec Total Test time (real) = 491.33 sec The following tests FAILED: 12 - kwsys.testDynamicLoader (Failed) 40 - ExternalOBJ (Failed) 41 - LoadCommand (Failed) 52 - ExportImport (Failed) 55 - EmptyLibrary (OTHER_FAULT) 57 - BundleUtilities (Failed) 64 - LinkFlags-lib_config (Failed) 65 - LinkFlags-dll_config (Failed) 66 - LinkFlags-exe_config (Failed) 68 - SubProject-Stage2 (Failed) 74 - CustomCommand (Failed) 76 - OutOfSource (Failed) 77 - BuildDepends (Failed) 78 - SimpleInstall (Failed) 79 - SimpleInstall-Stage2 (Failed) 98 - LoadedCommandOneConfig (Failed) 100 - complexOneConfig (Failed) 99 - complex (Failed) 103 - ExternalProject (Failed) 120 - Plugin (Failed) 125 - SubDir (Failed) 203 - CMake.CheckSourceTree (Failed) ... which seems to be actually quite good, considering I haven't made any special effort to try to pass the tests. > Is there a nija for windows? I would be interested in > testing that. Yes, the current version of Ninja supports Windows, but the generator would certainly need to be adapted. Thanks, -- Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne wrote: > > Anyone who is interested in trying the Ninja generator with > their own projects is welcome to clone my repository at: > > https://github.com/pcc/CMake/tree/ninja-generator > > and to report any issues encountered. Note that the generator is > currently only known to work on Linux. To select the Ninja generator > you can pass the option "-G Ninja" on the cmake command line. > Gave it a whirl with BRL-CAD. You caught me out fair and square on one unspecified dependency that no other build system has caught, which is kinda cool. It seems to mostly build, but it's not recognizing that it's done (if I re-run ninja, it redoes most of the build). This could be something I'm not doing right or expected ninja behavior at this stage, but I thought I'd mention it. It looks like various custom commands aren't running (some tcl related stuff, docbook documentation generation) - are custom commands currently supported? For the core program building though, looks like it succeeded quite handily - very nice! Unfortunately, my time delta calculation was one of the targets not built (or at least I don't see its output) so I'm not sure what the time difference is yet ;-). Cheers, and nice work! CY ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Peter, I am very interested in the ninja generator and gave it a try for one of my very large projects. Unfortunately, I have approximately 100 targets all with the same output name(simple) but in CMake I give them all unique target names(dot separated name built from their place in the directory tree). This works fine for Makefiles however the ninja generator seems to be adding: # Shortcut target for the output name. build simple: phony MD/MDF/Parsers/BX/BLS/v1_1/utils/simple/simple # Shortcut target for the target name. build BX.BLS.v1_1.simple: phony simple Which then causes the following from ninja: ninja: WARNING: multiple rules generate simple. build will not be correct; continuing anyway Is there a way to disable these shortcut targets? Even changing my target names to a different format is a possibility if that is necessary. -Kris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Peter Collingbourne Sent: Thursday, September 08, 2011 2:55 PM To: Jean-Christophe Fillion-Robin Cc: CMake ML Subject: Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: > -- Forwarded message -- > From: Peter Collingbourne > Date: Wed, Sep 7, 2011 at 9:17 PM > Subject: Proposal: restat rules > To: ninja-bu...@googlegroups.com FWIW, the Ninja generator I have been working on is based on work by Nicolas Despres, and has been successfully used to compile a number of large open source projects, including CMake itself, LLVM/Clang, OpenCV and Bullet Physics. I am planning to submit the Ninja generator as a patch to CMake upstream once it has been put through more exhaustive testing and certain known issues have been resolved (my post to ninja-build being one of them). Anyone who is interested in trying the Ninja generator with their own projects is welcome to clone my repository at: https://github.com/pcc/CMake/tree/ninja-generator and to report any issues encountered. Note that the generator is currently only known to work on Linux. To select the Ninja generator you can pass the option "-G Ninja" on the cmake command line. Thanks, -- Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
This is very cool work Peter. How well is this generator doing with the CMake tests? Is there a nija for windows? I would be interested in testing that. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Am Donnerstag, 8. September 2011, 19:54:46 schrieb Peter Collingbourne: > On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: > > -- Forwarded message -- > > From: Peter Collingbourne > > Date: Wed, Sep 7, 2011 at 9:17 PM > > Subject: Proposal: restat rules > > To: ninja-bu...@googlegroups.com > > FWIW, the Ninja generator I have been working on is based on work by > Nicolas Despres, and has been successfully used to compile a number > of large open source projects, including CMake itself, LLVM/Clang, > OpenCV and Bullet Physics. If you want something big try to build KDE stuff with it. There is a script called kdesrc-build that can be used to automate the building, I'm rather sure this can easily be changed to call Ninja instead of make. Eike signature.asc Description: This is a digitally signed message part. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Tested cmake/ninja with Blender's cmake files, works well, and fast! Single file rebuild is 0.97 sec, same on makefiles was 3.7sec. btw, we do something similar to LLVM with generating source, only updating if it changes, however only for C files not headers, ninja handles this ok for my quick tests editing files and rebuilding. Looking forward to having this in stable cmake! On Fri, Sep 9, 2011 at 4:54 AM, Peter Collingbourne wrote: > On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: >> -- Forwarded message -- >> From: Peter Collingbourne >> Date: Wed, Sep 7, 2011 at 9:17 PM >> Subject: Proposal: restat rules >> To: ninja-bu...@googlegroups.com > > FWIW, the Ninja generator I have been working on is based on work by > Nicolas Despres, and has been successfully used to compile a number > of large open source projects, including CMake itself, LLVM/Clang, > OpenCV and Bullet Physics. > > I am planning to submit the Ninja generator as a patch to CMake > upstream once it has been put through more exhaustive testing and > certain known issues have been resolved (my post to ninja-build being > one of them). > > Anyone who is interested in trying the Ninja generator with > their own projects is welcome to clone my repository at: > > https://github.com/pcc/CMake/tree/ninja-generator > > and to report any issues encountered. Note that the generator is > currently only known to work on Linux. To select the Ninja generator > you can pass the option "-G Ninja" on the cmake command line. > > Thanks, > -- > Peter > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- - Campbell ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne wrote: > > I am planning to submit the Ninja generator as a patch to CMake > upstream once it has been put through more exhaustive testing and > certain known issues have been resolved (my post to ninja-build being > one of them). > Very cool! What differences (if any) have you seen incompilation speed? Cheers, CY ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: > -- Forwarded message -- > From: Peter Collingbourne > Date: Wed, Sep 7, 2011 at 9:17 PM > Subject: Proposal: restat rules > To: ninja-bu...@googlegroups.com FWIW, the Ninja generator I have been working on is based on work by Nicolas Despres, and has been successfully used to compile a number of large open source projects, including CMake itself, LLVM/Clang, OpenCV and Bullet Physics. I am planning to submit the Ninja generator as a patch to CMake upstream once it has been put through more exhaustive testing and certain known issues have been resolved (my post to ninja-build being one of them). Anyone who is interested in trying the Ninja generator with their own projects is welcome to clone my repository at: https://github.com/pcc/CMake/tree/ninja-generator and to report any issues encountered. Note that the generator is currently only known to work on Linux. To select the Ninja generator you can pass the option "-G Ninja" on the cmake command line. Thanks, -- Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
