Maybe I’m atypical but I normally don’t run with an admin account until the software I am installing is ready to be installed. That is, for an open-source project, my sequence will typically be:
- Clone or checkout project
- Configure it
- Compile it
- Test it (optional)
- Install it
With OCIO, since I don’t have pystring and it’s not installable via Homebrew (the macOS package manager I use), I end up getting pystring installed as part of the OCIO install. If I don’t have admin privileges when it comes to installation I get something like this:
… [tons of stuff elided] …
build succeeded, 158 warnings.
The HTML pages are in build-html.
Copying tabs assets
[100%] Built target docs
Install the project...
-- Install configuration: "Release"
CMake Error at include/OpenColorIO/cmake_install.cmake:41 (file):
file cannot create directory: /usr/local/include/OpenColorIO. Maybe need
administrative privileges.
Call Stack (most recent call first):
include/cmake_install.cmake:42 (include)
cmake_install.cmake:43 (include)
make: *** [install] Error 1
(returned status 2) 1072 %
I do appreciate the “Maybe need administrative privileges” hint. I mean that sincerely.
If I su to admin and retry, I end up with this:
(returned status 2) 1072 % su admin
Password:
su: Sorry
(returned status 1) 1073 % su admin
Password:
admin@Pikachu build % make install /Users/jgoldstone/repos/git/ocio/build
Performing update step for 'pystring_install'
Performing patch step for 'pystring_install'
Error copying file "/Users/jgoldstone/repos/git/ocio/share/cmake/projects/Buildpystring.cmake" to "CMakeLists.txt".
make[2]: *** [ext/build/pystring/src/pystring_install-stamp/pystring_install-patch] Error 1
make[1]: *** [CMakeFiles/pystring_install.dir/all] Error 2
make: *** [all] Error 2
admin@Pikachu build % emacs ext/build/pystring/src/pystring_install-stamp/pystring_install-patch /Users/jgoldstone/repos/git/ocio/build
admin@Pikachu build % ls !$ /Users/jgoldstone/repos/git/ocio/build
ls ext/build/pystring/src/pystring_install-stamp/pystring_install-patch
ext/build/pystring/src/pystring_install-stamp/pystring_install-patch
admin@Pikachu build % ls -l !$ /Users/jgoldstone/repos/git/ocio/build
ls -l ext/build/pystring/src/pystring_install-stamp/pystring_install-patch
-rw-rw-r-- 1 jgoldstone 702229781 0 Dec 29 22:31 ext/build/pystring/src/pystring_install-stamp/pystring_install-patch
admin@Pikachu build %
The root cause seems to be that unlike many install targets I have known, the installation process tries to mutate not just the installation directories, but the source directories as well. Is this standard practice and I’ve just been lucky with my 5-step strategy at the top of this email? Or is OCIO (or perhaps it’s some cmake template/structure/whatever that OCIO is customizing) being a little weird here?
— — later — —
By manually compiling pystring copying the header to /usr/local/include/pystring/pystring.h and a static library version containing to the .o to /usr/local/lib/libpystring.a, and adding -Dpystring_ROOT=/usr/local -Dpystring_STATIC_LIBRARY=TRUE to the cmake invocation, I got around the pystring issue.
There are at least two more places where the install modifies the build dir or its subdirs. The first I forgot to write down; the second is the build dir itself, where it wants to write an install_manifest.txt file. Rather than finesse this, I realized that the build dir was disposable, and therefore not really a security concern if I deleted it afterwards; so after the make and before the make install, sitting in the build dir I did a chmod -R o+w . Which seemed to work.
So, again: I feel as if most ‘make install’ steps treat the build directories as a read-only filesystem. OCIO doesn’t. Do I have a skewed view of most open-source projects’ viewpoints here, or is OCIO genuinely different?
