'make install' not supportive of only using admin for the install and not the compile


Joseph Goldstone
 

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:
  1. Clone or checkout project
  2. Configure it
  3. Compile it
  4. Test it (optional)
  5. 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?






Join ocio-dev@lists.aswf.io to automatically receive all group messages.