|
(0027090)
|
|
Christopher Sean Morrison
|
|
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
|
|
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.
|
|