Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The 'install' -target for make tries to change permissions on existing directories #160

Open
Peanhua opened this issue Nov 21, 2022 · 4 comments

Comments

@Peanhua
Copy link

Peanhua commented Nov 21, 2022

If I have the installation target "include" and other directories already in place, I do not wish to see their permissions altered in any way.

This can be tested for example with the following:

$ sudo bash -c 'rm -rf /tmp/f ; mkdir -p /tmp/f/{bin,include,lib,src} && chmod go-w /tmp/f && chmod go+w /tmp/f/*'
$ tar xf ozz-animation-0.14.1.tar.gz
$ cd ozz-animation-0.14.1
$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/tmp/f ..
$ cmake --build ./
$ make install
<snip>
Install the project...
-- Install configuration: ""
-- Up-to-date: /tmp/f/./include
CMake Error at cmake_install.cmake:46 (file):
  file INSTALL cannot set permissions on "/tmp/f/./include": Operation not
  permitted.


make: *** [Makefile:130: install] Error 1

The above test should finish without errors. The behavior is same with the 0.14.1 release and current master branch.

@guillaumeblanc
Copy link
Owner

Hi,

thanks for reporting the issue.
I know very little about permissions, and I think in this case everything is managed by cmake.

Could you have a look to cmake install command documentation and share your recommendations?

Regards,
Guillaume

@Peanhua
Copy link
Author

Peanhua commented Nov 23, 2022

Before jumping into CMake scripting, I think it'd be good idea to step back and think what is the goal here.

First of all, I'm on Linux system, things are probably different in other systems.

The default installation prefix is set to be "/usr/local", for me that is a sign the Filesystem Hierarchy Standard (FHS) is being used. If the default prefix would have contained the project name, then I wouldn't necessarily had made that assumption.

Here are couple links about the FHS:
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

So I do not know if you intend to follow FHS and what you actually want to accomplish with the 'install' make target.

In the case that you did/do not intend to follow the FHS, then this issue and the other one can be ignored. But to avoid confusion, it would be good idea to change the default installation prefix to contain the project name.

In the case that you did/do intend to follow the FHS, then there are basically two choices, either /usr/local or /opt. Personally I would prefer /usr/local because then the installed libraries would be automatically in my search path, without needing to add yet another include and lib -directory when compiling/linking my projects.

@guillaumeblanc
Copy link
Owner

Hi,
I'm not used enough to it, could you propose a change to conform install?
Regards,
Guillaume

@Peanhua
Copy link
Author

Peanhua commented Aug 11, 2023

Before I could even start to propose any changes, I would need to know whether you are intending to follow FHS or not?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants