MantisBT - CMake
View Issue Details
0013071CMakeCMakepublic2012-03-28 17:482016-06-10 14:31
Ben Longbons 
Kitware Robot 
normalminoralways
closedmoved 
CMake 2.8.7 
 
0013071: nonexecutables in $PATH should be ignored
While building various things, I like to have simple wrappers in ~/bin/ around basic tools like gcc - e.g. to run with niceness to prevent making my desktop unresponsive, or to check that it builds with a prerelease version as well as the latest release, or to record command-line options if a project's build system doesn't echo it (ahem), or even sometimes to add or remove a command-line option.

Of course, I don't want to use these wrappers all the time, so when I'm not using them I chmod -x. This works for the vast majority of cases, but unfortunately makes it impossible to build cmake projects.

If you have to search $PATH yourself, please emulate libc.

from execvp(3):
       If permission is denied for a file (the attempted execve(2) failed with
       the error EACCES), these functions will continue searching the rest of
       the search path. If no other file is found, however, they will return
       with errno set to EACCES.
$ touch ~/bin/gcc
$ rm CMakeCache.txt
$ cmake .
No tags attached.
Issue History
2012-03-28 17:48Ben LongbonsNew Issue
2012-03-30 10:02Brad KingNote Added: 0029005
2012-03-30 10:02Brad KingStatusnew => backlog
2012-03-31 01:11Ben LongbonsNote Added: 0029019
2016-06-10 14:28Kitware RobotNote Added: 0042012
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0029005)
Brad King   
2012-03-30 10:02   
At least the find_program command would need to be taught this check. Note however that CMake also works on filesystems where file permissions cannot be relied upon. Furthermore there could be compatibility concerns because find_program has always worked the way it does now.

Use "mv $tool $tool.disable" instead of "chmod -x $tool" to workaround the issue. This problem is not exclusive to CMake. For example see this commit in git.git upstream:

  http://git.kernel.org/?p=git/git.git;a=commitdiff;h=f98f8cba [^]
(0029019)
Ben Longbons   
2012-03-31 01:11   
True, but on an OS that requires permissions to execute, the execute permissions will be checked.

Sure, if I mount a FAT volume it'll either mark everything executable or nothing, depending on mount options. But the only question that needs to be asked is: given that my OS requires an execute permission, is it in the $PATH, with execute permissions for me?

After all, you can't expect to run cmake on a Linux box and copy the generated files to a Windows box and expect them to work.

Doing a full proper check for owner/group/other + attributes would be complicated, but an #ifdef'ed check for ANY execute bit would solve real-world cases without breaking anything.
(0042012)
Kitware Robot   
2016-06-10 14:28   
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.