OIIO is missing in VFX CY2024 and VFX CY2025 CI builds.

[cozdas]

Looks like containers for CY2024 and CY2025 don't have OIIO in them thus the CI builds that are set to exercise OIIO build without OIIO.

Log snippet from the "Linux VFX CY2024 <Clang config=Debug, shared=ON, simd=ON, cxx=17, docs=OFF, oiio=ON>", Configure step:

-- Checking if the OpenImageIO found is built with OpenEXR 3+...
-- Could not find OpenImageIO header to evaluate the OpenEXR version.
-- Please provide the OpenImageIO_DIR variable.
-- If your OpenImageIO's files are located in different root directory, please provide the OpenImageIO_ROOT where the include files are located.

Older containers 2022 and 2023 do have OIIO, and CI builds use them as intended.

[jfpanisset]

The ci-XXXX containers are now assembled from Conan packages, and can't capture the circular dependency between OCIO and OIIO. When building the OCIO Conan package, the aswf-docker project turns off OCIO_USE_OIIO_FOR_APPS:

https://github.com/AcademySoftwareFoundation/aswf-docker/blob/d9431fc8777257b5a17adcad900c7ad6b8d8baab/packages/conan/recipes/ocio/conanfile.py#L142

Since OIIO depends on OCIO, it isn't possible to "cleanly" include OIIO in the ci-ocio container (which only includes the dependencies of OCIO, and not OCIO itself).

As a workaround, in order to exercise building OCIO apps linked against OIIO, you would need to use an image which includes an OIIO build such as ci-rawtoaces or ci-vfxall with the caveat that these images will already include a build of OCIO installed in /usr/local/ (binaries and include files), so you will need to be extra careful to avoid picking up / mixing those include files and libraries with the OCIO version you want to build.

Ideally OCIO tools could be moved to a separate repo which would allow for a clean layering / dependency graph between OCIO and OIIO.

[cozdas]

Thanks for the clarification Jean-Francois,
Remi already suspected that the new cyclic dependency might be the reason behind the exclusion, good to have the confirmation.

[jfpanisset]

The cyclic dependency has been around "forever" from what I understand, the ability to build the OCIO tools without OIIO support was explicitly added a few years ago to break the cycle.

https://github.com/AcademySoftwareFoundation/aswf-docker/blob/main/python/aswfdocker/data/versions.yaml

gives a hint of the hierarchy of ASWF project dependencies:

• Layer 1
  • imath
• Layer 2
  • openexr
  • openfx
• Layer 3
  • ocio
  • openvdb
• Layer 4:
  • oiio
• Layer 5:
  • rawtoaces
  • materialx
  • OSL

Once the transition to building everything as Conan is completed, I plan on publishing auto-generated dependency graphs derived from Conan recipes.

[zachlewis]

The cyclic dependency has been around "forever" from what I understand, the ability to build the OCIO tools without OIIO support was explicitly added a few years ago to break the cycle.

OIIO's build system provides a workaround for this -- one can force OIIO-3.x's build system to locally pull, build, and statically link OpenColorIO by providing to cmake -DOpenImageIO_BUILD_LOCAL_DEPS=OpenColorIO and -DLINKSTATIC=1.

(This is similar to what we're doing for the official OpenImageIO python wheels -- we use -DOpenImageIO_BUILD_MISSING_DEPS=all -DLINKSTATIC=1, and OIIO's build system automatically does the rest, including imath and openexr (but not openvdb)).

[lgritz]

I don't think you need -DLINKSTATIC=1 (which would affect all libraries), because the auto-build for OCIO is hard-coded already for static libraries.