Qt-Konfigurationsoptionen

configure ist ein Befehlszeilentool, das Sie beim Erstellen einer benutzerdefinierten Qt-Version aus dem Quellcode unterstützt. Es ist Teil des Hauptverzeichnisses der Qt-Quelldateien.

Seit Qt 6 ist „configure“ ein Wrapper um CMake. CMake kann auch direkt aufgerufen werden. „configure“ bietet zusätzliche Fehlerprüfung und Kompatibilität mit Qt 5.

Auf dieser Seite werden einige der „configure“-Optionen erläutert. Die vollständige Liste der Optionen erhalten Sie mit dem Befehl „ configure -h “.

Ablauf der Konfiguration

„configure“ muss in einer funktionierenden Build-Umgebung aufgerufen werden, in der CMake, Compiler und die erforderlichen Build-Tools bereits verfügbar sind. Unter „Qt-Quellcode kompilieren“ sind diese Abhängigkeiten für die einzelnen Plattformen aufgeführt.

Nach der Einrichtung einer solchen Umgebung besteht der typische Arbeitsablauf darin, ein separates Build-Verzeichnis zu erstellen und dann zunächst „configure“ auszuführen, anschließend Qt zu kompilieren und schließlich Qt zu installieren:

~/qt-source/configure
cmake --build . --parallel
cmake --install .

Möglicherweise möchten Sie mit verschiedenen „configure“-Flags experimentieren und daher „configure“ mehrmals ausführen. Beachten Sie, dass CMake „configure“-Optionen und Informationen zur Umgebung in einer Datei namens „CMakeCache.txt“ zwischenspeichert. Löschen Sie diese Datei, wenn Sie ohne zwischengespeicherte Informationen von vorne beginnen möchten.

Quell-, Build- und Installationsverzeichnisse

Das Quellverzeichnis enthält den Quellcode, der aus dem Quellpaket oder dem Git-Repository bezogen wird. Im Build-Verzeichnis werden die mit dem Build verbundenen Dateien gespeichert, wie z. B. Dateien des Build-Systems, Objektdateien und andere Zwischendateien. Im Installationsverzeichnis werden die Binärdateien und Bibliotheken installiert, die entweder vom System oder von der Anwendung genutzt werden.

Es wird empfohlen, diese Verzeichnisse durch „Shadow-Building“ und die Verwendung der Option `-prefix` voneinander zu trennen. Auf diese Weise können Sie den Qt-Quellbaum frei von Build-Artefakten und Binärdateien halten, die in einem separaten Verzeichnis gespeichert werden. Diese Methode ist sehr praktisch, wenn Sie mehrere Builds aus demselben Quellbaum, jedoch für unterschiedliche Konfigurationen erstellen möchten. Um einen Shadow-Build durchzuführen, führen Sie `configure` aus einem separaten Verzeichnis aus:

mkdir ~/qt-build
cd ~/qt-build
~/qt-source/configure -prefix /opt/Qt6

Die Konfiguration mit der Option -prefix bedeutet, dass die Qt-Binärdateien und -Bibliotheken in einem anderen Verzeichnis installiert werden, in diesem Fall in /opt/Qt6.

Beispiele, Tests und Werkzeuge

Standardmäßig konfiguriert „configure“ nur die Bibliotheken und Werkzeuge von Qt. Mit „ -make examples “ oder „ -make tests “ können Sie zusätzlich die mit Qt gelieferten Beispiele oder Tests erstellen:

~/qt-source/configure -make examples -make tests

Sie können Qt auch so konfigurieren, dass Beispiele, Tests und Werkzeuge zwar konfiguriert, standardmäßig aber nicht erstellt werden. Wenn Sie die CMake-Variablen „ QT_BUILD_EXAMPLES_BY_DEFAULT “, „ QT_BUILD_TESTS_BY_DEFAULT “ und „ QT_BUILD_TOOLS_BY_DEFAULT “ auf „OFF“ setzen, werden die entsprechenden Teile nicht von „ cmake --build . “ erstellt. Stattdessen generiert CMake einzelne Ziele, die Sie dann separat erstellen können.

Hier erstellen wir Qt-Bibliotheken und -Tools, aber auch das NotePad-Beispiel:

