This seems to be much easier with Apple's metal-cpp library: https://developer.apple.com/metal/cpp/

This requires C++17, which appears to mean we have to upgrade libxml++ to its v4 API (2.6 uses auto_ptr which was removed in C++17 [though GCC seems to allow it, but clang not]) which requires a newer glibmm, which pulls in cairomm, sigc++ updates.

libxml++ v4 is API breaking, most notably Node::add_child is gone and now must be Element::add_child_element.

The question is whether we can use C++17 for macOS in v2.17.x without breaking everything else. Or use C++17 for everything? After 30/6/2024 Centos 7 Is EOL (that's keeping us on C++11) but it seems unlikely that everything else would be happy to go to libxml++-4/C++17.

• Fix libdcp not to call add_child (no-add-child)
• Fix DoM master to not call add_child (no-add-child)
• Update osx-environment and build DoM with c++17 and the no-add-child branches on macOS - combined branch of DoM is c++17, osx-environment branch is also c++17
• See if it still builds on everything else - I'm guessing not because libxml++-4.0 does not seem to be included with Debian, so we'd have to build half the world.
• If so closely eyeball the libdcp/DoM changes, commit, profit.

macOS dep updates are:

• sigc++ -> 3.6.0
• glibmm -> 2.68.2
• libxml++ -> 4.0.3
• cairomm -> 1.18.0

Ubuntu 18.04 seems tricky because something (I think) needs meson 1.2.0 but that needs Python >= 3.7.0.

Bottom line though is it seems possible, but will need some ifdeffing. The changes are on

• libcxml - c++17 branch (libxml++ 4.0)
• libdcp - c++17 branch (libxml++ 4.0)
• dcpomatic - c++17 branch (libxml++ 4.0, Cairo / Pango namespace changes)
• osx-environment - c++17 branch

Once C++17 branches are merged I guess this can be bumped from 2.18.0.