[CMake] Strange search order of CMakeCache.txt

[Michael Wild]

On 5. Mar, 2010, at 14:19 , Marcel Loose wrote:

> Hi all,
> 
> I just spent an hour debugging a very strange phenomenon running CMake
> on Mac OS-X, which in the end turned out to be trivial, but completely
> unexpected for me.
> 
> The problem was caused by the fact that CMake had accidentally been run
> once from the source directory. When running CMake in an empty binary
> directory it seemed to somehow fail to set CMAKE_BINARY_DIR correctly.
> 
> Cause of the problem turned out to be the order in which CMake searches
> for the CMakeCache.txt file: first in the directory containing the
> CMakeLists.txt file (CMAKE_SOURCE_DIR), then in the (binary) directory
> that CMake is being run from (CMAKE_BINARY_DIR). 
> 
> Wouldn't it be more logical to start in the binary directory and then
> look in the source directory? Or, probably even better, completely
> ignore the source directory when searching for the cache file.
> 
> Best regards,
> Marcel Loose.

It is not very intuitive (but very useful) that CMake first assumes the directory argument to be a binary tree, and only then looks for a CMakeLists.txt. E.g.:


mkdir -p path/to/build-tree
cd path/to/build-tree
cmake path/to/source-tree
# now want to change some setting, don't have to remember/type source-tree path
ccmake .
make

On the other hand, it can be quite confusing behavior if an "accidental" CMakeCache.txt is present in the source tree... Perhaps CMake should add a safety check and emit a warning if a cache exists in the current working directory that references the same source tree as the cache in the directory specified on the command line...


Michael