Adsk Contrib - Support Yaml 0.9.0 and other build fixes

[doug-walker]

As requested by @lgritz, this PR adds support for Yaml 0.9.0 and makes it the recommended version, which gets installed when OCIO_INSTALL_EXT_PACKAGES is set to MISSING or ALL. Addresses issue #2340.

Support for Yaml 0.9.0 simplifies building OCIO with gcc-15.

In addition, it fixes a build problem on Windows where recent vcpkg installs of glew no longer seem to have glu. This only seems to be necessary for gluErrorString, and it required pulling in windows.h. So another potential fix would just be to not use gluErrorString, as is done on macOS. Any opinions on that?

In addition, it fixes a bug in how the version of minizip_ng was being detected, as pointed out by @jfpanisset in issue #2314.

Assisted by: Claude Code / Sonnet 5

[jfpanisset]

For context here's what I currently do in aswf-docker ci-ocio images. The version of yaml-cpp:

• 2023: 0.8.0
• 2024: 0.8.0
• 2025: 0.8.0
• 2026: 0.8.0
• 2027: 0.9.0

Since for now I'm building 2027 images with OCIO 2.5.2, that demonstrates that you can build / link at least 2.5.2 against 0.9.0. Since OCIO wants to be able to build its latest version against older VFX Platform images, I can update the 2023-2026 images to yaml-cpp 0.9.0 to make that easier.

As for minizip-ng, I'm already including minizip-ng 4.0.10 in 2023-2026 (and rev'ed up to 4.2.1 for 2027), and for OCIO 2.2.1 builds for vfx2023 I apply this patch to support building against minizip-ng 4:

https://github.com/AcademySoftwareFoundation/aswf-docker/blob/d14a1c2c94ca88fbbabb9c966f6e6fe371b6a4cb/scripts/vfx/build_ocio.sh#L46

[doug-walker]

Following up on the TSC discussion today, I've made the following updates to the dependencies. I'm listing the minimum and recommended versions (the latter is what OCIO installs when requested). Arrows indicate where I've increased the version. And I list the current latest version of each package.

Library external dependencies

expat

• min: 2.6.0
• rec: 2.7.2 --> 2.8.4 (current 2.8.4, has CVE fixes)

yaml-cpp

• min: 0.8.0
• rec: 0.8.0 --> 0.9.0 (current 0.9.0)

pystring

• min: 1.1.3
• rec: 1.1.4 (current 1.2.0)

Imath

• min: 3.1.1
• rec: 3.2.1 --> 3.2.3 (current 3.2.3)

zlib

• min: 1.2.13
• rec: 1.3.1 --> 1.3.2 (current 1.3.2, has CVE fixes)

minizip-ng

• min: 4.0.0 --> 4.0.5
• rec: 4.0.10 --> 4.2.2 (current 4.2.2)

Library vendored

sampleicc (not maintained)

xxhash 0.8.1 (current 0.8.4)

In addition to the Actions runs, I've gotten the local build/tests to pass on macOS (arm64, x86_64), Windows, and Linux.

The only actual library code change was to modify how exceptions are handled due to changes in the most recent expat. We have a lot of unit tests around the XML parsing, so hopefully this is solid.

[cozdas]

Looks great.

Regarding the glu issue, the current fix looks correct but considering that multiple new developers hit glew/glut/glu related build problems in the past, and glu being deprecated many years ago I'm ok with removing the glu entirely. We can either return generic error string like mac does or add utility function to convert error enums to string.

There's another glu function usage in oglapp.cpp (gluOrtho2D) but that one seems ok as in that case glu is included via freeglut. Looks like it can be replaced with glOrtho() easily too if needed.

I'm ok with keeping the current glu fix as is and creating a ticket to remove glu in glsl.cpp in a later version.

[doug-walker]

@remia, my latest commit makes a fix to get the Wheel workflow back online, please take a look.

[remia]

That seem reasonable, thanks @doug-walker, maybe we should consider dropping manylinux2014 but that can be done somewhere else.

According to Claude:

Who would lose wheels if you drop it: only Linux users with glibc older than 2.27. Your manylinux_2_28 wheels are also tagged manylinux_2_27, so Ubuntu 18.04 is already covered. What's left:

RHEL/CentOS 7 and its clones: studios still on CY2022 or older pipelines, and paid extended-support RHEL 7.
Amazon Linux 2, which reached end of support on 30 June 2026.
Very old distros such as Debian 9, Ubuntu 16.04 and SLES 12.

Those users would fall back to building from the sdist, which is painful for a C++ project, so say so in the release notes.