One of the more broadly-useful things to come out of KDE Frameworks efforts is, in my opinion, the KDE Extra CMake Modules (ECM). Since KDE software nearly-universally uses CMake as (meta-)build system, a lot of common functionality is distilled into the ECM. It makes building KDE software more consistent and generally easier. Inspired by KDE ECM, let me present ARPA2CM, a conceptually-similar set of CMake modules for a different software stack.

Software Stack

The ARPA2CM modules are – no suprise here – CMake modules for the ARPA2 stack. ARPA2 is a loose collection of projects for security-related things. A lot of it is based on Kerberos, there’s a bunch of TLS work, and as an over-arching idea there’s “identity management” where it should be far easier to switch identities when accessing the internet – authentication should not belong to walled gardens.

There’s some philosophy at internetwide.org.

The irony of using plain http there is not lost on me.

My part of the stack is largely the CMake bits and some LDAP-wrangling. Early on we noticed that there would be a dozen or more somewhat-independent repositories, and they would all have common needs: finding Kerberos, finding TLS libraries, dealing with logging, .. exactly the category of things that KDE’s ECM does.

However, the dependencies (find-modules) are ones that few KDE applications need, the major language is C rather than C++, with no Qt in sight, so ECM itself is a bad fit for the CMake-level tooling. We developed our own collection, although it’s all BSD-2-Clause licensed so that it could be incorporated upstream (in CMake) or cross-stream (in KDE ECM) if needed.

There’s also some bits that were copied straight out of ECM into ARPA2CM, like FindGperf and its supporting modules.

The target platform(s) for the software stack are primarily Linux (Debian stable and newer, I think) and secondarily Windows; this means that the chosen CMake-required-version, for instance, is a bit older than the most-recent one.

Coding Style

Since most of the “code” is CMake code, the important formatting tool is not clang-format. I chose gersemi as the CMake-formatter; Harald Sitter once spent a long time looking for such formatting tools and pointed my at this one. It is somewhat simplistic, but it does do reasonable formatting and is somewhat opinionated about it, so there’s not a ton to tweak.

Once I started using gersemi in earnest, I found some bugs, reported them, and they were fixed. I like tools like that.

I have not gone over the code repeatedly to make it the most beautiful CMake code possible. That’s for some time when there’s other slack in the schedule. It’s reasonably consistent all over, but the module- documentation, for instance, could be made .rst for consistency with ECM and CMake documentation. Merge requests over on GitLab are welcome.

Using ARPA2CM

Since ARPA2CM is not packaged (as far as I know; heck, this is the first release announcement so why would anyone have done that already), getting it might currently be tricky. If you’re the vendoring type, plopping the find-modules/ and modules/ directories into another project might be enough.

If ARPA2CM is installed, then there is an example CMakeLists.txt which looks for it. This is an awful lot like you might use KDE ECM in your project.

Future

I expect to do some minor maintainence on the ARPA2CM collection, and as the rest of the stack matures, it may grow some new modules for shared dependencies or use. FreeDiameter is the most recent addition to the modules (just before the 1.0 release of ARPA2CM). As long as it does its job for the dozen projects under the ARPA2 umbrella, it’s “good enough”.

Now I can move on to working on LDAP-wrangling software that uses these CMake modules.

Work on ARPA2CM was sponsored by Stichting NLNet and by the NGI0 project “xover”, at various points in the now 4-year history of ARPA2CM.