Hmm. It looks my original proposal breaks some backward compatibility. Maybe
this patch is better:
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -1148,13 +1148,13 @@ bool SystemTools::FileExists(const kwsys_stl::string&
filename)
{
return (GetFileAttributesA(winpath) != INVALID_FILE_ATTRIBUTES);
}
- return access(filename.c_str(), R_OK) == 0;
+ return access(filename.c_str(), R_OK) == 0 || access(filename.c_str(), X_OK)
== 0;
#elif defined(_WIN32)
return (GetFileAttributesW(
SystemTools::ConvertToWindowsExtendedPath(filename).c_str())
!= INVALID_FILE_ATTRIBUTES);
#else
- return access(filename.c_str(), R_OK) == 0;
+ return access(filename.c_str(), R_OK) == 0 || access(filename.c_str(), X_OK)
== 0;
#endif
}
From: cmake-developers [mailto:[email protected]] On Behalf Of
Thompson, KT
Sent: Friday, December 19, 2014 3:46 PM
To: [email protected]
Subject: [cmake-developers] Proposed change to behavior of find_program
CMake developers,
I am proposing a small change to SystemTools.cxx to address a problem I have on
multiple systems. I need find_program to return the path to an executable file
that is not marked with the read permission bit, but is marked with the execute
bit (e.g.: chmod 111 file).
On Linux systems, find_program unnecessarily requires that a file be readable.
I propose that the FileExists function be changed to test for execute
permission instead of read permission:
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -1148,13 +1148,13 @@ bool SystemTools::FileExists(const kwsys_stl::string&
filename)
{
return (GetFileAttributesA(winpath) != INVALID_FILE_ATTRIBUTES);
}
- return access(filename.c_str(), R_OK) == 0;
+ return access(filename.c_str(), X_OK) == 0;
#elif defined(_WIN32)
return (GetFileAttributesW(
SystemTools::ConvertToWindowsExtendedPath(filename).c_str())
!= INVALID_FILE_ATTRIBUTES);
#else
- return access(filename.c_str(), R_OK) == 0;
+ return access(filename.c_str(), X_OK) == 0;
#endif
}
Comments? Thoughts?
-kt
Kelly (KT) Thompson
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
