CMake 3.11 is here -- it went through four rc's -- which means that preparatory work is underway in KDE FreeBSD land (and has been since -rc1). KDE, as the main early consumer of CMake, is the package maintainer on FreeBSD. That means that it falls to us to signal things that break due to CMake updates, and often to fix them as well. Generally the KDE ports (even the KDE4-era onces) are not a problem; modern-ish CMake was basically develop-tested in KDE. Sometimes updates in C++ bite us -- recent FreeBSD releases keep updating Clang, which keeps getting more picky about C++ code (and may default to newer C++ standards than expected). But generally, KDE stuff is ok.

To test a CMake update, I build about 2000 packages on my own desktop workstation. It takes about 20 hours with all the supporting libraries and other bits -- rebuilding Qt Webengine, three WebKits, five llvm's and gcc6 kinda takes its time. Then there's maybe two dozen packages that don't build, and it comes down to figuring out whether they don't build because of a change in CMake, or a change in something else, or simply because they're already broken. But it means I end up diving into all kinds of codebases, for instance:

  • dspdfviewer had a simple C++ error, because of newer Clang being picky. (already fixed)
  • SuperTux2 has a weird #define type .. which of course breaks some C++ standard libraries where type is used as a structure field name. (already fixed)
  • sqlitebrowser has a really weird copy of QtScintilla which has both an enum and a list of #defines for the same tokens .. which breaks under some inclusion sequences. (not fixed)
  • hatari assumes that SDL_INCLUDE_DIR can only have one directory. (already fixed)
  • kicad has a typical CMake 2.6 or 2.8 setup, where some newer CMake modules from 3.0 have been copied into a cmake/ directory. This eventually breaks when the internals that the 3.0 modules rely on change. Fixing this is as easy as just deleting the old, crufty CMake bits that are shipped with the software -- but it needs to be spotted before an update anyway. (already fixed)

There are not software packages I would normally involve myself with, and of these five, three have problems that are not really CMake-related.

KitWare has been great in responding to reported regressions, by the way. So those 2000 packages also serve as a testbed to spot unexpected changes in CMake's behavior. Sometimes the best thing to do is to fix it in CMake, sometimes update the other software -- or sometimes say "this has been unmaintained upstream for six years, let it go."

There are two issues left on my list which are vexing: drawpile needs an extra include with CMake 3.11 and Wesnoth can't find OpenMP anymore. There's another dozen or so packages that are failing and need some work. I need to get those sorted out one way or another before the CMake 3.11.0 update hits the FreeBSD ports tree. For the over-eager, it's already in the area51 staging tree, in branch cmake-3.11.