MantisBT - CMake
View Issue Details
0015036CMake(No Category)public2014-07-24 05:482016-06-10 14:31
Simon Ask Ulsnes 
Kitware Robot 
normalminoralways
closedmoved 
Apple MacOS X10.4.10
CMake 3.0 
 
0015036: "make --question" always returns 1
In my project, I'm relying on the build system being able to answer the question whether or not the source tree has been updated or not. Currently, Makefiles generated by CMake do not support this usage for one reason or another.

The exit code of "make --question" should be 0 if all targets (or the specified target) are up to date, and nonzero if changes have been made. However, CMake-generated Makefiles always indicate that changes have been made, which results in nontrivial work being executed unnecessarily.
1. Create simple project with a single source file and a CMakeLists.txt
2. Create the Makefile with `cmake .`
3. Run `make`.
4. Run `make --question`.
5. Observe that the exit code is 1 instead of 0, even though the source file was not updated between steps 3 and 4.
No tags attached.
Issue History
2014-07-24 05:48Simon Ask UlsnesNew Issue
2014-07-24 11:02Brad KingNote Added: 0036450
2014-07-24 14:27Simon Ask UlsnesNote Added: 0036456
2014-07-24 15:06Brad KingNote Added: 0036457
2014-07-24 15:18Simon Ask UlsnesNote Added: 0036458
2014-07-24 15:30Brad KingNote Added: 0036459
2014-07-24 15:32Simon Ask UlsnesNote Added: 0036460
2014-07-24 15:41Brad KingNote Added: 0036461
2014-07-24 16:59Simon Ask UlsnesNote Added: 0036462
2016-06-10 14:29Kitware RobotNote Added: 0042590
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0036450)
Brad King   
2014-07-24 11:02   
This is due to the multi-level Makefile layout that CMake generates. See the explanation here:

 http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F [^]

Furthermore the internal "cmake_check_build_system" target must always run to determine whether any input files to CMake have changed such that it must re-run.

I do not think it is possible to support 'make --question'.
(0036456)
Simon Ask Ulsnes   
2014-07-24 14:27   
That's very sad news, since it forces me to use the rather slow and awkward SCons instead, or worse, revert to plain GNU Make. I really would prefer to use CMake.
(0036457)
Brad King   
2014-07-24 15:06   
Re 0015036:0036456: What is the purpose of asking "make --question" in the first place? Do you just want to know if the build is up to date without actually bringing it up to date? Why?
(0036458)
Simon Ask Ulsnes   
2014-07-24 15:18   
I'm the author of the Wayward Web Framework (https://github.com/simonask/w, [^] http://simonask.github.io/w [^]), which includes a Live Reload facility. Doing an actual build on every request is infeasible, because it brings HTTP response time over 1000ms in many cases. Doing an actual build in the background is also infeasible, because it makes it very difficult to distinguish between compilation errors in code that the user intended to compile and code that was saved as a result of habitual intermediate saving. :)
(0036459)
Brad King   
2014-07-24 15:30   
Re 0015036:0036458: Try using the Ninja generator. It generates a single monolithic build file so perhaps the "ninja" tool could answer the question or be taught to do so.
(0036460)
Simon Ask Ulsnes   
2014-07-24 15:32   
Thank you, I will look into it! :)

It's still a bummer that CMake can't support this, since CMake is by far the best-known and most widely user build tool at the moment. But perhaps the core features of CMake have more to do with being cross platform.
(0036461)
Brad King   
2014-07-24 15:41   
Re 0015036:0036460: Why depend on the build system for this at all? Can you keep a local database of timestamps of files in the source tree on each deployment? Then you only need to stat the sources, compare to the database, and update as needed. It will be build-system agnostic.
(0036462)
Simon Ask Ulsnes   
2014-07-24 16:59   
Thanks for the suggestion. Detecting changes to a C/C++ source tree that should cause a rebuild is a non-trivial operation. It's extremely error-prone, and build systems themselves often don't get it right. Since supporting multiple build systems is not a priority, I would rather not try to reimplement the mechanism, especially not in light of the risk that my implementation and the underlying build system may disagree in some cases, or in the worst case produce corrupt builds.

That said, if no existing build system is able to fit within the requirements for responsiveness and usability, it may be the only option. I would just hate to essentially add another build system to the forest.
(0042590)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.