~/qt-source/configure -make examples -- -D QT_BUILD_EXAMPLES_BY_DEFAULT=OFF
cmake --build . --parallel
cmake --build . --parallel --target notepad

Build-Konfigurationen

Sie können Qt-Bibliotheken und -Tools in verschiedenen Varianten erstellen, die jeweils für einen anderen Anwendungsfall optimiert sind.

Debug- und Release-Builds

-release Weist den Compiler an, den Code zu optimieren und keine zusätzlichen Debug-Symbole neben Qt und seinen Tools bereitzustellen.

-debug Lässt einige Optimierungen weg, um das Debuggen von Qt und seinen Tools zu vereinfachen. Diese Option aktiviert außerdem die Generierung von Debug-Symbolen, mit denen Sie den Code und den Zustand der erstellten Bibliotheken in einem Debugger untersuchen können.

Schließlich ermöglicht „ -debug-and-release “, sowohl eine Debug- als auch eine Release-Variante der Qt-Bibliotheken in einem Durchgang zu erstellen. Dies wird nur unterstützt, wenn Sie einen Build für Windows konfigurieren.

Es gibt weitere Optionen zur Anpassung der Konfigurationen:

• -force-debug-info: Erstellt einen Release-Build mit Debug-Informationen.
• -separate-debug-info: Extrahiert die Debug-Informationen in eine separate Datei.
• -optimize-size: Optimiert Release-Builds hinsichtlich der Größe statt der Geschwindigkeit.

Statische und gemeinsam genutzte Builds

Qt-Module können als separate Bibliotheken erstellt werden, mit denen eine ausführbare Datei verknüpft wird und die beim Start (bei Qt-Bibliotheken) oder zur Laufzeit (bei Qt-Plugins) geladen werden. Dies wird als „Shared Build“ bezeichnet und ist auf den meisten Plattformen die Standardkonfiguration. Die entsprechende „configure“-Option lautet „ -shared “.

Sie können Qt auch so erstellen, dass eine ausführbare Binärdatei alle Qt-Module, mit denen sie verknüpft ist, sowie alle benötigten Qt-Plugins enthält. Dies wird als statischer Build bezeichnet und kann bei der Konfiguration mit der Option „ -static “ ausgewählt werden.

CMake-Generatoren

Bei der Konfiguration können Sie einen CMake-Generator auswählen. Beachten Sie, dass CMake Generatoren unterstützt, die nicht mit Qt verwendet werden können. Daher wählt „configure“ automatisch einen Generator für Sie aus.

„configure“ verwendet immer den Generator „ Ninja “ und das Build-Tool „Ninja“, sofern eine Ninja-Ausführungsdatei verfügbar ist. Ninja ist plattformübergreifend, funktionsreich und leistungsstark und wird auf allen Plattformen empfohlen. Die Verwendung anderer Generatoren funktioniert möglicherweise, wird jedoch nicht offiziell unterstützt.

Module und Funktionen

Der Qt-Quellcode ist in mehreren Verzeichnissen der obersten Ebene organisiert, die als Submodule bezeichnet werden, zum Beispiel qtbase, qtdeclarative oder qtmultimedia. Innerhalb dieser Submodule finden Sie den Quellcode für die verschiedenen Qt-Module. Qt Core, Qt Quick, und Qt Multimedia sind Beispiele für solche Qt-Module.

Submodule können explizit ein- oder ausgeschlossen werden, um die Bauzeiten zu verkürzen. Darüber hinaus verfügt jedes Qt-Modul möglicherweise über Funktionen, die ebenfalls explizit aktiviert oder deaktiviert werden können.

Ein- und Ausschließen von Qt-Submodulen

Die Option „ -skip “ von `configure` dient dazu, Submodule (Quellverzeichnisse auf oberster Ebene) vom Qt-Build auszuschließen. Durch das Ausschließen eines Submoduls werden alle darin enthaltenen Qt-Module ausgeschlossen. Das Submodul „ qtwayland “ enthält sowohl das Qt Wayland Compositor sowie das Qt-Wayland-QPA-Plugin. Die Angabe von ` -skip qtwayland ` als `configure`-Option schließt daher beide Qt-Module aus.

~/qt-source/configure -skip qtwayland

