MantisBT - CMake
The correct operation of find_file and other find_* command calls in CMAKE_FIND_ROOT_PATH scenarios on Windows might be possible to restore, while
still keeping the rest of the issue 0010994 fix.
= Contents =
CMakeLists.txt : CMakeLists file to be used.
testToolChain.toolchain : Toolchain file demonstrating a workaround.
root/ : Directory to be used as CMAKE_FIND_ROOT_PATH.
root/include/dummyFile.txt : File to be searched for by FIND_FILE.
Build/ : Out-of-source build directory.
Used to get a clean state between the multiple
cmake invocations that will be performed.
= Reproducing =
The CMakeLists.txt will be Configured by CMake versions 2.8.11 and 2.8.12.
The results will differ.
== Steps ==
=== 2.8.11 ===
1. Use CMake version 2.8.11
2. Invoke from Build/ :
cmake ..
The variable TEST_NOROOT is set to path of dummyFile.txt.
=== 2.8.12 ===
1. Use CMake version 2.8.12
2. Invoke from Build/ :
cmake ..
The variable TEST_NOROOT is not set to path of dummyFile.txt - Its value is TEST_NOROOT-NOTFOUND.
This result differs from 2.8.11 and is therefore a regression.
"Windows: Search '/' prefix only when cross compiling (0010994)"
A developer comment on issue 0010994 (http://www.cmake.org/Bug/view.php?id=10994#c32940 [^]), links to the attempted fix commit f9eee7f1 (http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f9eee7f1 [^]).
According to the f9eee7f1 commit message:
"Fix WindowsPaths.cmake to add '/' to CMAKE_SYSTEM_PREFIX_PATH only when
cross-compiling to Windows from a non-Windows host."
The root ('/') path is made to be omitted from CMAKE_SYSTEM_PREFIX_PATH on Windows hosts, as a change from 2.8.11 to 2.8.12.
I claim this omission breaks CMAKE_FIND_ROOT_PATH on Windows hosts.
As demonstrated by the uploaded test example, a command call of the form:
"find_file(<VAR> NAMES <NAMES> PATH_SUFFIXES <SUFFIXES>)"
Will no longer function in presence of CMAKE_FIND_ROOT_PATH.
As many Find* Modules included with CMake use find_file command calls of the above form, these Modules therefore become unable to function in a CMAKE_FIND_ROOT_PATH scenario.
The uploaded test example also contains a toolchain file.
The toolchain file appends '/' to CMAKE_SYSTEM_PREFIX_PATH.
The addition of '/' allows the command call to succeed.
This indicates the ab-or-pre-sence of '/' has a breaking effect on find_file.
The uploaded test example also attempts a command call of the form:
"find_file(<VAR> NAMES <NAMES> PATHS / PATH_SUFFIXES <SUFFIXES>)"
Here a 'PATHS /' parameter is added with respect to the previous failing call.
The addition of '/' in PATHS also allows the command call to succeed.
Commit f9eee7f1, already mentioned and linked in a section above,
describes the reason for '/' omission as:
"This will avoid searching and finding local paths without a drive letter on Windows."
In a CMAKE_FIND_ROOT_PATH scenario with CMAKE_SYSTEM_PREFIX_PATH containing '/', a drive-less path will never be formed by find_file. The operation of find_file, relevant to this scenario, is described next.
Assuming values of:
CMAKE_FIND_ROOT_PATH = F:\root
CMAKE_SYSTEM_PREFIX_PATH = '/' # (Or just containing '/' among other items)
A find_file command call will prefix F:\root to '/', getting 'F:\root\'.
This path will then be considered for the search.
(The find_file command documentation (http://www.cmake.org/cmake/help/v2.8.12/cmake.html [^]), describes CMAKE_SYSTEM_PREFIX_PATH as used during the '5.' step of the search process. The search path prefixing effect of CMAKE_FIND_ROOT_PATH is described towards the end of find_file documentation.)
Using find_file in a CMAKE_FIND_ROOT_PATH scenario, the 'paths without a drive letter' issue does not occur, as '/' is used just to form a longer path by concatenation of CMAKE_FIND_ROOT_PATH with CMAKE_SYSTEM_PREFIX_PATH.
Commit f9eee7f1 has therefore introduced a new bug (A regression), while attempting to fix an unrelated case.
| duplicate of | 0014591 | closed | find_path appears to ignore PATH_SUFFIXES |
DummyProj.zip (1,168) 2013-12-03 02:43https://public.kitware.com/Bug/file/4994/DummyProj.zip