MantisBT - CMake

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0014485

CMake

public

2013-10-15 12:40

2016-06-10 14:31

Reporter

irwin

Assigned To

Kitware Robot

Priority

normal

Severity

minor

Reproducibility

always

Status

closed

Resolution

moved

Platform

MSYS on Windows

OS Version

Product Version

CMake 2.8.11.2

Target Version

Fixed in Version

Summary

0014485: 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.

Steps To Reproduce

Additional Information