Die Option „ -submodules “ von „configure“ kann verwendet werden, um einen Build zu konfigurieren, bei dem nur die aufgeführten Submodule und deren Abhängigkeiten erstellt werden. Durch die Angabe des Submoduls „ qtmultimedia “ Qt Multimedia werden alle seine Abhängigkeiten in den Build einbezogen. Mehrere Submodule können durch Kommas getrennt werden.

~/qt-source/configure -submodules qtmultimedia,qtactiveqt

Ein- oder Ausschluss von Funktionen

Die Optionen „ -feature-<Feature> “ und „ -no-feature-<Feature>“ dienen dazu, bestimmte Funktionen einzubeziehen bzw. auszuschließen.

Beispielsweise können Sie die Konfigurationsoption „ -no-feature-accessibility “ verwenden, um die Barrierefreiheitsunterstützung in Qt zu deaktivieren:

~/qt-source/configure -no-feature-accessibility

Verwenden Sie „ configure -list-features “, um eine Liste aller verfügbaren Funktionen in der Befehlszeile anzuzeigen. Beachten Sie, dass Funktionen von anderen Funktionen abhängen können, sodass das Deaktivieren einer Funktion Nebenwirkungen auf andere Funktionen haben kann.

Bibliotheken von Drittanbietern

Die Qt-Quellpakete enthalten Bibliotheken von Drittanbietern. Um festzulegen, ob Qt die systemeigenen Versionen der Bibliotheken oder die mitgelieferte Version verwenden soll, übergeben Sie entweder „ -system “ oder „ -qt “ vor dem Namen der zu konfigurierenden Bibliothek.

Die folgende Tabelle fasst einige Optionen für Bibliotheken von Drittanbietern zusammen:

Es ist auch möglich, die Unterstützung für die meisten dieser Bibliotheken zu deaktivieren, indem man -no anstelle von -qt verwendet.

„configure“ in Qt 6 nutzt CMake, um Bibliotheken von Drittanbietern zu finden. Dazu werden verschiedene Systempfade überprüft. Wenn Sie Bibliotheken an einem anderen Ort installiert haben, können Sie CMake dies mitteilen, indem Sie die Variable „ CMAKE_PREFIX_PATH “ setzen oder erweitern.

Eine vollständige Liste der Optionen finden Sie in der Hilfe zu configure -help.

SSL

Qt Network kann so konfiguriert werden, dass es die Kommunikation über Secure Sockets Layer (SSL) unterstützt, implementiert die eigentlichen Algorithmen jedoch nicht selbst. Stattdessen muss es auf andere Bibliotheken zurückgreifen.

Unter Windows kann Qt zu diesem Zweck die Secure-Channel-Bibliothek des Systems verwenden (Konfigurationsoption „ -schannel “). Unter macOS und iOS kann Qt so konfiguriert werden, dass es die SecureTransport-API nutzt (Konfigurationsoption „ -securetransport “).

Die umfassendste Unterstützung, die zudem auf fast allen Zielplattformen funktioniert, bietet das OpenSSL-Toolkit (Option „ -openssl “). Qt benötigt hierfür OpenSSL 1.1.1 oder höher.

Qt kann auf drei Arten für die Verwendung von OpenSSL konfiguriert werden:

• Qt Network Lädt OpenSSL-Bibliotheken (DLLs) bei Bedarf erstmals zur Laufzeit. Werden diese nicht gefunden, läuft die Anwendung zwar weiter, kann jedoch die SSL-Kommunikation nicht verarbeiten. Dies wird durch die Konfigurationsoption „ -openssl-runtime “ aktiviert.
• Qt Network Die Anwendung wird gegen die OpenSSL-Bibliotheken verlinkt. Wenn diese zum Zeitpunkt des Ladens nicht gefunden werden, kann die Anwendung nicht gestartet werden. Dies wird durch die Konfigurationsoption „ -openssl-linked “ aktiviert.
• Qt Network wird mit einer statischen Version der OpenSSL-Bibliotheken kompiliert, und OpenSSL wird Teil der Bibliothek „ Qt Network “. Dies wird durch die Verwendung der Konfigurationsoption „ openssl-linked “ und die Einstellung der Variablen „ OPENSSL_USE_STATIC_LIBS “ auf „ ON “ aktiviert.

