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/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
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 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
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 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
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 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
On 30.09.2011 19:16, Eric Noulard wrote: 2011/9/30 Alexander Neundorfa.neundorf-w...@gmx.net: 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
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
2011/9/30 Alexander Neundorf a.neundorf-w...@gmx.net: 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
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 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
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 cliffy...@gmail.com
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 function() above,
and
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 cliffy...@gmail.com 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
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 pe...@pcc.me.ukwrote: 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 pe...@pcc.me.ukwrote: 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 Tue, Sep 13, 2011 at 08:40:32AM -0400, Clifford Yapp wrote: On Sun, Sep 11, 2011 at 11:01 PM, Peter Collingbourne pe...@pcc.me.ukwrote: 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 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 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 11:52:23AM -0400, Clifford Yapp wrote: On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne pe...@pcc.me.uk 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
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 pe...@pcc.me.uk 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
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
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 pe...@pcc.me.uk 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
On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne pe...@pcc.me.uk 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
On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: -- Forwarded message -- From: Peter Collingbourne pe...@pcc.me.uk 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
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne pe...@pcc.me.uk 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
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 pe...@pcc.me.uk wrote: On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: -- Forwarded message -- From: Peter Collingbourne pe...@pcc.me.uk 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
[CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
-- Forwarded message -- From: Peter Collingbourne pe...@pcc.me.uk Date: Wed, Sep 7, 2011 at 9:17 PM Subject: Proposal: restat rules To: ninja-bu...@googlegroups.com Hi, In this email I'll try to explain one of the oddities of make (which some CMake-based build systems rely on), and why we can't currently express this in Ninja. I'll also propose how we could extend Ninja to support this behaviour. (Warning, long essay ahead.) In the LLVM project we maintain a code generator called tblgen, the purpose of which is to generate a number of header files containing various metadata. From time to time, tblgen and its dependent libraries will be modified, causing a rebuild of tblgen. Strictly speaking, we should now rebuild the header files, and all of their reverse dependencies, even if the generated file did not change. This is suboptimal, because the reverse dependencies constitute every object file built from a source file that transitively includes one of the tblgen generated files (which is 50% of object files in the build). To avoid this problem, we cause tblgen to write its output to a temporary file, and use a utility to copy the temporary file over the target file only if the temporary file is different from the target. In makefile terms, it looks something like this: - all: outputuser.o tblgen: tblgen.cpp touch tblgen output.inc.tmp: tblgen touch output.inc.tmp output.inc: output.inc.tmp if cmp output.inc.tmp output.inc ; then : ; else cp output.inc.tmp output.inc ; fi outputuser.o: outputuser.cpp output.inc touch outputuser.o - Note what happens during an incremental build where tblgen is the only dirty file, but its output file output.inc.tmp does not change relative to output.inc. make initially schedules a rebuild of tblgen, output.inc.tmp, output.inc and outputuser.o. After output.inc has been rebuilt, its timestamp remains the same as before the build. Before make begins to rebuild outputuser.o, it will re-evaluate the dirty state of outputuser.o based on the timestamps of its inputs (i.e. it will stat them again). Because outputuser.cpp and output.inc are both older than outputuser.o, make doesn't rebuild it after all, despite it being initially scheduled for a build. The behaviour is different in Ninja, which operates in two phases: the scheduling of the build and the build itself. Like make, Ninja will schedule a rebuild of tblgen, output.inc.tmp, output.inc and outputuser.o. Unlike make, it will rebuild targetuser.o, because it does not re-stat inputs during the build. The key observation here is that unlike make, Ninja currently provides no mechanism for pruning the scheduled build graph during a build using a build rule. What I propose for Ninja is that we implement this pruning behaviour in a similar way to make, but only for specific rules with a special variable set on the rule. We can call this variable restat (suggestions for better names are welcome). If this variable is present on a rule, Ninja will, after executing the rule command, re-stat each output file to obtain its modification time. If the modification time is unchanged from when Ninja initially stat'ed the file before starting the build, Ninja will mark that output file as clean, and recursively for each reverse dependency of the output file, recompute its dirty status. As an improvement over what make does, Ninja then stores the current timestamp in the build log entry associated with the output file. This timestamp will be treated by future invocations of Ninja as the output file's modification time instead of the output file's actual modification time for the purpose of deciding whether it is dirty (but not whether its reverse dependencies are dirty). To give an example of how this would look, here is the above makefile translated to Ninja: - rule touch command = touch $out rule cpifdiff command = if cmp $in $out ; then : ; else cp $in $out ; fi restat = true build tblgen: touch tblgen.cpp build output.inc.tmp: touch tblgen build output.inc: cpifdiff output.inc.tmp build outputuser.o: touch outputuser.cpp output.inc default outputuser.o - Now consider what happens when Ninja is asked at timestamp 3 to rebuild the default target (outputuser.o) where tblgen.cpp has timestamp 2 and all other files have timestamp 1. Ninja will schedule a rebuild of tblgen, output.inc.tmp, output.inc and outputuser.o. Again, suppose that the contents of output.inc.tmp are equal to output.inc when built. So after output.inc has been rebuilt, it still has a timestamp 1. Ninja will notice that the timestamp is the same as at the start of the build, and will mark output.inc as clean. This is propagated through to outputuser.o, which is also marked clean. So no further rebuilding is needed. Ninja will also associate the timestamp 3 with output.inc in the build log. Suppose that Ninja is invoked again immediately afterwards. The build planner
