I have a Windows platform with a Linux OS filesystem effectively mounted on the z: drive letter (this was actually for Wine, but I assume it would be straightforward to set this up on the Microsoft version of Windows as well) where a whole bunch of Linux executables can be found in z:/usr/bin, e.g.,
bash.exe-3.1$ ls z:/usr/bin/lua z:/usr/bin/lua The following command confirms they are Linux executables: bash.exe-3.1$ file z:/usr/bin/lua z:/usr/bin/lua: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, stripped Access to Linux executables on a Windows platform confuses the hell out of the following simple test case: bash.exe-3.1$ cat test.cmake 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 Windows system perspective, i.e., bash.exe-3.1$ ls /usr/bin/lua ls: /usr/bin/lua: No such file or directory What is the convention for CMake's mapping of "PATHS /usr/bin" to some drive letter? I assume from this incorrect result of "finding" /usr/bin/lua that it effectively checks all possible drive letters for a match and reports back /usr/bin/lua (not z:/usr/bin/lua) when it discovers z:/usr/bin/lua. But this incorrect result obviously causes problems on all Windows systems where there is file access to a Linux OS. To address this issue, I think the right thing to do here is to ignore all PATHS values on Windows that don't start with a drive letter. Of course, I can work around this issue by using find_program(LUA_EXECUTABLE lua) instead, which relies on having the PATH variable set properly both on Linux and MSYS. However, PATHS is an important part of the CMake find command logic out in the software universe (e.g., in the officially supported Find modules for CMake) so addressing this issue is important. Of course, I could be missing something so I would like some discussion here concerning this issue before I put together an official bug report describing the problem. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -- 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