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 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
