ci: Add a VFX 2026 platform test

[lgritz]

And some minor tweaks for gcc14 + C++20 warnings

[jfpanisset]

For the 2026 build case I see in comments:

# setenvs: export CTEST_EXCLUSIONS="broken|python-oslquery"

but in fact this is still broken since the OpenImageIO Python module is not available in those images, which in turn is breaking that build. Should that exclusion be enabled for now until OIIO Python bindings can be built?

I've spent quite a bit of time trying to trace the CMake code in OIIO but although the build configuration script for OIIO finds the CPython Conan dependency, it decides that it doesn't provide the Development component it needs to build bindings (other projects are OK with this):

-- Found Python3 3.13.3
...
-- Not building Python bindings: USE_PYTHON=ON, Python3_Development.Module_FOUND=FALSE

[lgritz]

For the 2026 build case I see in comments:

# setenvs: export CTEST_EXCLUSIONS="broken|python-oslquery"

Sorry, I was just testing that to see if it was fixed in 2026, but apparently not. I'll leave that test excluded for now.

I've spent quite a bit of time trying to trace the CMake code in OIIO but although the build configuration script for OIIO finds the CPython Conan dependency, it decides that it doesn't provide the Development component it needs to build bindings (other projects are OK with this):

So you are saying that the Conan OIIO build recipe itself disables building the Python bindings?

Or that we need to change something on our end?

[jfpanisset]

As of the releases this week, when building OIIO I try to enable building Python bindings:

Enable with_python option in conanfile.py

Set USE_PYTHON CMake variable

but OIIO's CMake code doesn't seem to interact correctly with the auto-generated CMake from the cpython Conan package and decides that although it finds the Interpreter, it doesn't find the Development component (aka libpython) and disables building the bindings. Spent a bunch of time tracing through the CMake code, but didn't manage to find the culprit. I very much want to make this work, especially now that I know that the bindings are exercised by the OIIO test suite, but it's definitely stretching the limits of my minimal CMake knowledge.

In a Conan environment, the dependencies specified by requires() statements in the Conan recipe don't get installed in a standard location, they are pulled directly from the internal Conan cache with paths that include hexadecimal hash directory names. Conan auto generates CMake code for each package that is meant to help a non-Conan-aware package to be able to find the Conan dependency with a simple find_package() but OIIO is definitely not the only case where the package's CMake code doesn't play well in a Conan environment.

In the ci-osl build container, all of the Conan packages have been installed and flattened into /usr/local so no more Conan involved at that point.

[lgritz]

but it's definitely stretching the limits of my minimal CMake knowledge.

And this is stretching the limits of my Conan knowledge.

All I know is that OIIO's build system by itself does build the Python bindings just fine. So I'm not sure I know why Conan would be causing it to not work.

For OSL CI, of course I can just build OIIO myself and not rely on the container version (and I do, in order to test various versions that aren't in the ASWF containers). But maybe other people would expect/want it to work in the ASWF containers natively?

[lgritz]

This looks relevant: https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/src/cmake/pythonutils.cmake#L36

Maybe we also need to make this change when using the conan components?

What if we change those lines to simply

        set (_py_components Interpreter Development Development.Module)

across all platforms???

[jfpanisset]

My goal is:

• provide all dependencies for project XXXX in container image ci-XXXX so the project can exercise "pick up pre-installed dependencies" code paths (as well as save time for the big dependencies)
• turn on as many build options as possible when building the project itself

For the latest builds I was able to get libraw and OpenJPEG built into OIIO, building Python bindings will be next priority (also OpenVDB, that one should hopefully be straightforward).

libheif is going to be more work since that pulls in ffmpeg, but that will have to be done.

For now if you need OIIO with Python bindings you may want to keep building your own, I'll late you know when I manage to turn on more options. I've got issues to track this:

AcademySoftwareFoundation/aswf-docker#272

AcademySoftwareFoundation/aswf-docker#264

I had run across the "manylinux" code in pythonutils.cmake and tried using:

set (_py_components Interpreter Development)

but that didn't get CMake to find the Development component. But I won't give up!