Setzen Sie die CMake-Variable ` OPENSSL_ROOT_DIR `, wenn OpenSSL nicht an einem Standardpfad installiert ist und daher von `configure` nicht gefunden wird.

Weitere Anweisungen zu Qt mit SSL-Unterstützung finden Sie unter „Secure Sockets Layer (SSL)-Klassen “.

Optionen für die Cross-Kompilierung

Um Qt für die plattformübergreifende Entwicklung und Bereitstellung zu konfigurieren, benötigen Sie zunächst eine passende Qt-Version für den Host-Rechner. Außerdem muss die Entwicklungs-Toolchain für die Zielplattform eingerichtet sein. Diese Einrichtung variiert je nach den unterstützten Plattformen.

Gängige Optionen sind:

• -external-hostbindir - Pfad zu den für diesen Rechner kompilierten Qt-Tools.
• -device - Wählen Sie „devices/mkspec“ für die qmake-Begleitdateien aus.
• -device-option - Legt zusätzliche qmake-Variablen fest.

Entwickler-Builds

Die Konfigurationsoption „ -developer-build “ ist eine Komfortoption, die den Build für die Entwicklung von Qt selbst optimiert. Sie sollte nicht zum Erstellen von Qt-Varianten verwendet werden, die an Kunden ausgeliefert werden.

Bibliotheken in einem Entwickler-Build enthalten mehr exportierte Symbole als ein Standard-Build, und der gesamte Qt-Code wird mit einer höheren Warnstufe kompiliert. Außerdem wird das Standardpräfix auf das Build-Verzeichnis geändert, wodurch die Notwendigkeit entfällt, Qt vor dem Testen zu installieren, und schließlich wird die Kompilierung der Qt-Autotests standardmäßig aktiviert.

Neukonfiguration bestehender Builds

Das Qt-Build-System bietet grundlegende Unterstützung für die Neukonfiguration bestehender Qt-Builds mit anderen „configure“-Optionen, ist jedoch aufgrund der internen Funktionsweise von CMake nicht sehr robust.

Der sicherste Weg, einen bestehenden Build neu zu konfigurieren, besteht darin, die Option „ -redo “ an „configure“ zu übergeben. Dadurch wird die Datei „CMakeCache.txt“ des Builds entfernt, was einen relativ sicheren Zustand für die Neukonfiguration gewährleistet. Die ursprünglichen „configure“-Flags gelten weiterhin für den neu konfigurierten Build.

Installation der „Configure“-Zusammenfassung und der Optionen

Seit Qt 6.9 können die „configure“-Zusammenfassungsdateien sowie die an ` configure` übergebenen Optionen automatisch als Teil der Installation einbezogen werden.

Diese Funktion wird durch Setzen der CMake-Variablen ` QT_INSTALL_CONFIG_INFO_FILES ` auf ` ON` aktiviert:

~/qt-source/configure -prefix /opt/Qt6 -- -D QT_INSTALL_CONFIG_INFO_FILES=ON

Während der Installation werden Textdateien für die „configure“-Zusammenfassung und die Optionen (für jeden Repository-Teil des Builds) in das Verzeichnis „ architecture-independent Qt data directory “ kopiert.

Beispielsweise

/opt/Qt6/config_qtbase.opt
/opt/Qt6/config_qtbase.summary
/opt/Qt6/config_qtdeclarative.opt
/opt/Qt6/config_qtdeclarative.summary
...

Spezifische Optionen für Plattformen

Die folgenden Seiten enthalten Anleitungen zur Konfiguration von Qt für die Entwicklung auf bestimmten Plattformen:

• Qt für QNX erstellen
• Qt für VxWorks erstellen
• Ein Embedded-Linux-Gerät konfigurieren
• Qt für Android – Kompilieren aus dem Quellcode
• Qt für HarmonyOS – Kompilieren aus dem Quellcode
• Qt für Linux – Kompilieren aus dem Quellcode
• Qt für Windows – Kompilieren aus dem Quellcode
• Qt für macOS – Kompilieren aus dem Quellcode
• Qt für INTEGRITY – Tutorial zum Monolith-Projekt
• Qt für iOS – Kompilieren aus dem Quellcode
• Qt für WebAssembly – Kompilieren aus dem Quellcode