View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014486CMakeCMakepublic2013-10-15 14:572016-06-10 14:31
Reporterirwin 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformMSYS/WindowsOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0014486: Search paths without a root component recognized by the host operating system should be ignored by find commands
DescriptionThis is the second 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.) The first of these issues "The result of find commands should always have the drive letter included on Windows platforms" has already been reported at http://public.kitware.com/Bug/view.php?id=14485. [^]

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
 
When bug 14485 is addressed that result should become

-- LUA_EXECUTABLE = z:/usr/bin/lua

which has the merit of always referring to a real file when the find is a success.

The current bug report concerns the different issue of when that real file is not what you want for the case when a Linux file system hierarchy is mounted as a drive letter (in this case z:). For this case, I assume most users would normally prefer PATHS values such as /usr/bin without a drive letter (as in the above test code) be ignored by find commands since obviously many Linux files found this way are normally useless on a Windows system. But in the above mailing-list discussion Brad King made the case that some Windows users would prefer the find command to stay just as it is (i.e., for PATHS values without a drive letter specified, all possible drive letters are searched to see if any matches are obtained). So to cater to the needs of the two different sets of Windows users, I propose the following possibilities be available.

1. The current status quo as default since some Windows users prefer that.

2. Ignore sources of search paths (such as PATHS values) which are unrooted, i.e. (this is Brad's description) "paths without a root component recognized by the host operating system". This possibility would only be used if the user set a unique cmake variable or property (named, say IGNORE_UNROOTED_SEARCH_PATHS) to a true value and would insure that PATHS values without drive letter such as /usr/bin would be ignored on Windows for all find commands.
TagsNo tags attached.
Attached Files

 Relationships
related to 0014485closedKitware Robot The result of find commands should always have the drive letter included on Windows platforms 

  Notes
(0034128)
Brad King (manager)
2013-10-15 15:06

 Link to thread on gmane:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8228 [^]
(0034129)
Brad King (manager)
2013-10-15 15:09

 IIUC the distinction of 0014486 from 0014485 is that this issue is for those who say we shouldn't search in the unrooted paths in the first place, and that issue is for those who say we should search in them but add the root (current working drive letter) to the result.
(0042393)
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 14:57 irwin New Issue
2013-10-15 15:06 Brad King Relationship added related to 0014485
2013-10-15 15:06 Brad King Note Added: 0034128
2013-10-15 15:09 Brad King Note Added: 0034129
2016-06-10 14:29 Kitware Robot Note Added: 0042393
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