The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=14485 ====================================================================== Reported By: irwin Assigned To: ====================================================================== Project: CMake Issue ID: 14485 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2013-10-15 12:40 EDT Last Modified: 2013-10-15 12:40 EDT ====================================================================== Summary: The result of find commands should always have the drive letter included on Windows platforms Description: This is one of two issues noted on the mailing-list thread started at http://public.kitware.com/pipermail/cmake-developers/2013-October/008589.html for Windows systems that happen to have a Linux file hierarchy mounted as a particular drive letter. (This scenario always happens on Wine, but it could also occur on the Microsoft version of Windows systems.)
The test CMake code is as follows: find_program(LUA_EXECUTABLE lua PATHS /usr/bin NO_DEFAULT_PATH ) message(STATUS "LUA_EXECUTABLE = ${LUA_EXECUTABLE}") When the above is executed from the MSYS bash.exe shell, then the following result is obtained: bash.exe-3.1$ cmake -P test.cmake -- LUA_EXECUTABLE = /usr/bin/lua This is an obviously incorrect result since /usr/bin/lua does not exist from the MSYS/Windows system perspective, i.e., bash.exe-3.1$ ls /usr/bin/lua ls: /usr/bin/lua: No such file or directory If the result of the find command had included the drive letter, then the result would have been -- LUA_EXECUTABLE = z:/usr/bin/lua and, indeed, that file does exist from the MSYS/Windows perspective: bash.exe-3.1$ ls z:/usr/bin/lua z:/usr/bin/lua The proposed change to always include the drive letter in the results of find commands on Windows systems has the huge advantage that the results are guaranteed to exist from the MSYS/Windows perspective making additional analysis of other find issues (e.g., is the file found the one you want) much easier. And I cannot think of a scenario where a user would consider it to be a good thing for the results of a find command to not exist (like demonstrated above). So this proposed change seems a no-brainer to me. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2013-10-15 12:40 irwin New Issue ====================================================================== -- 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