With a number of recent changes in KDE Frameworks it’s now possible to build the first module (KCoreAddons) against Qt6 out of the box. This isn’t officially supported or ready for consumption yet of course, but meant as a development tool and is an important step towards the transition to KF6.

Extra CMake Modules (ECM)

The biggest change towards Qt6 support happened in ECM, by no longer forcing Qt5 on its Qt features and by adjusting default installation paths accordingly. The key for this is the new QtVersionOption module, which follows the Qt requirement explicitly set by a project, or if there is none, follows the user choice. The output is a single CMake variable, QT_MAJOR_VERSION, which then can be used in all subsequent places depending on a specific Qt version.

This is now in use inside ECM for all modules that provide Qt specific functionality. This doesn’t mean all that already works with Qt6 of course, in fact a lot is still just empty scaffolding. It does however mean ECM no longer pulls in Qt5 unconditionally, even when used in a Qt6 context.

To further support porting, the standard installation directories defined by KDEInstallDirs now also provide version-less aliases.

It’s worth noting though that any Qt6 functionality provided by ECM 5.x isn’t coming with the same source and behavior stability guarantee as everything else, but is subject to change until the 6.0 release.

KCoreAddons

With ECM no longer insisting on Qt5, making the first framework build against Qt6 was actually fairly straightforward then, thanks to the extensive preparation work over the past two years. Even its unit tests mostly run and pass already.

While the buildsystem changes (which essential replace mentions of 5 with ${QT_MAJOR_VERSION}) are rather ugly, it’s nevertheless the least painful option for the transition period:

  • Version-less targets make for clean code but leak into CMake config files and are thus forced on all consumers as well.
  • Branching is increasingly more expensive the earlier we have to start with it, we are therefore trying to do that as late (and as short) as possible.

To try KCoreAddons with Qt6 yourself, there’s two additional CMake arguments needed for now:

  • -DBUILD_WITH_QT6=ON to actually use Qt6.
  • -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT to disable all deprecated Qt5 code that wont be available in KF6.

As noted for ECM, Qt6 is not officially supported prior to the 6.0 release, this option is only available to support the ongoing work towards KF6.

Outlook

Similar changes are being worked on for other frameworks where adding Qt6 support in the still primarily Qt5-based codebase is feasible without too much hassle. The goal is to allow testing of as many parts as possible against Qt6 (up to maybe even pilot ports of individual applications), so we can identify runtime issues and remaining gaps in Qt6.

Doing this in the Qt5 code allows us to defer branching for Qt6 a bit longer, which is a good thing as maintaining an increasingly divergent branch gets disproportionally more expensive over time and risks important fixes getting lost. And as long as we can avoid that, KF5 keeps benefiting from all the improvements made as part of the KF6 work.

There are limits to this approach of course, once we hit those branching is the likely next step.

Contribute

The KF6 workboard is the central place for coordinating the work related to Frameworks 6. There’s also a weekly one hour call on Tuesday 17:00 CET. It’s also worth joining the kde-frameworks-devel mailing list and the #kde-devel channel on Matrix.