Erstellen gängiger Projekttypen

In diesem Kapitel wird beschrieben, wie man qmake-Projektdateien für drei gängige, auf Qt basierende Projekttypen einrichtet: Anwendung, Bibliothek und Plugin. Obwohl alle Projekttypen viele der gleichen Variablen verwenden, nutzt jeder von ihnen projektspezifische Variablen, um die Ausgabedateien anzupassen.

Plattformspezifische Variablen werden hier nicht beschrieben. Weitere Informationen finden Sie unter „Qt für Windows – Bereitstellung “ und „Qt für macOS“.

Erstellen einer Anwendung

Die Vorlage „ app “ weist qmake an, eine Makefile-Datei zu generieren, mit der eine Anwendung erstellt wird. Mit dieser Vorlage kann der Anwendungstyp festgelegt werden, indem eine der folgenden Optionen zur Definition der Variablen CONFIG hinzugefügt wird:

Bei Verwendung dieser Vorlage werden die folgenden qmake-Systemvariablen erkannt. Sie sollten diese in Ihrer .pro-Datei verwenden, um Informationen zu Ihrer Anwendung anzugeben. Weitere plattformabhängige Systemvariablen finden Sie in den Plattformhinweisen.

• HEADERS – Eine Liste der Header-Dateien für die Anwendung.
• SOURCES – Eine Liste der C++-Quelldateien für die Anwendung.
• FORMS – Eine Liste der UI-Dateien für die Anwendung (erstellt mit dem „ Qt Widgets -Designer“).
• LEXSOURCES – Eine Liste der Lex-Quelldateien für die Anwendung.
• YACCSOURCES – Eine Liste der Yacc-Quelldateien für die Anwendung.
• TARGET – Name der ausführbaren Datei für die Anwendung. Standardmäßig entspricht dieser dem Namen der Projektdatei. (Eine eventuelle Dateiendung wird automatisch hinzugefügt.)
• DESTDIR – Das Verzeichnis, in dem die ausführbare Zieldatei abgelegt wird.
• DEFINES – Eine Liste aller zusätzlichen Präprozessor-Definitionen, die für die Anwendung benötigt werden.
• INCLUDEPATH – Eine Liste aller zusätzlichen Include-Pfade, die für die Anwendung benötigt werden.
• DEPENDPATH – Der Suchpfad für die Abhängigkeiten der Anwendung.
• VPATH – Der Suchpfad zum Auffinden der bereitgestellten Dateien.
• DEF_FILE – Nur Windows: Eine .def-Datei, die für die Anwendung eingebunden werden soll.

Sie müssen nur die Systemvariablen verwenden, für die Sie Werte haben. Wenn Sie beispielsweise keine zusätzlichen INCLUDEPATHs haben, müssen Sie auch keine angeben. qmake fügt die erforderlichen Standardwerte hinzu. Eine Beispielprojektdatei könnte wie folgt aussehen:

TEMPLATE = app
DESTDIR  = c:/helloapp
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
DEFINES += USE_MY_STUFF
CONFIG  += release

Für Elemente mit einem einzigen Wert, wie z. B. die Vorlage oder das Zielverzeichnis, verwenden wir „=“; für Elemente mit mehreren Werten verwenden wir jedoch „+=“, um die vorhandenen Elemente dieses Typs zu ergänzen. Die Verwendung von „=“ ersetzt den Variablenwert durch den neuen Wert. Wenn wir beispielsweise „ DEFINES=USE_MY_STUFF “ schreiben, werden alle anderen Definitionen gelöscht.

Erstellen eines Testfalls

Ein Testfallprojekt ist ein „ app “-Projekt, das als automatisierter Test ausgeführt werden soll. Jedes „ app “ kann als Testfall markiert werden, indem der Wert „ testcase “ der Variablen „ CONFIG “ hinzugefügt wird.

Bei Testfall-Projekten fügt qmake ein check -Ziel in das generierte Makefile ein. Dieses Ziel führt die Anwendung aus. Der Test gilt als bestanden, wenn er mit einem Exit-Code von Null endet.

Das Ziel „ check “ durchläuft SUBDIRS-Projekte automatisch rekursiv. Das bedeutet, dass es möglich ist, innerhalb eines SUBDIRS-Projekts den Befehl „ make check “ auszuführen, um eine gesamte Testsuite auszuführen.

Die Ausführung des Ziels „ check “ kann durch bestimmte Makefile-Variablen angepasst werden. Diese Variablen sind:

# Run tests through test-wrapper and use JUnit XML output format.
# In this example, test-wrapper is a fictional wrapper script which terminates
# a test if it does not complete within the amount of seconds set by "--timeout".
# The "-o result.xml,junitxml" options are interpreted by QTestLib.
make check TESTRUNNER="test-wrapper --timeout 120" TESTARGS="-o result.xml,junitxml"

Testfall-Projekte können mit den folgenden CONFIG -Optionen weiter angepasst werden:

