TL;DR
Starting with the CMake 3.27 release series, snap packages will be provided only for the amd64 and arm64 architectures. The existing snap packages for CMake 3.26 and earlier for the armhf, i386, ppc64el and s390x architectures will continue to remain available, but will not be updated further beyond 3.26 the release series.
Background
There are two primary drivers for this change:
- Non-existent support for Qt 6.
- Building for the architectures being dropped has proven to be problematic.
Lack of support for Qt 6
A number of times over the past couple of years, I’ve pointed out the difficulty with snapping an application that uses Qt (which CMake does for its GUI tool). The most recent discussion thread can be found here.
I’ve observed increasing problems with the existing approach used to snap CMake 3.26 and earlier. Integration with the desktop is getting flakey, especially around things like theme integration. In contrast, the official CMake releases from Kitware seem to show no such problems. The Kitware packages are built with a static Qt, managed as part of the Kitware build images so that it doesn’t have to be built along with every package.
So far, the CMake snaps have been built with Qt 5, but that is now fully two LTS releases behind the latest Qt LTS release (6.5). Qt 5.15 LTS is about to hit end-of-life (extended support requires a license). Furthermore, improved desktop integration is one of the benefits of Qt 6. I am not willing to risk the CMake snap being a blocker to using Qt 6 in the official CMake packages from Kitware, should that become desirable. Therefore, the CMake snap needs to have a way forward that doesn’t rely on sticking with Qt 5.
Building a snap that uses Qt (even just Qt 5) is also problematic. The key issues can be summarised as:
- The recommended way to support Qt apps is to use the kde-neon extension. But this extension supports precisely just one architecture:
amd64. Furthermore, it is focused on Qt 5. - For any snap using Qt that needs to support multiple architectures, the only sane option appears to be to fall back to the old Qt helpers. But they were deprecated long ago, are also stuck on Qt 5, and don’t appear to have had any commits in a year and a half. Basically, it’s a dead-end.
The CMake snap has been relying on the deprecated Qt helpers for too long. But with no viable alternative in sight, something has to change.
Remote builds
The CMake snaps have been built using the snapcraft remote-build service so far. This was the only viable choice for the broad set of architectures being provided. While this service generally works, it has been observed to be unreliable and slow. At times, it has taken over a day to get the complete set of snaps built for all architectures. The arm64 and armhf builds in particular tend to be slow, and the demand for arm-based build agents is clearly higher. Queue times can be long, and occasionally the arm builds simply die for no apparent reason.
Remote builds also don’t integrate particularly well with CI systems. The snap build service that connects a GitHub repo with builders doesn’t have any concept of git branches. It always pulls from the default branch, even when triggered by pushes to other branches. That’s a non-starter for a snap like CMake’s where there are tracks for each feature release, and each track has its own branch in the GitHub repo. See this discussion thread for further details. Again, there has been essentially no action on this for a long time, and I’ve given up any hope it will be addressed on any sort of useful time frame. That build service also appears to be backed by the same thing as the snapcraft remote-build anyway, so it would likely suffer from the same problem of slow builds and build agent availability/reliability.
Changes for CMake 3.27 onward
Given the above, starting with the CMake 3.27 release series, the CMake snaps will be built very differently. The snaps will no longer build CMake from sources, they will just repackage up the binaries from the official Kitware release packages. Essentially, the snaps will become simple wrappers around the official Kitware releases. This will have the added advantage of fewer differences with the official releases, which has been a problem in the past (early snap versions didn’t work if you were using the intel graphics drivers, for example).
Currently, there are only official Kitware release packages for amd64 and arm64. In theory, armhf could be added if someone is willing to do the work to add that to the CMake gitlab CI, and if that happens, it would be easy to then provide armhf snaps again. If anyone would like to explore that, please get in contact via the CMake forums. UPDATE: I’ve spent time exploring an armhf build and discussed it with the chief CMake maintainer. We have concluded that supporting an armhf build would be problematic, and we do not intend to pursue that avenue any further.
The number of active users of the ppc64el and s390x architectures is tiny (about 10 each). There are also very few active i386 users (about 50). Therefore, the impact of dropping those architectures is small. Affected users will need to find other avenues if they need updated CMake releases for 3.27 and beyond.
The armhf architecture does have a modest number of active users (a bit under 700). I’d like to support it if there’s a way to easily do so, but that has to be through the path of using official Kitware release packages to be viable. UPDATE: As mentioned above, I no longer believe this is possible.