[cmake-developers] CMake confused if CMakeFiles directory removed

Matthew Woehlke matthew.woehlke at kitware.com
Thu Aug 23 16:55:41 EDT 2012


After FindBoost falling apart when I tried to clean my build tree in 
combination with upgrading to CMake 2.8.9, and subsequently chasing that 
red herring for a bit, I think I've finally nailed down a bug that's 
been occasionally biting me for some time.

Basically, if you delete CMakeFiles, but not your cache, CMake gets 
confused about the state of its found compilers and recreates bogus 
files in the new CMakeFiles directory.

As a test case, consider the attached CMakeLists.txt (the 
execute_process stuff is to clear the screen of strace output prior to 
the find_library call, when strace'ing; 'strace -e file' recommended).

On first run, CMake stats a whole bunch of directories that might have 
libraries (basically, it looks like it stats everything in the default 
search dirs), then does openat on the ones that exist, including 
/usr/lib64 where the file can be found.

After removing CMakeFiles, it does NOT stat at all, and does openat on a 
reduced set of directories including some that don't exist.

Comparing the CMakeFiles from both runs is informative. The "broken" one 
has only empty values in its CMake<lang>Compiler.cmake, and its 
CMakeDetermineCompilerABI_<lang>.bin are empty files (file size == 0).

I would guess a simple (though arguably incorrect) fix would be to force 
CMake to re-find compilers - ignoring the cache entries that they have 
been found already - if it needs to recreate their files in CMakeFiles/.

-- 
Matthew
-------------- next part --------------
cmake_minimum_required(VERSION 2.8)

set(fl1 fl1-NOTFOUND)
execute_process(COMMAND printf "\\e[H\\e[J\\e[3J\\e[H")
find_library(fl1 NAMES dl)
message(FATAL_ERROR "find_library 1: ${fl1}")


More information about the cmake-developers mailing list