CMake Module Libraries

The KDE Extra CMake Modules (docs in CMake-style) are a collection of CMake code that do three things: add useful features to CMake, provide Find modules for dependencies for KDE code, and provide tooling for KDE code. There is slow osmosis between KDE ECM and the official CMake modules shipped with each CMake release.

Some days of the week I work on the ARPA2 project, which is a software stack devoted to security and privacy handling. There’s a bunch of TLS wrangling, and Kerberos hounding (not done by me) and LDAP bit-banging. There’s a whole stack of software, starting with an allocation-free DER-handling library, going up to a TLS handling daemon with desktop UI intended to allow you to quickly and efficiently select privacy settings and online identities (e.g. X509 certificate identities). Most of the software stack now uses CMake, and most of it uses roughly the same modules. So I’ve been thinking of setting up another “Extra CMake Modules”, but this time for the ARPA2 project.

Much like KDE ECM, there are two things I would want to get out of a CMake module collection:

  • Curated Find modules. Much of the ARPA2 stack works with Berkeley DB, OpenLDAP, GPerf, GnuTLS, Kerberos .. and there seems to be a huge selection of crappy CMake modules for finding those dependencies, and not much that lives up to the quality and consistency standards of KDE ECM. I’ve started collecting these modules, or writing my own, and will try to live up to those same standards.
    • Useful features like version-extraction from git, consistent packaging and config-file generation (and pkg-config files, too). These features spill over into tooling easily: based on consistent source structures across the software stack, it’s possible to do automatic packaging and uninstalls as well. This reduces the complexity of the CMakeLists in each sub-project / software product from ARPA2.

So my goals are pretty clear, and KDE ECM serves as a big inspiration, but I’m left with an existential question: why aren’t there more of this kind of curated library? Especially curated Find modules are really valuable so that CMake-based projects can easily and consistently find components from outside the CMake ecosystem. I can’t possibly be the only one who needs to find Berkeley DB on both Linux and FreeBSD. I can understand core CMake not shipping Find modules for everything. I can understand Berkeley DB itself not shipping CMake files so that find_package() can use config mode. What surprises me thoush is that no one has sat down and said “here’s the bestest, most portable, shiniest FindBDB.cmake you can get, and everyone should be using FindBDB from the DatabaseCMakeModules package (which, incidentally, also comes with Find modules for a dozen other databases and …)”

In a way, I’m wondering where the “CMake extragear” is, something close to CMake, but not part of the official distribution.

So, with that much ado, here’s a link to the ARPA2 CMake Modules github repository; it’s in an early stage of development and still collecting modules from the ARPA2 stack, but I do hope to reach a point where find_package(ARPA2CM) becomes as but-of-course as find_package(ECM).

This entry was posted in ARPA2. Bookmark the permalink.

3 Responses to CMake Module Libraries

  1. christoph says:

    > I’m wondering where the “CMake extragear” is […]

    Isn’t ECM exactly this?

    • adridg says:

      It might be! But it isn’t really advertised as such — much like my little blurb for ARPA2CM, the KDE ECM seem to be geared towards a single software stack, a single workflow. I mean, I’d be thrilled to drop all the Find modules I have into ECM, including stuff like finding unreleased GNUTLS variants 🙂

  2. Gruenich says:

    Find modules are only the second best option. Try to reach the library authors and convince them to support either pkg-config or CMake configure files. The number of such libraries is growing.