Guidelins for one codebase that builds with Qt5 and Qt6?

[Halla Rempt]

On dinsdag 6 augustus 2024 12:46:58 CEST Volker Krause wrote:
> On Montag, 5. August 2024 16:15:19 CEST Halla Rempt wrote:
> > I seem to remember that there were KDE apps that could be built with
> > both Qt6/Kf6 and Qt5/Kf5. Did I remember that right? And if so, is there
> > some howto or documentation for that?
> 
> Right, that was the approach taken by many Frameworks, Plasma and Gear 
> modules.
> 
> I'm not familiar enough with Krita's code to judge whether any of that is 
> applicable, but here's roughly what we did there:
> 
> (1) Require Qt 5.15 and a recent KF5, and port away from deprecated API.
> 
> In many cases that already was the bulk of the code changes, and it's also 
> what supported the direct Kate port Christoph mentioned for example.

Good, that's sorted, I just finished that part. Except for QLinkedList, because QList isn't a working replacement for that.

> 
> This started in mid 2019.
> 
> (2) Using ECM will automatically give you a switch for the major Qt version 
> (https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/modules/
> QtVersionOption.cmake, included by all modules that do anything Qt-related).

I didn't know about that, so I copied kdenlive's manual code, but I'll use it.


> Replacing "Qt5" with "Qt${QT_MAJOR_VERSION}" and "KF5" with "KF$
> {QT_MAJOR_VERSION}" tended to be the bulk of the necessary build system 
> changes.

I'l do that.

> (3) A large chunk of the remaining changes for making things build with Qt 6 
> can still be done without ifdefs (missing includes etc), but you wont be able 
> to avoid them entirely. Similar for conditional code in the build system. 
> Without (1) this can get significantly more painful though.
> 
> (4) As soon as the Qt 6 version is ready, drop Qt 5 support by removing 
> conditional code and replacing ${QT_MAJOR_VERSION} with "6" in the build 
> system. We got to this point in early 2024.

That's going to take quite a bit of time for us, since we really needed a lot of patches to Qt itself to make things like HDR work.

> 
> This worked ok for C++ code I think, the Qt 5 code remained releasable for the 
> entire time. A few regressions got in during the process, but also a few 
> version-independent issues got found by stricter compile-time checks on e.g. 
> implicit conversions in Qt 6.
> 
> Supporting two major versions at the same time tends to get increasingly 
> painful over time though, so I can only recommend to see this as "scaffolding" 
> for a transient phase that shouldn't be longer than absolutely necessary. 
> Apart from a few special exceptions (e.g. style plugins) we also didn't 
> release anything officially supporting both versions.

The most important part of our releases are our binaries, and those will be Qt5 until we can be sure everything works. That's going to be pain!

> 
> What didn't work was anything involving larger amounts of QML code. There were 
> a few attempts to support both versions as well with various levels of dirty 
> hacks, but nothing that ended up being widely used.
> 

That is a very useful warning. We've just started using QML more in places like the text tool's font properties.

Thanks for the tips!

Halla