[package] opencolorio/2.1.0: Cannot be built from source if profile defines compiler.libcxx

[jcar87]

Package and Environment Details

• Package Name/Version: opencolorio/2.1.0
• Operating System+version: Linux Ubuntu 20.04
• Compiler+version: Clang 10
• Docker image: n/a
• Conan version: conan 1.50.0
• Python version: Python 3.8.10

Conan profile

[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=clang
compiler.version=10
compiler.libcxx=libstdc++11
compiler.cppstd=14
build_type=Debug
[options]
[conf]
[build_requires]
[env]
CC=/usr/bin/clang-10
CXX=/usr/bin/clang++-10

Steps to reproduce

conan install opencolorio/2.1.0@ -pr clang-debug --build=missing

Logs

Click to expand log

opencolorio/2.1.0: Calling build()
-- The C compiler identification is Clang 10.0.0
-- The CXX compiler identification is Clang 10.0.0
-- Check for working C compiler: /usr/bin/clang-10
-- Check for working C compiler: /usr/bin/clang-10 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/clang++-10
-- Check for working CXX compiler: /usr/bin/clang++-10 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting language standard
-- Conan setting CPP STANDARD: 14 WITH EXTENSIONS OFF
-- Conan: Adjusting fPIC flag (ON)
-- Conan: Compiler Clang>=8, checking major version 10
-- Conan: Checking correct version: 10
-- Conan: C++ stdlib: libstdc++11
CMake Error at source_subfolder/share/cmake/utils/CppVersion.cmake:19 (set_property):
  set_property could not find CACHE variable CMAKE_CXX_STANDARD.  Perhaps it
  has not yet been created.
Call Stack (most recent call first):
  source_subfolder/CMakeLists.txt:104 (include)


-- Performing Test COMPILER_SUPPORTS_CXX14
-- Performing Test COMPILER_SUPPORTS_CXX14 - Success
-- Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_INCLUDE_DIR OpenGL) 
-- Use "OpenGL_ROOT" to specify an install location
-- Could NOT find GLEW (missing: GLEW_INCLUDE_DIRS GLEW_LIBRARIES) 
-- Use "GLEW_ROOT" to specify an install location
-- Could NOT find GLUT (missing: GLUT_glut_LIBRARY GLUT_INCLUDE_DIR) 
-- Use "GLUT_ROOT" to specify an install location
CMake Warning at source_subfolder/share/cmake/utils/CheckSupportGL.cmake:47 (message):
  GPU rendering disabled
Call Stack (most recent call first):
  source_subfolder/CMakeLists.txt:140 (include)

[jcar87]

A user reports being unable to build this package from source in one of the comments in the conan-io/conan#11695 thread.

I have been able to reproduce this.

This is a combination of a few things:

• The entire build tree is wrapped in another CMake project, as per

  conan-center-index/recipes/opencolorio/all/CMakeLists.txt

  Lines 4 to 5 in 31e2674

  	include(conanbuildinfo.cmake)
  	conan_basic_setup(KEEP_RPATHS)

• The profile defines compiler.cppstd=14, which causes conan_basic_setup() (as called above) to do

set(CMAKE_CXX_STANDARD ${CONAN_CMAKE_CXX_STANDARD})

• The CMakeLists of the project itself have logic that requires CMAKE_CXX_STANDARD to be a cache variable:
• https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/share/cmake/utils/CppVersion.cmake#L19

set_property(CACHE CMAKE_CXX_STANDARD PROPERTY STRINGS "${SUPPORTED_CXX_STANDARDS}")

Because the variable is previously set by Conan, but not as a cache variable this call fails.

I don't think CMake themselves prescribe CMAKE_CXX_STANDARD to be one or the other (cache or local) - in this case, I would imagine the project is setting is a cache variable for "stylistic" reasons - setting the STRINGS property on the variable to a list of strings will cause cmake-gui and ccmake to constrain the value to a set of options, rather than leave it as a freeform strings, and making it a cache variable will cause it to show on the GUI to modify it if necessary.

While it could be argued that perhaps that behaviour makes the project not suitable to be included as part of a different CMake tree (rather than be the root of the tree itself), we may want to consider patching this to make the logic more robust. If done properly I'd imagine that this is something that can be contributed upstream without impacting their desired functionality.

[SpaceIm]

It should be patched to rely on cxx compile features. CMAKE_CXX_STANDARD should never be set in the CMakeLists of a library (it should come from user, either in command line arguments or preset). It's a never ending story due to the huge amount of bad CMakeLists.

[jcar87]

It should be patched to rely on cxx compile features. CMAKE_CXX_STANDARD should never be set in the CMakeLists of a library (it should come from user, either in command line arguments or preset). It's a never ending story due to the huge amount of bad CMakeLists.

I wouldn't jump to the conclusion and disqualify these as "bad" CMakeLists. Having inspected the build script from this library, the maintainers of OpenColorIO take a cautious and sensible approach of only setting it if it was not already previously defined, and if it is previously defined, they assume a cache variable (as is the case with variables passed as command line arguments).

In this instance however, it is previously defined but not as a cache variable, and thus the error.

I'm not sure what the arguments are for considering this universally bad practice - setting it as a regular variable in the top-level CMakeLists.txt (after the first call to project()) is explicitly mentioned as a perfectly valid approach, at least on this book by one of the CMake co-maintaiers, also on this blog post:
https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/. Using compile features at the target level is also a perfectly valid approach, I don't think we can fault library maintainers for favouring simplicity.

A point to be made is that perhaps very few CMakeLists maintainers write the scripts with an eye on supporting the entire project to be included as part of a different tree - and assume they are the root tree, or that some variables are to be globally defined (as cache variables) instead of being restricted to their scope.

[timeinpixels]

Is there any workaround to fix the build on my machine?

[AbrilRBS]

This has been fixed for a while now, openimageio compiles correctly in Conan 2