For software that uses CMake as (meta) buildsystem, and then gets packaged by distro's -- at least on FreeBSD -- there's something weird going on: the meta-buildsystem knows exactly what files are generated and where they get installed, but then knowledge about those files gets re-created outside of the meta-buildsystem in the ports tree, and that re-created information is used to do the actual packaging. To me, it feels like a duplication of effort, since CPack can be used to (re)use the information straight from the meta-buildsystem.

Back in february I blogged about starting on a CPack generator for FreeBSD packages.

Since then, with some comments and hints from Baptiste Daroussin (FreeBSD pkg(8) maintainer) on the FreeBSD side, and a really slick and constructive review process on Kitware's gitlab, mostly by Brad King, the FreeBSD generator is being upstreamed, and it may be in CMake 3.10, as near as I can tell. There is still some wrestling to be done because there are multiple sources of libpkg.

This isn't directly intended to break into the FreeBSD ports system -- if only because there's various staging and QA steps in a ports build that CMake just doesn't know about. But it does produce packages that can be directly installed. That's a big help for stuff not-yet-in-ports but which might be distributed and tested already. That, in turn, is something I need for some of my other (non-KDE) projects which are inching towards release and could be subsequently packaged but need testing now.

Anyway, big thanks to the constructive reviewers, and y'all can probably look forward to new package generators in CMake 3.10.

One of the new things CMake is picking up -- entirely independently -- in 3.9 is a new parameter to the project() command. You can check out CMake 3.9-RC2 now. The project() command now has an optional parameter DESCRIPTION, where you can put the human-readable project description. The FreeBSD package generator will use that description if it is given (although the Debian project description takes precedence, and there's a CPACK_FREEBSD_PACKAGE_DESCRIPTION if you need to set a FreeBSD-specific description which takes precedence over all).

This new parameter is an opportunity for other CPack generators, too: there's a Deb and RPM generator, and it struck me while writing the FreeBSD package generator that there's quite a bit of packaging information that is invariant under the actual package format: homepage of the upstream project, for instance; possibly the package description; the software license the upstream software is published under. The different Free Software distro package generators don't share that information (much -- the FreeBSD package generator falls back to Debian and RPM settings if the FreeBSD-specific settings are not given).

So I think there's a longer-term project that could be undertaken: massaging software meta-data in CMake and sharing that between package generators. That doesn't just make sense for the Free Software OS generators: Wix and NSIS could (re)use the same information, although I don't know offhand if there's license information fields in those packages (the Wix and NSIS stuff I've done is for propritary software that comes with a separate EULA, and doesn't use CMake anyway). And while we're at it, that makes project metadata more accessible: suppose you could end up with something like this:

project(konsole
  DESCRIPTION "Terminal emulator using KDE Frameworks 5, which integrates fully with the Plasma5 desktop."
  LICENSE spdx:gplv3+
  WWW https://konsole.kde.org/
)

Right now you can find those bits of metadata (usually) in the README and the LICENSE file, possibly in the appinfo file, but I think it would be (even more) useful to have that information available in the (meta) buildsystem. And I think that anything that nudges developers towards better metadata maintainence and use of standard-ish notations is a good thing.