Hi,
I figured I'd take a look at resolving #10126:
http://www.cmake.org/Bug/view.php?id=10126
The fix proposed by Brad King at this ticket involves two parts. I'd like
to seek clarification on this ticket.
1. It is proposed to add new file permissions to INSTALL and FILE commands
called READ/WRITE/EXECUTE.
a. So to clarify, you'd want existing OWNER_* / GROUP_* / EXECUTE_*
options to remain unmodified? i.e. if you install(PERMISSIONS GROUP_WRITE)
this will still NOT respect the umask, correct? (i.e. the only way to
respect the umask would be to use the NEW READ/WRITE/EXECUTE options?)
b. If the answer to (a) is yes, what do you want to do if the user
specifies install(PERMISSIONS WRITE GROUP_WRITE)? Is that an error? Should
we just have the WRITE take precedence and respect the umask anyway, even
though GROUP_WRITE was specified to not respect umask? (If the answer to
(a) is no, then obviously there's no harm in specify WRITE GROUP_WRITE
because it's purely redundant.)
c. Would it be better to introduce a new permissions keyword for
respecting the umask for the entire set of keywords? E.g.
install(PERMISSIONS RESPECT_UMASK GROUP_WRITE). This could be done in
conjunction with new READ/WRITE/EXECUTE, so for example:
install(PERMISSIONS RESPECT_UMASK WRITE) would specify owner/group/world
write while respecting umask, and install(PERMISSIONS WRITE) would do the
same but NOT respect the umask. What I like about this: (i) preserves
compatibility as if you answer "yes" to (a) above, (ii) avoids the issues
from (b) above.
d. If the answer to (c) is yes, should that keyword become the default,
subject to a new policy? (And introduction of a different NO_RESPECT_UMASK
keyword).
2. Proposal to modify default permission copying of configure_file and
friends: I may have questions here but haven't thought it through yet.
Finally, to resolve the issue as reported by the original submitter:
Fix works almost perfectly, yet there are some files still having 0644
rights:
in builddir/CMakeFiles/ it's
- CMakeCCompiler.cmake
- CMakeCXXCompiler.cmake
- CMakeSystem.cmake
3. Won't the proposal from #2 above fix this problem? As in, #1 then
because a "nice-to-have" thing but not necessary to fix the original problem
with CMake? (Or do we need to go on and modify the INSTALL commands in
CMake itself to use the new #1 feature above to change CMake's
installation?)
Best regards,
James Johnston
--
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
