Date
1 - 2 of 2
'make install' not supportive of only using admin for the install and not the compile
|
Michael Dolan
There is some convenience CMake built into OCIO which will download (to the build dir), compile and statically link core dependencies at build time. In OCIO v1 the core dependencies were embedded in the repo so no download was necessary (though they were still unpacked to the build dir and patched before building), but we had to change that when we moved over to the ASWF to adhere to FOSS standards. The CMake option OCIO_INSTALL_EXT_PACKAGES is what controls this behavior. It defaults to MISSING so that only missing components are downloaded. It can also be set to ALL to make a fully self-contained OCIO core build, or NONE to prevent any of these steps. Your solution to set <package>_ROOT=<my location> is the right one. OCIO sees the build dir (where CMake is run from) as a temporary workspace to get OCIO built, so will create files in there as needed, as well as populate templated files from the source tree. That's why we don't recommend running a build from the source tree, which will pollute the structure considerably.These downloaded dependencies are not installed on your system's install location (CMAKE_INSTALL_PREFIX) though, just statically linked into OCIO binaries and considered throw away beyond that. It is not very common for OSS projects to download and build dependencies for you automatically, but the build directory being a mutable workspace is generally necessary, for CMake to generate its make files if for nothing else. So in summary, there are generally three locations in play when building a project: source, build, and install locations. The source location should remain untouched during a build (unless you build in the source tree). The build dir is fair game for the build process to write to as needed. The install dir should only receive final build files which the project has instructed CMake to install. In a typical build the install dir is the one needing permissions since it could be a system location. Let me know if I misunderstood your issue question though. On Wed, Dec 30, 2020 at 11:32 AM Joseph Goldstone <joseph.goldstone@...> wrote:
|
|
|
|
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:
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? |
|
|