Add OpenColorIOConfig.cmake generation

[remia]

This address issue #1187, the proposed implementation is based heavily on OpenImageIO.

Current implementation have a very simple Config.cmake.in template, as opposed to OpenImageIO which take cares of dependencies and set variables. According to some quick test I did, it doesn't seems needed here but happy to be proved wrong.

More anecdotally, I noticed that when I used the find_package(OpenColorIO CONFIG) directive, while it works, it doesn't print anything like the version found and path you usually see. Any ideas ?

[lgritz]

LGTM. After it's merged and I can try using it in OIIO's CI builds, I'll let you know if anything needs revision. But it seems reasonable to me.

There's some extra complexity in OIIO's config because there are dependencies on Imath/OpenEXR whose types get exposed in OIIO's exported APIs. But I don't think OCIO has anything like that where dependencies are directly exposed in your APIs, so you don't need to worry about that.

[hodoulp]

LGTM based on my curent understanding and the cmake documentation.

But I still have something to highlight which seems 'wrong' without being able to explain it. In the generated file ../install_rls/lib/cmake/OpenColorIO/OpenColorIOTargets-release.cmake there is one unexpected line about IlmBase:

set_target_properties(OpenColorIO::OpenColorIO PROPERTIES
  IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE "IlmBase::Half"
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libOpenColorIO.2.1.0.dylib"
  IMPORTED_SONAME_RELEASE "@rpath/libOpenColorIO.2.1.dylib"
  )

All third-party dependencies are statically linked so the library itself and its targets must be hidden.

[remia]

All third-party dependencies are statically linked so the library itself and its targets must be hidden.

Is that always true ? I just looked at dependent library on my macOS build and found that it link expat dynamically, I was not expecting that, could that be the same for you with Half ?

myinstall/lib/libOpenColorIO.2.1.0.dylib:
  @rpath/libOpenColorIO.2.1.dylib (compatibility version 2.1.0, current version 2.1.0)
  /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0)
  /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 164.0.0)
  /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
  /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
  /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync (compatibility version 1.0.0, current version 4.7.0)
  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1775.118.101)
  /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1463.4.2)

Currently I can't reproduce your issue though, my cmake target file doesn't contains the IlmBase::Half link import. Can you share more details on how you built it ?

set_target_properties(OpenColorIO::OpenColorIO PROPERTIES
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libOpenColorIO.2.1.0.dylib"
  IMPORTED_SONAME_RELEASE "@rpath/libOpenColorIO.2.1.dylib"
  )

Edit: looks like the dynamic expat link is acknowledge in the build system and can be controlled with expat_STATIC_LIBRARY so that's probably completely unrelated.

[hodoulp]

All third-party dependencies are statically linked so the library itself and its targets must be hidden.

Is that always true ? I just looked at dependent library on my macOS build and found that it link expat dynamically, I was not expecting that, could that be the same for you with Half ?

Finally, I have time to double-check, and the half unexpected dependency is gone!

[hodoulp]

Without being a cmake expert, everything seems fine.

[lgritz]

I didn't catch this originally (despite having approved it, sorry), but is there a reason why you made a separate target for the headers than for the library? It's not wrong per se, but it's very unusual, and I don't think I've seen it in any other projects (except those who have an option to do something useful in a header-only way and want to be able to avoid pulling in the library). Usually the main library target also knows about the header files, too, so you only need to mention that one target.

[remia]

@lgritz Agreed, I don't believe there is a strong reason to have these two different targets either, and this shows up in the generated config file (although it's probably harmless). I'll look if I can remove it to simplify things.