[CMake] Strange search order of CMakeCache.txt

Marcel Loose loose at astron.nl
Fri Mar 5 08:43:34 EST 2010


On Fri, 2010-03-05 at 14:27 +0100, Michael Wild wrote:
> 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

Hi Michael,

I never knew you could use path/to/build-tree as argument to cmake, but
re-reading the docs reveals that feature.

I would definitely like to get a warning when CMake finds a cache file
in what it thinks should be the source directory. It would have saved me
an hour of debugging. OTOH, now that I know of this "strange" behaviour,
I might be able to tackle these kinds of problems quicker.

Best regards,
Marcel Loose.




More information about the CMake mailing list