Qt 6: Ein steiler Weg zur neuen Hauptversion

Qt blickt auf eine bewegte Geschichte vom semi-quelloffenen Cross-Plattform-Framework über die Nokia-Zeiten mit Fokus auf mobilen Endgeräten bis zur eigenständigen Qt Company.

Während sich andere Anbieter im Cross-Plattform-Bereich konsequent an den Desktop gehalten haben, höchstens nebenbei in den Mobilbereich expandierten und Embedded-Systeme links liegen ließen, nutzte die Qt Company die Gunst der Stunde: Qt 5 steht mittlerweile für eine ganze Gruppe unterschiedlicher Echtzeitbetriebssysteme zur Verfügung, die teilweise nicht auf Linux basieren.

Damit gehen naturgemäß andere Bedürfnisse an Grundlagen wie die Rendering-Infrastruktur einher, weshalb Qt 6.0 in vielerlei Hinsicht als eine Art Neuanfang dient. Da sich das Team bei einer neuen Hauptversion nicht um Binärkompatibilität sorgen muss, kann es Änderungen leichter umsetzen.

Am Anfang steht die Installation

Die Einführung von QT 5.0 diente Digia als Möglichkeit für den großen Hausputz im Bereich der unterstützten Plattformen. Unter anderem Nokias Oldie Symbian fiel dabei über die Reling – trotz großer Community.

Qt 6 verhält sich ähnlich und unterstützt Windows ausschließlich in Version 10 und macOS nur in Version 10.15. In beiden Fällen ist eine 64-Bit-Plattform unbedingt erforderlich – 32-Bit-Systeme kommen nicht mehr zum Einsatz. Im Bereich der Unix-basierten Plattformen fällt der Kahlschlag noch deutlicher aus: Selbst vergleichsweise aktuelle Versionen wie Ubuntu 18.04 sind nicht mehr in der Liste der kompatiblen Systeme zu finden, sondern nur mehr

• Ubuntu 20.04
• CentOS 8.1
• SLES 15
• Open SUSE

Installationsversuche der Entwicklungsumgebung auf älteren Linux-Versionen scheitern mit kryptischen Fehlermeldungen.

Im Bereich der Mobilsysteme, die naturgemäß nur als Target-Plattformen gelistet sind, wird iOS in Version 13 und 14 sowie Android als Runtime ab API 21 (Android 5) unterstützt. Beim Build müssen die Werkzeuge in API-Version 28 (Android 9) vorliegen. Die Echtzeitbetriebssysteme BlackBerry QNX und GreenHill Integrity wird Qt wohl erst ab Version 6.2 vollständig unterstützen. WebAssembly gibt es erst in der Version 6.1.

Zum Verwenden des Installationstools ist ein Qt-Account erforderlich, der zwar kostenlos ist, aber einen zusätzlichen Anmeldeschritt voraussetzt. Zudem müssen Entwickler im Rahmen der Einrichtung nun die in Abbildung 1 gezeigten Warnungen abnicken.

Ende 2020 ist die Entwicklungsumgebung Qt Creator in Version 4.14 erschienen, die Komfortfunktionen für Qt 6 mitbringt. Wer parallel mit einer älteren Version arbeiten möchte, sollte nach dem Schema /opt/qt und /opt/qt6 zwei Ordner anlegen.

Wichtig ist im Zusammenhang mit der geänderten Plattformauswahl, dass das Übersetzen ausschließlich mit C++-17-Compilern erfolgt. Damit finden sich die Funktionen des Sprachstandards langsam, aber sicher auch in Qt-Code wieder und kommen im Framework bereits zum Einsatz.

(Keine) Änderung im Build-System

Das Kompilieren erfolgt wie seit Qt 4 gewohnt mit einer Kombination aus Hilfswerkzeugen und dem nativen Compiler der Zielplattform.

Bisher war für das Erzeugen des Makefiles allgemein das Werkzeug QMake vorgesehen, das für seine verständliche Syntax durchaus beliebt war. Seit geraumer Zeit bietet Qt Creator für neue Projekte die Option zur Auswahl eines Build-Systems an.

Neben den für das Erstellen regulärer Makefiles verantwortlichen Systemen QMake und CMake steht mit QBS ein Tool zur Verfügung, das stattdessen den kompletten Build-Prozess einer Qt-Anwendung erledigt.

Wer sich für CMake entscheidet, bekommt in der Projektstruktur eine neue Datei mit dem Namen "CMakeLists.txt". In ihr finden sich folgende Zeilen zur Konfiguration:

cmake_minimum_required(VERSION 3.5)
project(untitled-cmake LANGUAGES CXX)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

Die CMake-Integration unterscheidet sich von QMake unter anderem dadurch, dass das Build-System versucht, die Rolle der einzelnen Projektdateien zu ermitteln. Variablen wie CMAKE_AUTOMOC sorgen dafür, dass die passenden Qt-Hilfswerkzeuge automatisch Einzug in den Build-Prozess halten. Ein angenehmer Nebeneffekt ist, dass die Ressourcenliste nun einfacher ausfällt:

...
find_package(QT NAMES Qt6 Qt5 COMPONENTS Widgets REQUIRED)
find_package(Qt${QT_VERSION_MAJOR} COMPONENTS Widgets REQUIRED)

set(PROJECT_SOURCES
  main.cpp
  mainwindow.cpp
  mainwindow.h
  mainwindow.ui
)

if(${QT_VERSION_MAJOR} GREATER_EQUAL 6)
  qt_add_executable(untitled-cmake
  ${PROJECT_SOURCES}
)

Beim Verwenden von CMake sollten Entwickler die in Abbildung 4 gezeigte Einstellung beachten. Linux-Systeme bringen im Allgemeinen eine eigene Version von CMake mit, die Qt Creator von Haus aus in den Build-Prozess einbindet. Da sie jedoch nicht immer funktionieren, ist mitunter eine Anpassung erforderlich.

Auch wenn der Umstellung der Build-Systeme einige Aufmerksam zuteil wurde, berührt sie die meisten Qt-Entwickler kaum. Qt6 unterstützt über den gesamten Lebenszyklus der 6.x-Versionen des Frameworks weiterhin QMake, und die Qt Company gibt in der Dokumentation sogar an mehreren Stellen den Hinweis, dass Entwickler in Ermangelung eines automatisierten CMake-to-QMake-Konverters QMake-Dateien weiter nutzen sollen.

Brisant ist die Umstellung für jene, die ihre Qt-Distributionen komplett aus dem Quellcode kompilieren, da der Prozess ab sofort ausschließlich mit CMake erfolgt. Als kleine Erleichterung dürfen Entwickler die Compiler-Parameter nach wie vor über das von Qt5 bekannte Konfigurationsskript festlegen. Weitere Informationen finden sich in der Dokumentation und einem Blogbeitrag zum Build-System. In der Dokumentation findet sich zudem eine detaillierte Erläuterung des von QT Creator erzeugten Makefile.