Support for building with C++ 20 for VFX Platform 2026

[jfpanisset]

Problem

Currently the top level CMakeLists.txt forces the C++ standard to 17:

set(CMAKE_CXX_STANDARD 17)

For 2026 the VFX Platform specifies C++ 20 as the API/SDK version. When building in a VFX Platform 2026 Conan environment this results in:

#24 3.452 -- Warning: Standard CMAKE_CXX_STANDARD value defined in conan_toolchain.cmake to 20 has been modified to 17 by /opt/conan_home/d/b/openf69bc4c21731b6/b/CMakeLists.t
xt

Since OpenFX manages C++ plugins which have to conform to a certain ABI, I'm not sure how tightly coupled the C++ version of the host application, the OpenFX library and the plugins are, and how that interacts with the VFX Platform.

[jfpanisset]

Also the CMakeLists.txt in https://github.com/AcademySoftwareFoundation/openfx/blob/main/test_package/CMakeLists.txt forces C++ 14:

set(CMAKE_CXX_STANDARD 14)

[revisionfx]

For the general question, it's C header files at the root, no shared library code - so should not have any impact in theory.

Pierre

[garyo]

As Pierre says, the core OpenFX API is C-only (see the include dir) and plugins should only expose a small set of C functions, so anything they do internally is up to them. The intent is that a plugin could even be written in rust or some other language. But we do have optional support libs for host and plugins, and those use C++. We also build a set of sample plugins, some of which use those support libs, so they need a C++ version specified.
So is there a way in cmake for us not to force the C++ version but merely set a minimum? I'm working on a new set of C++ bindings which will require C++20, but the current support libs should work with >= 14.

[garyo]

@jfpanisset any comments on this?

[jfpanisset]

I don't know enough about the intricacies of how a plugin / shared library compiled for one C++ standard interacts with a host app compiled for a different C++ standard, and especially if they are linked against different versions of the C++ runtime. But if the API itself is just C, then this should not apply, and it is up to commercial plugin vendors / OFX projects to decide how granular they want to be in host platform support if they release a C++ based plugin.

https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/

shows how you can use:

target_compile_features(foo PUBLIC cxx_std_14)

to set the required (minimum) C++ level for a specific component of the project as opposed to setting CMAKE_CXX_STANDARD globally, perhaps that could be used here?

[garyo]

Thanks -- this is useful info. The OpenFX API is indeed "pure C". The examples are shared libs, and only expose pure C symbols, so should be buildable with any C++ standard newer than what they use (which I think is 14). The host and plugin support libs are trickier; they'll get linked into the host or plugin respectively, so need to use whatever their consumer is built with—hence the conan recipe, which ought to let the consumer specify (clearly we're not doing that here yet). We should probably switch to target_compile_features as you specify above.