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
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}")
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
