The KDE-FreeBSD team also maintains the CMake packages on FreeBSD -- mostly because KDE was the first big consumer of CMake. The meta-buildsystem is now used by hundreds of packages on FreeBSD. We recently switched the backend -- the build system that is generated by CMake -- from make to ninja, which gives us small-but-measurable build-time improvements.

Now we're working on the CMake 3.9 update, which was released a two weeks ago.

Re-building hundreds of packages that use CMake is always an interesting exercise, since it's the kind of big-practical test that regular testing avoids (this reminds me that really, we should be doing this in the RC phase rather than after release, to help the CMake folks find stuff before a release is finalized). The interesting bits have to do with all the ways that people find to abuse CMakeLists and do weird stuff.

Three CMake things I noticed recently:

  • Checking if stderr is a tty (for instance, to produce pretty colorized CMake output when it is) changed between CMake 3.0 and 3.1. OK, that's not a recent change, but me-asking-myself "wasn't this colorized?" was recent. Not a bug, something to work around most likely.
  • Finding UI files and automatically processing them has changed slightly. It is possible to add search paths. Quoting from the release notes,

    A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the vicinity of the file including "ui_foo.h".

    This breaks projects that #include "path/to/ui_foo.h". Previously, CMake ignored the path and looked for the UI file in the same directory as the source including it. Now, it looks for the UI file at the given path. In some packages which pull weird shenanigans with include flags and UI file locations, this breaks. Bug filed, though I have come to the conclusion that "Don't Do That Then" is the right response and we'll have to patch the packages that do this.

  • A change in the way auto-MOC works has revealed a bug of sorts in either auto-RCC or the ninja backend generator; this breaks Digikam for us. The same problem can be triggered in earlier CMake versions by turning on auto-RCC. Since we end up with different build results between make and ninja (make build succeeds, ninja doesn't), I've filed a bug for this too. We're still looking at what ought to be done about it, though. In the meantime there's a simple fix for Digikam, though I'm not sure what other packages may be affected.

Trawling through packages that use or support (much) older CMake versions make me appreciate how far CMake has come since, say, 2.7. Whenever I find a page and a half of convoluted code to figure out which compiler flags support a given C++ standard, I'm glad of newer approaches like set(CMAKE_CXX_STANDARD 17) and be done with it. But I can understand projects not chasing CMake releases all that closely; there is a maintainence cost after all.

Anyway, thanks to the CMake folks for being very responsive to bug reports, and for FreeBSD users, expect CMake 3.9 soon-ish -- it depends a little on how it intersects with the other updates we are trying to do, where Plasma5 is a big thing happening right now.