|
Notes |
|
|
(0017328)
|
|
Eric NOULARD
|
|
2009-09-07 13:41
|
|
|
|
|
(0017606)
|
|
Brad King
|
|
2009-09-18 10:27
|
|
|
I've assigned this to myself since something along these lines has been on my todo list for a long time. I still don't know when I'll find time to work on it, but it would be a cool feature. |
|
|
|
(0027089)
|
|
Brad King
|
|
2011-07-27 17:59
|
|
Moving to backlog as I have no time to work on this now.
|
|
|
|
(0036989)
|
|
cxj
|
|
2014-10-06 23:04
|
|
|
This is a make or break feature for my team. If I can't find some way to hack around this limitation, we'll be forced to choose some other system. And I plan to be vocal about it. Come on -- 6 years to remove a major impediment to effective use of a tool? |
|
|
|
(0036995)
|
|
Brad King
|
|
2014-10-07 08:42
|
|
Re 0006672:0036989: Complaining that other people have not spent their time to meet your needs and making threats about it is not a good way to get help. Please instead use a constructive tone and perhaps even make an actual proposal about how the problem might be solved.
One reason this has not been addressed is that it is non-trivial. Code in CMakeLists.txt is not even executed until after the cache is initialized so there would have to be some other way to indicate in the source tree that it should not be built in-source. Even better, CMake internals could be taught to delay or avoid writing files to the build tree until the CMakeLists.txt has had a chance to say not to. |
|
|
|
(0036999)
|
|
cxj
|
|
2014-10-07 11:07
|
|
Yes, you're correct -- complaints often do not result in desired action. I've been a member of various open-source projects since 1999, so I'm well aware of the dynamics.
Look at it from the user's point of view for a moment: a major shortcoming which has had numerous discussions across a variety of websites attempting to find solutions has languished in the official bug queue for 6 years. Regardless of the non-trivial nature of the solution, that lack of action says to the user community that perhaps CMake is a poor choice. My so-called threat was really a simple statement of fact, though perhaps poorly worded in my frustration of the moment*. When I (or others) respond to questions about CMake we will tell the truth -- that it has glaring flaws and that those flaws don't get addressed in a timely fashion.
An all-volunteer labor-based project can either be a "scratch their own itch" and the rest of the world be damned kind of project, or one which cares about a greater user community. For a variety of reasons, I'd have to say CMake is in the latter category. Otherwise, I wouldn't be here at all.
As to an actual solution:
I understand that CMakeLists.txt is not a procedural language, but more a declaration of how to build internal data structures. Hence, it makes perfect sense that some files get written before evaluation begins. Given the strong encouragement to use out-of-source builds and their inherent advantages, it seems like a solution which precedes evaluation of CMakeLists.txt is called for.
I personally would go so far as to say that CMake should patently refuse to do any in-source builds unless a command line switch (or environment variable or config file) says otherwise. I.e. cmake --force-in-source to actually force an in-source build. This would no doubt raise screams from the hopefully minority of users who actually do in-source builds.
Given the non-triviality of addressing it via a CMakeLists.txt directive, some outside the box thinking is required. Hence having some sort of flags or settings which affect the cmake executable before doing any writing of files seems like the best solution.
I could maybe even live with something like a .nobuild file in the source directory as a flag, although that's really ugly and probably not as Windows friendly as it needs to be. What I can't live with is having my source directories trashed.
I suspect the same root cause is what appear to prevent any file(REMOVE, ...) or execute_process(COMMAND, rm ...) commands in the CMakeLists.txt file from being executed when an exit is forced via a message(FATAL_ERROR, "no in-source builds, thanks"). Otherwise the numerous hacks would work, where people try to automatedly clean up the unwanted CMakeCache.txt and CMakeFiles/ after catching an in-source build. Of course, they do not.
This is a make or break issue for us. Other common CMake complaints are like the warts all other build systems have -- something that can be worked around or lived with. We like CMake for its succinct build and linking targets, its clear output, its ability to generate both Make and Ninja files. We'd like to be able to use it. |
|
|
|
(0037000)
|
|
Brad King
|
|
2014-10-07 11:36
|
|
Re 0006672:0036999: Actually the language used in CMakeLists.txt is procedural. However, it runs in the context of a persistent ("cached") space of variables stored in CMakeCache.txt. The cache is initialized before the procedural steps start to run. With cmake-gui or the cmake command-line "-D" option it is even possible to store entries in the cache before CMake even parses CMakeLists.txt.
Currently one can do the following to minimize the impact:
cmake_minimum_required(VERSION ...)
if("${CMAKE_SOURCE_DIR}" STREQUAL "${CMAKE_BINARY_DIR}")
message(FATAL_ERROR "Do not build in-source. Please remove CMakeCache.txt and the CMakeFiles/ directory. Then build out-of-source.")
endif()
project(...)
Those two locations are the only thing CMake touches before running. This approach is a common an effective workaround to this issue.
Lots of people do in-source builds so we cannot require special settings for them. I agree a .nobuild mark file would be ugly, especially because we already have a "CMakeLists.txt" file right there to indicate it is a source directory. I'd really like to find a way to have the no-in-source indicator placed in the CMakeLists.txt file itself. Or, we could introduce a general-purpose ".cmake/" directory that could contain files like ".nobuild". |
|
|
|
(0041418)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
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. |
|