Von Qt 5 auf Qt 6 migrieren: ein Fahrplan für Embedded-Projekte

Kurz gesagt: Eine Migration von Qt 5 auf Qt 6 scheitert selten an einzelnen API-Änderungen – sie scheitert daran, dass zu viele Baustellen gleichzeitig aufgemacht werden. Wer den Wechsel in Stufen zerlegt und jede Stufe lauffähig hält, verwandelt ein Projekt mit offenem Ende in eine Reihe überschaubarer Schritte: erst auf Qt 5.15 modernisieren, dann das Build-System auf CMake heben, dann auf Qt 6 wechseln, zuletzt die Kompatibilitätsschicht ablösen. Auf Embedded-Zielen kommt eine fünfte Aufgabe dazu, die auf dem Desktop unsichtbar bleibt: der neu aufgebaute Grafik-Stack.

Warum der Wechsel irgendwann ansteht

Qt 6.0 erschien Ende 2020, und die Qt-6-Reihe hat mit 6.2, 6.5 und 6.8 mehrere LTS-Stände hervorgebracht. Qt 5.15 war die letzte Qt-5-Version mit Langzeitpflege; ihr Open-Source-Support ist ausgelaufen, und kommerzielle Bedingungen ändern sich über die Jahre – den aktuellen Stand klären Sie am besten direkt mit The Qt Company.

Der eigentliche Druck entsteht aber selten aus dem Support-Kalender, sondern aus der Hardware. Ein neues SoC bringt ein neueres Yocto-Release mit, das einen neueren Compiler und neuere Systembibliotheken mitbringt – und irgendwann lässt sich ein altes Qt 5 darin nicht mehr sauber bauen. Wer die Migration bis zu diesem Moment aufschiebt, muss sie unter Zeitdruck zusammen mit einem Board-Bring-up erledigen. Das ist die teuerste aller Reihenfolgen.

Was sich tatsächlich ändert

Der Sprung von 5 auf 6 ist kein Bruch wie seinerzeit von Qt 3 auf Qt 4. Der größte Teil einer typischen Anwendung übersetzt nach überschaubaren Anpassungen. Die Arbeit konzentriert sich auf vier Bereiche.

Das Build-System. Qt 6 selbst wird mit CMake gebaut, und CMake ist der Pfad, auf den Dokumentation, Werkzeuge und Beispiele ausgerichtet sind. Anwendungen lassen sich weiterhin mit qmake übersetzen, doch jede Erweiterung – ein neues Modul, ein Qt-Quick-Compiler-Schritt, ein zusätzliches Target – führt zurück auf den unterstützten Weg.

Entfernte und verschobene APIs. Klassen wie QRegExp und QTextCodec sind nicht verschwunden, sondern in das Modul Qt5Compat gewandert. Das ist eine Brücke, kein Ziel: Sie hält die Migration in Gang, während die Ablösung – etwa QRegExp durch QRegularExpression – nach und nach passiert. Qt Quick Controls 1 wurde dagegen ersatzlos entfernt; wer noch darauf aufsetzt, hat hier den größten Einzelposten. Auch Qt Multimedia wurde für Qt 6 neu geschrieben, was für Anwendungen mit Kamera- oder Video-Pfad eine eigene Betrachtung verlangt.

Der Grafik-Stack. Qt Quick rendert in Qt 6 nicht mehr direkt gegen OpenGL, sondern über die RHI, eine Abstraktionsschicht über die Grafik-APIs der jeweiligen Plattform. Auf dem Desktop merkt man davon wenig. Auf einem Embedded-Board mit EGLFS, herstellerspezifischem EGL und einem GPU-Treiber, dessen Eigenheiten man über Jahre kennengelernt hat, ist das der Punkt, an dem eine Migration Zeit kostet.

C++-Standard und Sprachdetails. Qt 6 setzt mindestens C++17 voraus. Für Projekte, die ohnehin auf einem älteren Stand festhängen, ist das ein willkommener Anlass – wir haben die praktischen Folgen im Beitrag zu modernem C++ für Embedded-Systeme ausgeführt. Dazu kommen Detailänderungen, etwa die Vereinheitlichung von QList und QVector, die meist der Compiler für Sie findet.

Die Reihenfolge, die das Risiko klein hält

Die verbreitetste Fehlentscheidung ist der gleichzeitige Wechsel von Qt-Version, Build-System und Compiler. Schlägt dann etwas fehl, gibt es drei Verdächtige und keinen lauffähigen Zwischenstand. Die folgende Staffelung vermeidet das:

Stufe	Inhalt	Ergebnis
1	Auf Qt 5.15 heben, Deprecation-Warnungen abarbeiten	Lauffähige Anwendung ohne veraltete Aufrufe
2	Build-System auf CMake umstellen – noch unter Qt 5	Build-Wechsel isoliert verifiziert
3	Auf Qt 6 wechseln, Qt5Compat als Brücke	Erste lauffähige Qt-6-Version
4	Qt5Compat ablösen, QML auf versionslose Imports	Keine Übergangsabhängigkeiten mehr
5	Grafik-Stack und Plattform-Plugin auf der Zielhardware validieren	Bestätigtes Verhalten auf dem echten Gerät