Testfälle werden häufig mit „ QTest “ oder „ TestCase “ geschrieben, es ist jedoch keine Voraussetzung, „ CONFIG+=testcase “ und „ make check “ zu verwenden. Die einzige wesentliche Voraussetzung ist, dass das Testprogramm bei Erfolg mit einem Exit-Code von Null und bei Fehlschlag mit einem Exit-Code ungleich Null beendet wird.

Erstellen einer Bibliothek

Die Vorlage „ lib “ weist qmake an, ein Makefile zu generieren, mit dem eine Bibliothek erstellt wird. Bei Verwendung dieser Vorlage wird zusätzlich zu den Systemvariablen, die die Vorlage „ app “ unterstützt, auch die Variable „VERSION“ unterstützt. Verwenden Sie die Variablen in Ihrer .pro-Datei, um Informationen zur Bibliothek anzugeben.

Bei Verwendung der Vorlage „ lib “ können der Variablen „CONFIG“ die folgenden Optionen hinzugefügt werden, um den Typ der zu erstellenden Bibliothek festzulegen:

Die folgende Option kann ebenfalls definiert werden, um zusätzliche Informationen über die Bibliothek bereitzustellen.

• VERSION – Die Versionsnummer der Zielbibliothek. Zum Beispiel 2.3.1.

Der Name der Zieldatei für die Bibliothek ist plattformabhängig. Beispielsweise wird unter X11, macOS und iOS dem Bibliotheksnamen das Präfix „ lib “ vorangestellt. Unter Windows wird dem Dateinamen kein Präfix hinzugefügt.

Erstellen eines Plugins

Plugins werden mithilfe der Vorlage „ lib “ erstellt, wie im vorherigen Abschnitt beschrieben. Dadurch wird qmake angewiesen, ein Makefile für das Projekt zu generieren, das ein Plugin in einer für die jeweilige Plattform geeigneten Form erstellt, in der Regel in Form einer Bibliothek. Wie bei gewöhnlichen Bibliotheken wird die Variable VERSION verwendet, um Informationen über das Plugin anzugeben.

• VERSION – Die Versionsnummer der Zielbibliothek. Zum Beispiel 2.3.1.

Erstellen eines „ Qt Widgets “-Designer-Plugins

Qt Widgets Designer-Plugins werden unter Verwendung einer bestimmten Reihe von Konfigurationseinstellungen erstellt, die davon abhängen, wie Qt für Ihr System konfiguriert wurde. Der Einfachheit halber können diese Einstellungen aktiviert werden, indem „ designer “ zur Variablen „QT“ hinzugefügt wird. Zum Beispiel:

QT          += widgets designer

Weitere Beispiele für Plugin-basierte Projekte finden Sie in den „Qt Widgets Designer Examples “.

Erstellen und Installieren im Debug- und Release-Modus

Manchmal ist es erforderlich, ein Projekt sowohl im Debug- als auch im Release-Modus zu erstellen. Obwohl die Variable `CONFIG` sowohl die Option ` debug ` als auch die Option ` release ` enthalten kann, wird nur die zuletzt angegebene Option angewendet.

Erstellen in beiden Modi

Damit ein Projekt in beiden Modi erstellt werden kann, müssen Sie die Option „ debug_and_release “ zur Variablen „ CONFIG “ hinzufügen:

CONFIG += debug_and_release

CONFIG(debug, debug|release) {
    TARGET = debug_binary
} else {
    TARGET = release_binary
}

Der Geltungsbereich im obigen Ausschnitt passt das Build-Ziel in jedem Modus so an, dass die resultierenden Ziele unterschiedliche Namen erhalten. Durch die Verwendung unterschiedlicher Namen für die Ziele wird sichergestellt, dass sich diese nicht gegenseitig überschreiben.

Wenn qmake die Projektdatei verarbeitet, generiert es eine Makefile-Regel, die es ermöglicht, das Projekt in beiden Modi zu erstellen. Diese kann wie folgt aufgerufen werden:

make all

Die Option „ build_all “ kann der Variablen „ CONFIG “ in der Projektdatei hinzugefügt werden, um sicherzustellen, dass das Projekt standardmäßig in beiden Modi erstellt wird:

CONFIG += build_all

Dadurch kann das Makefile unter Verwendung der Standardregel verarbeitet werden:

make

Installation in beiden Modi

Die Option ` build_all ` stellt außerdem sicher, dass beide Versionen des Ziels installiert werden, wenn die Installationsregel aufgerufen wird:

make install

Es ist möglich, die Namen der Build-Ziele je nach Zielplattform anzupassen. Beispielsweise kann eine Bibliothek oder ein Plugin unter Windows nach einer anderen Konvention benannt werden als auf Unix-Plattformen:

CONFIG(debug, debug|release) {
    mac: TARGET = $$join(TARGET,,,_debug)
    win32: TARGET = $$join(TARGET,,d)
}

Das Standardverhalten im obigen Ausschnitt besteht darin, den für das Build-Ziel verwendeten Namen beim Erstellen im Debug-Modus zu ändern. Eine ` else `-Klausel könnte dem Geltungsbereich hinzugefügt werden, um dasselbe für den Release-Modus zu bewirken. Bleibt dies unverändert, bleibt der Zielname unverändert.