View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014485CMakeCMakepublic2013-10-15 12:402016-06-10 14:31
Reporterirwin 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformMSYS on WindowsOSOS Version
Product VersionCMake 2.8.11.2 
Target VersionFixed in Version 
Summary0014485: The result of find commands should always have the drive letter included on Windows platforms
DescriptionThis 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.
TagsNo tags attached.
Attached Files

 Relationships
related to 0014486closedKitware Robot Search paths without a root component recognized by the host operating system should be ignored by find commands 

  Notes
(0034125)
Brad King (manager)
2013-10-15 13:15

 Link to thread on gmane:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8228 [^]
(0042392)
Kitware Robot (administrator)
2016-06-10 14:29

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2013-10-15 12:40 irwin New Issue
2013-10-15 13:15 Brad King Note Added: 0034125
2013-10-15 15:06 Brad King Relationship added related to 0014486
2016-06-10 14:29 Kitware Robot Note Added: 0042392
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team