Stufe 1 ist die wirksamste und wird am häufigsten übersprungen. Qt 5.15 kennt fast alle Deprecations, die in Qt 6 zu Fehlern werden. Mit QT_DISABLE_DEPRECATED_BEFORE lässt sich der Compiler dazu bringen, alte Aufrufe hart abzulehnen, statt sie nur zu bemängeln – die Migration wird damit zu einer Liste von Compilerfehlern, die sich abarbeiten lässt, während die Anwendung durchgehend lauffähig bleibt.

Ein konkreter Blick: vom .pro zur CMakeLists

Der Build-Wechsel wirkt größer, als er ist. Eine typische qmake-Datei:

# app.pro
QT += quick
CONFIG += c++17
SOURCES += main.cpp
RESOURCES += qml.qrc
TARGET = myapp

Dieselbe Absicht in CMake, wie Qt 6 sie erwartet:

cmake_minimum_required(VERSION 3.21)
project(myapp LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

find_package(Qt6 REQUIRED COMPONENTS Quick)
qt_standard_project_setup()

qt_add_executable(myapp main.cpp)
qt_add_qml_module(myapp
    URI MyApp
    VERSION 1.0
    QML_FILES Main.qml
)
target_link_libraries(myapp PRIVATE Qt6::Quick)

Der Zugewinn liegt nicht in der Syntax, sondern darin, dass QML-Module explizit werden. Statt einer Ressourcendatei, in der QML-Dateien lose einsortiert sind, beschreibt qt_add_qml_module ein benanntes Modul mit Version – die Grundlage dafür, dass Werkzeuge QML überhaupt vorab prüfen und übersetzen können.

Was auf Embedded-Zielen dazukommt

Auf dem Desktop endet eine Migration beim grünen Build. Auf einem Gerät fängt dort die eigentliche Prüfung an.

Das BSP muss mitspielen: Der Qt-6-Layer muss zum Yocto-Release des Boards passen, und ein Sprung über mehrere Yocto-Stände zieht Kernel, Toolchain und Systembibliotheken mit. Es ist deutlich billiger, Qt-Migration und BSP-Aktualisierung als zwei getrennte, nacheinander verifizierte Schritte zu fahren, statt beides in einem Rutsch – auch wenn das zunächst nach Mehrarbeit aussieht. Wie wir solche Layer aufbauen und pflegen, beschreiben wir unter Yocto BSP & Distributionen.

Der Grafik-Pfad braucht eine bewusste Prüfung: Läuft EGLFS mit dem herstellerspezifischen Backend? Verhält sich die Anwendung bei Bildschirmdrehung, Multi-Display oder Touch-Kalibrierung wie zuvor? Und bleibt die Startzeit im Rahmen, wenn ein anderer Rendering-Weg eingeschlagen wird? Der Hintergrund dazu steht in unserem Beitrag zu Qt im Embedded-Umfeld.

Schließlich die Verifikation. Eine Migration ändert an tausend Stellen wenig und an einigen wenigen viel – ohne automatisierte Tests auf echter Hardware bleibt die Frage offen, welche der beiden Sorten man gerade erwischt hat. Genau dafür ist unser Embedded Testrack gebaut: Jeder Build läuft auf dem realen Gerät über die realen Schnittstellen, sodass ein Regressionsfehler im Grafik- oder Eingabepfad sofort auffällt statt erst beim Kunden.

Aufwand realistisch einschätzen

Eine belastbare Schätzung entsteht nicht aus der Codezeilenzahl, sondern aus vier Fragen: Wie viel QML gibt es, und nutzt es Qt Quick Controls 1? Hängt die Anwendung an Modulen, die in Qt 6 neu geschrieben wurden – allen voran Multimedia? Wie eigen ist der Grafik-Stack der Zielhardware? Und existieren automatisierte Tests, die eine Regression überhaupt sichtbar machen?

Ein pragmatischer erster Schritt ist ein zeitlich begrenzter Vorstoß: Stufe 1 und 2 an einem Zweig durchführen, den Rest nur so weit anfassen, bis die Anwendung unter Qt 6 startet. Danach ist die Restarbeit meist gut benennbar – und die Diskussion dreht sich um konkrete Posten statt um ein Bauchgefühl. Qt-Themen dieser Art behandeln wir auch in unseren Schulungen, und die Migration selbst gehört zu unserem Angebot rund um Qt & QML.

Fazit

Der Wechsel auf Qt 6 ist kein Neuschreiben, sondern eine Kette planbarer Schritte – vorausgesetzt, sie werden nicht gleichzeitig gegangen. Modernisieren Sie zuerst unter Qt 5.15, isolieren Sie den Build-Wechsel, nutzen Sie Qt5Compat als Brücke statt als Dauerlösung, und behandeln Sie den Grafik-Stack auf dem Zielgerät als eigenständige Aufgabe. Wenn Sie eine Einschätzung zum Aufwand für Ihre Codebasis möchten oder eine begonnene Migration festhängt, sprechen Sie uns an.