MantisBT - CMake
View Issue Details
0006672CMakeCMakepublic2008-03-28 05:042016-06-10 14:30
Eric NOULARD 
Kitware Robot 
normalfeaturealways
closedmoved 
CMake-2-6 
 
0006672: Detect In-Source build BEFORE creating CMakeCache.txt
I've already been annoyed by a way to easily indicates user
that in-source build is forbidden or that its usage
disable some features.
But as far as my last test was, I wasn't able to detect
CMAKE_BINARY_DIR != CMAKE_SOURCE_DIR

before PROJECT statement.
as a consequence CMake already created CMakeLists.txt in-source
such that if the user finally tries to build out-fo-source afterwards
he ends-up sending a bug report telling out-of-source is not working.

I'd like to be able to WARN the user with messages
and stop BEFORE CMakeCache.txt is created.

Ideally I'd like to be able to do something like:

IF (CMAKE_INSOURCE)
  MESSAGE(STATUS "Building in-source is a bad idea because blabla...")
  IF (NOT CMAKE_INSOURCE_FORCED)
     MESSAGE(FATAL_ERROR "If you really want to build in-source then rerun with -DCMAKE_INSOURCE_FORCED:BOOL=TRUE")
  ENDIF(NOT CMAKE_INSOURCE_FORCED)
ENDIF (CMAKE_INSOURCE)

PROJECT(MyProject)
...
No tags attached.
has duplicate 0011343closed Brad King A built-in facility to disallow in-source builds would be a useful feature 
related to 0010187closed Kitware Robot Where to build the binaries - feature request for CMAKE variable 
related to 0012361closed Kitware Robot Undesirable cmake path behavior, ill defined usage 
related to 0014818closed Kitware Robot Out-of-source build does not work if an 'in-source' CMakeCache.txt file is available 
Issue History
2008-03-28 05:04Eric NOULARDNew Issue
2008-06-06 11:25Bill HoffmanStatusnew => assigned
2008-06-06 11:25Bill HoffmanAssigned To => Ken Martin
2009-09-07 13:41Eric NOULARDNote Added: 0017328
2009-09-18 10:24Brad KingAssigned ToKen Martin => Brad King
2009-09-18 10:27Brad KingNote Added: 0017606
2010-10-21 09:26Eric NOULARDRelationship addedhas duplicate 0011343
2010-12-14 19:06David ColeRelationship addedrelated to 0010187
2011-07-27 17:21Eric NOULARDRelationship addedrelated to 0012361
2011-07-27 17:59Brad KingNote Added: 0027089
2011-07-27 17:59Brad KingAssigned ToBrad King =>
2011-07-27 17:59Brad KingStatusassigned => backlog
2014-03-20 03:44Eric NOULARDRelationship addedrelated to 0014818
2014-10-06 23:04cxjNote Added: 0036989
2014-10-07 08:42Brad KingNote Added: 0036995
2014-10-07 11:07cxjNote Added: 0036999
2014-10-07 11:36Brad KingNote Added: 0037000
2016-06-10 14:27Kitware RobotNote Added: 0041418
2016-06-10 14:27Kitware RobotStatusbacklog => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:27Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0017328)
Eric NOULARD   
2009-09-07 13:41   
Just a pointer to a related thread on the ML:
http://www.cmake.org/pipermail/cmake/2009-September/031833.html [^]
(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.