Qt-Migration von Qt 5 auf Qt 6

Was umfasst eine Qt-Migration bei bitshift?

Wir übernehmen den Weg von Qt 5 nach Qt 6 vollständig – oder genau die Stufe, an der es gerade klemmt.

• Aufwandsabschätzung vorab über einen zeitlich begrenzten Spike, mit konkreten Posten statt einer Pauschale
• Modernisierung auf Qt 5.15 mit aufgeräumten Deprecation-Warnungen – die wirksamste und am häufigsten übersprungene Stufe
• Umstellung des Builds von qmake auf CMake, als eigener, isoliert verifizierbarer Schritt
• Wechsel auf Qt 6 mit Qt5Compat als Brücke, anschließend Ablösung der Übergangsabhängigkeiten
• Ersetzen entfallener Bausteine – Qt Quick Controls 1, für Qt 6 neu geschriebene Module wie Qt Multimedia, QRegExp und QTextCodec
• Grafikstack und Plattform-Plugin auf der Zielhardware verifizieren, nicht nur im Desktop-Build
• Absicherung durch automatisierte Tests, auf Wunsch über unser Embedded Testrack auf realer Hardware

Warum steht die Migration überhaupt an?

Der Druck kommt selten aus dem Support-Kalender, sondern fast immer aus der Hardware.

Qt 5.15 war die letzte Qt-5-Version mit Langzeit-Support; der Open-Source-Support ist ausgelaufen, die kommerziellen Konditionen ändern sich über die Jahre – den aktuellen Stand klären Sie am besten direkt mit The Qt Company. Der eigentliche Auslöser ist aber meist ein neuer SoC: Er bringt eine neuere Yocto-Version mit, die einen neueren Compiler und neuere Systembibliotheken mitbringt, und irgendwann baut ein altes Qt 5 darin nicht mehr sauber. Wer bis dahin wartet, migriert unter Zeitdruck parallel zu einem Board-Bring-up. Das ist die teuerste denkbare Reihenfolge.

Wie läuft die Migration ab?

In fünf Stufen, von denen jede für sich lauffähig bleibt – der häufigste Fehler ist, Qt-Version, Build-System und Compiler gleichzeitig zu wechseln.

Stufe	Arbeit	Ergebnis
1	Auf Qt 5.15 gehen, Deprecation-Warnungen auflösen	Laufende Anwendung ohne veraltete Aufrufe
2	Build auf CMake umstellen – noch unter Qt 5	Build-Wechsel isoliert verifiziert
3	Wechsel auf Qt 6 mit Qt5Compat als Brücke	Erste lauffähige Qt-6-Version
4	Qt5Compat ablösen, QML auf versionslose Importe	Keine Übergangsabhängigkeiten mehr
5	Grafikstack und Plattform-Plugin auf dem Ziel prüfen	Bestätigtes Verhalten auf dem realen Gerät

Weil nach jeder Stufe ein funktionierender Stand existiert, hat ein auftretender Fehler jeweils nur eine plausible Ursache. Die technischen Hintergründe dazu haben wir ausführlich in unserem Artikel Von Qt 5 auf Qt 6 migrieren beschrieben.

Was ist auf Embedded-Zielen zusätzlich zu tun?

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

Qt Quick rendert in Qt 6 nicht mehr direkt gegen OpenGL, sondern über die RHI – eine Abstraktion über die Grafik-API der jeweiligen Plattform. Auf dem Desktop merkt man davon wenig. Auf einem Board mit EGLFS, einem herstellerspezifischen EGL und einem GPU-Treiber, dessen Eigenheiten das Team über Jahre gelernt hat, kostet genau das Zeit. Dazu kommt das BSP: Die Qt-6-Schicht muss zur Yocto-Version des Boards passen, und ein Sprung über mehrere Yocto-Releases zieht Kernel, Toolchain und Systembibliotheken mit. Wie wir solche Layer bauen und pflegen, steht unter Yocto BSP & Distributionen.

Der Unterschied zu einer reinen Qt-Werkstatt: Weil wir die Embedded-Linux-Plattform darunter ohnehin beherrschen, ist die BSP-Frage für uns Teil des Auftrags und keine Schnittstelle, an der die Zuständigkeit endet.

Was kostet eine Qt-Migration?

Eine belastbare Zahl entsteht erst nach dem Spike – vorher wäre sie geraten.

Vier Fragen bestimmen den Aufwand: Wie viel QML gibt es, und hängt es an Qt Quick Controls 1? Nutzt die Anwendung Module, die für Qt 6 neu geschrieben wurden – Qt Multimedia vor allem? Wie eigenwillig ist der Grafikstack der Zielhardware? Und existieren automatisierte Tests, die eine Regression überhaupt sichtbar machen würden? Wir klären das in einem überschaubar bemessenen ersten Schritt und legen Ihnen danach eine Abschätzung mit benannten Posten vor. Sie entscheiden auf dieser Grundlage, ob und in welchem Umfang es weitergeht.

Warum bitshift dynamics für Ihre Qt-Migration?

Weil bei uns Qt-Kenntnis und Embedded-Tiefe aus demselben Team kommen.

Wir arbeiten seit 2005 an hardwarenaher Software und decken C++, Qt/QML, Embedded Linux und Yocto gemeinsam ab – deshalb bleibt eine Migration bei uns nicht am Grafikstack oder am BSP hängen. Wir sitzen in Lörrach im Dreiländereck, arbeiten remote-first und bei Bedarf vor Ort im DACH-Raum, auf Deutsch und auf Englisch. Wenn Ihr Team die Migration selbst durchführen möchte, geht das ebenso: Dann begleiten wir sie als Sparringspartner oder über eine passende Schulung.