Guidelins for one codebase that builds with Qt5 and Qt6?

[Ben Cooksley]

On Wed, Aug 7, 2024 at 8:17 PM Milian Wolff <mail at milianw.de> wrote:

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

For the record, this isn't a Gitlab limitation - it is an intentional
decision of how our Git hooks work, and the policy around how notifications
are sent.

It is generally bad practice to have long running non-merged work like
KDevelop and Krita have done.
If you do need to do this, then it is suggested you draft the work in a
personal fork repository and then submit the relevant pieces of work in the
relevant chunks for merging.


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


Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240807/facc61db/attachment-0001.htm>