CMake Minimum

[Colin Doncaster]

Hi all,

As CMake has become the defecto build system for many of the projects cited in the VFX reference platform, and in light of the 4.0.0 release, I was wondering if it’s worth citing a minimum CMake version on the list?

This would likely be for the dependencies to adhere to themselves vs. DCC’s requirements. There are wider community dependencies we won’t have control over, but it would be good to ensure the ones we do have control over stay compatible with each other?

Colin

[Neal Gompa]

I brought this up a couple years ago[1], and I do think it's still relevant now.

That said, I would really prefer we not make the minimum version CMake
4.0, as we're still dealing with the fallout in Fedora and had to
rollback the cmake package because of all the breakage. A dedicated
Change to upgrade to CMake 4.0 is being worked on for Fedora 43[2].

Qt 6.9 raises the minimum CMake for itself to 3.22, and I think that's
probably a reasonable floor. I'm also okay with the latest CMake 3.x
version too, it just means we'll need to get it upgraded in CentOS 9 and
CentOS 10 as those are at 3.26 and 3.30 respectively.

[1]: https://groups.google.com/g/vfx-platform-discuss/c/9fF08T6HNug
[2]: https://fedoraproject.org/wiki/Changes/CMake4.0




--
真実はいつも一つ！/ Always, there's only one truth!

[Larry Gritz]

This feels like a really different situation than everything else on the VFX Platform list and what it is meant to address. 

To use a made-up example, if Maya uses OpenColorIO 2.1 and exposes the symbols, and Houdini uses OpenColorIO 2.2, and you are writing a library that wants to use 2.3, that makes it very hard for Maya and Houdini plugins to use your library, they are all making mutually incompatible choices that prevent them from existing in the same address space. This kind of thing in fact used to happen all the time. So VP says "let's all use 2.2 this year" to diffuse the conflict.

Cmake just isn't like that. Maya, Houdini, your library, and the plugins are all free to use different versions of cmake without any conflict, because cmake choice only matters at build time of each package individually, and they carry no remnants of that choice to runtime.

CMake screwed up here, IMHO. And some distro package managers screwed up by pushing out a compatibility-breaking version as the default too soon after its initial release, before all the packages had time to test it as an optional upgrade and get ready. And some libraries screwed up by setting their CMake compatibility many years ago and never revisiting it to change it to a range, once ranges were allowed as of 3.12. VFX Platform did fine, I don't think anything needs adjustment there.

I'll say also, no projects in our immediate ecosystem needs adjustment. As shown by the VFX Industry Build Matrix , all the vfx-centric open source projects had cmake minimums above the 3.5 cutoff, so shouldn't have had any problem with cmake 4.0 (except for rez -- but this spreadsheet may be out of date and maybe rez is fine, I wouldn't know). We all stayed modern enough to avoid a problem. Many of our projects' CI testing were, however, victims of the change because some of our dependencies (pybind11, zlib, and others) did not have more modern cmake minimum compatibility and so building those dependencies from source with the new cmake failed. No change to VFX Platform would fix that, either, because none of those packages even know VP exists.

-- lg

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/0874C7E4-61B1-4D87-B3DB-E6B23B2BBC7A%40peregrinelabs.com.

--

Larry Gritz

l...@larrygritz.com

[Larry Gritz]

TL;DR:

Our projects had a lot of chaos because of cmake 4.0 in the last few days, but none of that was because of our projects themselves. We had to scramble to deal with the fact that some of our dependencies -- which don't listen to VFX Platform list at all -- had out-of-date cmake build systems that were incompatible with the new cmake.

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/4135986E-B2F2-4953-835D-D69B5BDC322E%40larrygritz.com.

--

Larry Gritz

l...@larrygritz.com

[Colin Doncaster]

Understood. 

One thought was that if there was a minimum CMake version cited then dependencies could be audited, if they don’t meet the minimums they are flagged in some way as “of concern”.  As we don’t have ownership over the projects but rely on them, they could be forked and updated to meet the VFX platforms requirements in a pro-active way.  

I’m also sure we’re not the only vendor building all of the VFX platform internally?  Our main dependencies CMake will pull the correct version for the requested CY from various GitHub repos and everything is built from source when a new distribution build is made (including ZLib, hdf5, etc.).  

As pointed out, for the most part a lot of the top level dependencies have no CMake compatibility issues, but it’s at this stage where the CMake version can/could impact project consumers.  

Luckily most of the cmake config and Find* artifacts are pretty simple and we have patches applied or forked repos for those that have posed issues. 

As you say, it sounds like it might not be the right place for it and any 4.0.0 pain was due to external factors.  

Colin

[Neal Gompa]

I would hope that instead of "forking" we'd attempt to contribute to
fix the projects. Forking projects just for this isn't worth it.

> To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/265467ED-D90F-4954-8809-4F17F803F577%40peregrinelabs.com.

[Larry Gritz]

It's actually more complicated than that.

A package may have said `cmake_minimum_required(VERSION 3.0)` and in fact verified through testing that it worked with every cmake from 3.0 all the way up through 3.31 and thought there was nothing to do: "my package works fine with the latest cmake as of yesterday." They may also have thought "as long as I don't make my package BREAK against cmake 3.0, there's no reason to raise the minimum, that is indeed the oldest version I support."

But the cmake 'cmake_minimum_required()' function is confusingly named, in a sense. You think you are declaring the minimum version you need, but what you're actually doing is declaring what backward compatibility you demand from CMake. 

What CMake did with 4.0 is drop support for emulating anything less than 3.5, erroring for packages that asked for compatibility older than that. So in a sense, what really changed was that a new maximum popped up for projects. Other than new cmake rejecting that old requested minimum, there was actually not anything else in the cmake files that wouldn't work with 4.0 (or with any of the 3.x's). 

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/265467ED-D90F-4954-8809-4F17F803F577%40peregrinelabs.com.

--

Larry Gritz

l...@larrygritz.com

[Larry Gritz]

Nobody needs to fork anything. The new cmake takes a hacky variable (or you can set an environment variable) that overrides the declared minimum of a package you're building. Set that to 3.5 and you're done, you don't need to change the actual files of any dependencies. (Assuming that the package is still compatible with cmake 3.5.)

On Apr 3, 2025, at 11:30 AM, Neal Gompa <ngom...@gmail.com> wrote:

I would hope that instead of "forking" we'd attempt to contribute to
fix the projects. Forking projects just for this isn't worth it.

--

Larry Gritz

l...@larrygritz.com