Guidelins for one codebase that builds with Qt5 and Qt6?

[Milian Wolff]

On Dienstag, 6. August 2024 12:58:29 MESZ Halla Rempt wrote:
> 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.

QLinkedList is available in Qt6 core5compat:
https://doc.qt.io/qt-6/qlinkedlist.html

<snip>

> > (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.

We recently ported KDevelop over to Qt6 and ran into issues with the gitlab 
configuration - branches must not contain more than a hundred patches, which 
you can easily end up with while porting larger applications.

We ran into this, as we did _not_ want to try and support Qt5 and Qt6 
simultaneously. Since you want to do that, I can only recommend you to get 
your porting patches into master incrementally, in smaller batches. Otherwise 
you will need to start gaming the system and workarounding the artificial 
gitlab patch limitations.

> 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.

Are those patches not upstreamed to Qt6?

> > 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.

I agree with Volker. Compared to the past, porting QtWidgets applications from 
Qt5 to Qt6 is trivial. I fear you krita folks will have more trouble due to 
the low level graphics work you are doing, but I hope that the bulk of the 
effort is going to be trivial. Definitely start with porting everything to the 
latest Qt 5.15 and fix deprecation warnings, then take it from there.

Good luck!
 
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240807/6eb0dcb5/attachment.sig>