(0036450)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (administrator)
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.

Notes
(0036450) Brad King (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (administrator) 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.

Issue History
Date Modified	Username	Field	Change
2014-07-24 05:48	Simon Ask Ulsnes	New Issue
2014-07-24 11:02	Brad King	Note Added: 0036450
2014-07-24 14:27	Simon Ask Ulsnes	Note Added: 0036456
2014-07-24 15:06	Brad King	Note Added: 0036457
2014-07-24 15:18	Simon Ask Ulsnes	Note Added: 0036458
2014-07-24 15:30	Brad King	Note Added: 0036459
2014-07-24 15:32	Simon Ask Ulsnes	Note Added: 0036460
2014-07-24 15:41	Brad King	Note Added: 0036461
2014-07-24 16:59	Simon Ask Ulsnes	Note Added: 0036462
2016-06-10 14:29	Kitware Robot	Note Added: 0042590
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships