Porting from Qt 5 to Qt 6 using Qt5Compat library
November 25, 2020 by Karsten Heimrich | Comments
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
Subscribe to our newsletter
Subscribe Newsletter
Try Qt 6.8 Now!
Download the latest release here: www.qt.io/download.
Qt 6.8 release focuses on technology trends like spatial computing & XR, complex data visualization in 2D & 3D, and ARM-based development for desktop.
We're Hiring
Check out all our open positions here and follow us on Instagram to see what it's like to be #QtPeople.
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.
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
PUBLIC_LIBRARIES is indeed Qt internal API. Instead, you can just link to Core5Compat like to all other Qt modules, e.g.
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).
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.
I like this suggestion! Have created https://bugreports.qt.io/browse/QTBUG-88968 to track it.
Great news thanks!
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 :).
Is there a list of deprecated features which have been removed in Qt 6?