Porting from Qt 5 to Qt 6 using Qt5Compat library

Porting from Qt 5 to Qt 6 has been intentionally kept easy. There has been a conscious effort throughout the development of Qt 6 to maintain as much source compatibility with Qt 5 as possible. Still, some effort is involved in porting. This short post summarizes some of the steps required when porting to Qt 6.

In Qt 5 some of the classes already had existing replacements, and some classes got successors during the Qt 6 development phase. Therefore it might make sense to be able to compile your code with both the old and new Qt version. This can ensure that the amount of work where your code does not compile with either version is minimized, allowing your application or library to  continue to work with Qt 5 and Qt 6. Another advantage could be that existing unit tests continue to work for most of the duration of porting, and regressions resulting from porting your code are easily distinguished from bugs introduced in Qt 6.

Types

The table below lists the classes that have been removed in Qt 6, but kept in Qt5Compat for ease of porting. It also contains the classes that shall be used in new code in Qt6 instead.

Qt 5 Class  Qt 6 Replacement
QLinkedList
std::list*
QRegExp QRegularExpression
QStringRef QStringView
QXmlSimpleReader QXmlStreamReader
QTextCodec QStringConverter
QTextEncoder QStringEncoder
QTextDecoder QStringDecoder

* If you do not need the reference stability of a linked list, you can consider using QList as well.

Adapting the build system

If you want to continue to use the above mentioned Qt 5 classes, first you need to adapt your build system to link against the new Qt5Compat module. For the qmake build system add the following line to your .pro file:

QT += core5compat

In case you already ported your application or library to the cmake build system, add the following to your CMakeList.txt:

PUBLIC_LIBRARIESQt::Core5Compat

Fixing up includes

In addition to the obviously required build system changes, you may need to fix up your includes of the former mentioned classes. Your actual code might look like this:

#include <QtCore/QRegExp>

That needs to be updated for the new Qt5Compat module:

#include <QtCore5Compat/QRegExp>

Or using the much more simple and portable version:

#include <QRegExp>

Looking forward

With Qt 6 on the horizon, you may already consider testing the new Qt 6 beta version. This will also allow early testing if your code is affected by the few Qt Core class changes mentioned above. For any issues you may find, please submit a detailed bug report to bugreports.qt.io. When filing a bug report, remember to mention which Qt version you found the issue with, and check for duplicates and known issues. You are also welcome to join the discussions in the Qt Project mailing lists and developer forums.


Blog Topics:

Comments

Benoît Gradit
1 point
53 months ago

It seems PUBLIC_LIBRARIES is not cmake standard, do you have plan on simplifying cmake files ? Creating some big project with cmake or qmake may become hell, specially with QML if you want to create custom modules, there will be improvement on thoses point in Qt 6 ? Additionnally is Qt finally providing official documentation on how we are supposed to do things ? Specially creating multiplatform application is a mess (more if you want also to support iOS and Android), and the Qt documentation on those point is ridiculously light on that.

B
Be
1 point
53 months ago

Upstream CMake is extraordinarily lacking on documentation and features for macOS packaging. Qt should provide a working example, but there's more work to do upstream. Tasks that are required for every macOS application require ugly hacks to get cpack to work. For Qt5 there is a bit of Qt specific stuff for cmake that is necessary, but the bigger challenge for me was the horrible cmake documentation. It took me over a week of scouring StackOverflow, random blogs, and wiki pages to get macOS packaging and code signing to work with CMake, which I chronicled on the CMake forum here:

https://discourse.cmake.org/t/lost-with-getting-cpack-to-make-a-macos-bundle/2102

This is the current code for reference:

https://github.com/mixxxdj/mixxx/blob/main/CMakeLists.txt#L2592

https://github.com/mixxxdj/mixxx/blob/main/cmake/modules/BundleInstall.cmake.in

https://github.com/mixxxdj/mixxx/blob/main/.github/workflows/build.yml#L129

https://github.com/mixxxdj/mixxx/blob/main/.github/workflows/build.yml#L249

Kai Köhne
0 points
53 months ago

PUBLIC_LIBRARIES is indeed Qt internal API. Instead, you can just link to Core5Compat like to all other Qt modules, e.g.

find_package(Qt6 COMPONENTS Core5Compat REQUIRED)
target_link_libraries(mytarget Qt6::Core5Compat)

On the topic of CMake API: We're not feeling quite confident enough to make some of the new CMake API public in Qt 6, but we'll gradually expand the documented API in Qt 6.1, or Qt 6.2. And we definitely plan to expand the overall CMake documentation, too (though we IMO already improved it quite a bit for 6.0).

Benoît Gradit
1 point
53 months ago

Just to add more though on that: I thinks what is missing in the Qt cmake documentation and would be great is to have a complete example of a Qt application repository which:

  • contains an application

  • which link to a library

  • which also depends on a custom QML module

  • can be build accross all major Qt platforms (Windows, MacOS, Linux, iOS and Android)

  • cover also deployement and installer (this is a big deal)

As those points are really poorly documented, as far as I know, both from cmake point and Qt point. There is a lot of documentation, but which only covers those point separately or too simply, which are in practice really far from real life applications.It could be great to have some really end-to-end sample on github, not just as a Qt sample (because Qt sample are actually build with a tons of specialized internal Qt code), but really pure sample, based on what customers should do.If you ask me, having those kind of template repository would be a real plus to the documentation and samples.

Kai Köhne
0 points
53 months ago

I like this suggestion! Have created https://bugreports.qt.io/browse/QTBUG-88968 to track it.

Benoît Gradit
0 points
53 months ago

Great news thanks!

Stephen Kelly
0 points
53 months ago

I agree that the blog should recommend users use target_link_libraries(mytarget <PRIVATE|PUBLIC|INTERFACE> Qt6::Core5Compat)

Users should use normal/modern cmake.

I was going to point out the QLinkedList issue, but I see that has already been fixed since publication :).

B
Be
-1 points
53 months ago

Is there a list of deprecated features which have been removed in Qt 6?