[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