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