OpenColorIO library CMakeLists.txt: Sets up GNUInstallDirs for non-win but completely ignores it in install(TARGETS...

[hobbes1069]

OpenColorIO/src/OpenColorIO/CMakeLists.txt

Lines 181 to 193 in bc88857

	if(NOT WIN32)
	# Install the pkg-config file.
	include(GNUInstallDirs)
	set(prefix ${CMAKE_INSTALL_PREFIX})
	set(exec_prefix "\${prefix}")
	set(libdir "\${exec_prefix}/${CMAKE_INSTALL_LIBDIR}")
	set(includedir "\${exec_prefix}/${CMAKE_INSTALL_INCLUDEDIR}")
	configure_file(res/OpenColorIO.pc.in ${CMAKE_CURRENT_BINARY_DIR}/OpenColorIO.pc @ONLY)
	install(FILES ${CMAKE_CURRENT_BINARY_DIR}/OpenColorIO.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
	endif()

and then:

OpenColorIO/src/OpenColorIO/CMakeLists.txt

Lines 297 to 301 in bc88857

	install(TARGETS OpenColorIO
	LIBRARY DESTINATION lib
	RUNTIME DESTINATION bin
	ARCHIVE DESTINATION lib
	)

Why go to the trouble of setting up the right directories and then just not use them?

[hobbes1069]

I see this is still a problem in 2.1.0. Hardcoding install paths is BAD.

Here's my fix:

$ cat ocio-install.patch
Index: OpenColorIO-2.1.0/src/OpenColorIO/CMakeLists.txt
===================================================================
--- OpenColorIO-2.1.0.orig/src/OpenColorIO/CMakeLists.txt
+++ OpenColorIO-2.1.0/src/OpenColorIO/CMakeLists.txt
@@ -293,7 +293,7 @@ endif()
 
 install(TARGETS OpenColorIO
 	EXPORT ${PROJECT_NAME}_EXPORTED_TARGETS
-	LIBRARY DESTINATION lib
-	RUNTIME DESTINATION bin
-	ARCHIVE DESTINATION lib
+    LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
+    ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
 )

[remia]

Thanks for the suggestion @hobbes1069, I implemented that, among other things, in #1471 would be great if you could have a look.

[hobbes1069]

LGTM!

[remia]

@hobbes1069 Would be curious if you have an example where the current hardcoded script fails or produce unexpected results, so that we are aware of what kind of changes we can expect for existing users? Thanks.

[hobbes1069]

Specifically in my case as a Fedora Linux packager, libraries go into either /usr/lib or /usr/lib64 depending on if they're 32 or 64bit. Debian based systems have a different but equivalent file hierarchy. There's also a chance someone will want to build OCIO as a subproject, such as cross compiling from Linux to Windows using MinGW, and set some sort of custom path.

[remia]

Thanks, that makes sense, I was expecting Windows differences related to the build configuration but forgot about these architecture issues. Agree that the less we hardcode the better, especially when CMake override are available.

[hodoulp]

I reopened the issue because the pull request is not yet merged.