[cmake-developers] find PATHS issues on Windows when Linux OS files are accessible

[Alan W. Irwin]

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
__________________________