View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012361CMakeCMakepublic2011-07-27 11:562016-06-10 14:31
ReporterChristopher Sean Morrison 
Assigned ToKitware Robot 
PrioritylowSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 2.8.4 
Target VersionFixed in Version 
Summary0012361: Undesirable cmake path behavior, ill defined usage
Descriptioncmake usage lists two separate meanings of the path specified as either path-to-source or path-to-existing-build. On more than one occasion, our users have encountered unexpected (and undesirable) behavior where the path they specified was a path-to-source, yet they got the latter path-to-existing-build behavior.

The usage is ill-defined in the sense that you cannot know which usage was intended by the user which invariably leads to unexpected behavior if a build was (at any point in time) performed in the source directory. Sure, out of source builds are better and recommended and documented as such, but if project developers merely occasionally ensure that in-source builds work for the sake of their non-educated users, they run into this usability problem.

As the latter path-to-existing build "feature" merely saves the caller from changing their directory, e.g., "cd path-to-existing-build; cmake .", I'd propose/request that the usage be simplified to the single unambiguous usage case of the path always meaning path-to-source.

That simplified usage improves usability by making the path behavior deterministic. Cmake doesn't have to inspect the contents of the path to infer that it was a source or build directory, and consequently would allow a use case (in-dir builds alongside out-of-dir builds) that presently is not possible.
Steps To Reproducecd source
cmake .
make
mkdir .build
cd .build
cmake ..
# files output to the "wrong" directory since there was a CMakeCache.txt in the source dir.
TagsNo tags attached.
Attached Files

 Relationships
related to 0006672closedKitware Robot Detect In-Source build BEFORE creating CMakeCache.txt 

  Notes
(0027088)
Eric NOULARD (developer)
2011-07-27 17:21

 This approach has 2 major drawbacks and 1 minor:
   A) This is not backward compatible
   B) The build driectory already "knows" from which source it is derived
      so I would *hate* to have to specify the source dir when I'm within
      the build dir.
   C) What would be the behavior if I'm in buildir1 and call cmake
      with sourcedir2, which is not "sourcedir1" from which buildir1 has
      been initialized with.

What I do really miss for a long time is a clean way to ENFORCE out-of-source
build "before" polluting the source tree. This is implementable in
a backward compatible way AND may prevent user from misuse by "ambiguity".

see
http://public.kitware.com/Bug/view.php?id=6672 [^]
(0027090)
Christopher Sean Morrison (reporter)
2011-07-27 18:09

 "A" is taken care of with however cmake already manages backwards incompatible changes. As part of some future release, the change would be introduced. That's not a drawback, it's just a delay.

"B" is definitely the decision in question, but begs a few questions. Should the interface be more convenient for the developer or for people just following build instructions (i.e., "users")? The path is indistinguishable as it presently stands designed given the "overloaded" use.

I'd bet most of the subsequent invocations, you specify an existing build dir from within that dir, i.e., almost always "cmake ." which could be easily replaced with an option, e.g., "cmake --rebuild" or "cmake -r", always using the current directory.

For "C", I'd expect it to do what it was told to do. If usage is always "cmake [options] [path-to-source]", then I'd expect it to output build files for sourcedir2 into my current directory, wherever I may be. If I specified "cmake -r", then it'd reconfigure the existing builddir1 files.

As for pollution, only devs care about that. Even for myself, I usually build out-of-dir for projects I work on but I could care less for code I'm just compiling to install. If I'm compiling a third-party source just to get an install, I don't care one whit whether I'm building in dir or out of dir. I want it done and over with as fast and easy as possible. That's usually compile, install, and delete the whole directory when I'm done. If it takes too long or if there are too many problems, I delete and don't look back.

Forcing users to create a build directory out of source would unnecessarily increase the build complexity (even if it's "mkdir build; cd build; ...; rm -rf build" but more distressingly increases their effort without providing any benefit whatsoever to that one-time-compile user.

I'm all for making things simpler for users. A better use of time (in my humble opinion) would be infrastructure to keep track of the pollution cmake produced along with functions for devs to specify the debris they generate.

Cheers!
(0030286)
David Cole (manager)
2012-08-11 11:38

 Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0041870)
Kitware Robot (administrator)
2016-06-10 14:28

 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
2011-07-27 11:56 Christopher Sean Morrison New Issue
2011-07-27 17:21 Eric NOULARD Note Added: 0027088
2011-07-27 17:21 Eric NOULARD Relationship added related to 0006672
2011-07-27 18:09 Christopher Sean Morrison Note Added: 0027090
2012-08-11 11:38 David Cole Status new => backlog
2012-08-11 11:38 David Cole Note Added: 0030286
2016-06-10 14:28 Kitware Robot Note Added: 0041870
2016-06-10 14:28 Kitware Robot Status backlog => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:28 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team