Erstellen gängiger Projekttypen

Dieses Kapitel beschreibt, wie man qmake-Projektdateien für drei gängige Projekttypen, die auf Qt basieren, erstellt: Anwendung, Bibliothek und Plugin. Obwohl alle Projekttypen viele der gleichen Variablen verwenden, benutzt jeder von ihnen projektspezifische Variablen, um die Ausgabedateien anzupassen.

Plattformspezifische Variablen werden hier nicht beschrieben. Weitere Informationen finden Sie unter Qt für Windows - Deployment und Qt für macOS.

Erstellen einer Anwendung

Das app Template weist qmake an, ein Makefile zu erzeugen, das eine Applikation baut. Mit dieser Schablone kann der Typ der Anwendung durch Hinzufügen einer der folgenden Optionen zur CONFIG-Variablendefinition angegeben werden:

Wenn Sie diese Vorlage verwenden, werden die folgenden qmake-Systemvariablen erkannt. Sie sollten diese in Ihrer .pro-Datei verwenden, um Informationen über Ihre Anwendung anzugeben. Für weitere plattformabhängige Systemvariablen können Sie einen Blick in die Platform Notes werfen.

• HEADERS - Eine Liste von 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 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 ist dies der Name der Projektdatei. (Die Erweiterung, falls vorhanden, wird automatisch hinzugefügt).
• DESTDIR - Das Verzeichnis, in dem sich die ausführbare Zieldatei befindet.
• 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 Pfad für die Suche nach Abhängigkeiten für die Anwendung.
• VPATH - Der Suchpfad, um mitgelieferte Dateien zu finden.
• DEF_FILE - Nur für Windows: Eine .def-Datei, gegen die die Anwendung gelinkt werden soll.

Sie müssen nur die Systemvariablen verwenden, für die Sie Werte haben. Wenn Sie zum Beispiel keine zusätzlichen INCLUDEPATHs haben, brauchen Sie keine anzugeben. qmake fügt die notwendigen Standardwerte hinzu. Ein Beispiel für eine Projektdatei könnte so aussehen:

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

Für Elemente, die nur einen Wert haben, wie z.B. die Vorlage oder das Zielverzeichnis, verwenden wir "="; aber für mehrwertige Elemente verwenden wir "+=", um sie zu den vorhandenen Elementen dieses Typs hinzuzufügen. Mit "=" wird der Variablenwert durch den neuen Wert ersetzt. Wenn wir zum Beispiel DEFINES=USE_MY_STUFF schreiben, werden alle anderen Definitionen gelöscht.

Erstellen eines Testfalls

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

Für Testcase-Projekte 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 gleich Null beendet wird.

Das Ziel check durchläuft automatisch die SUBDIRS-Projekte. Das bedeutet, dass es möglich ist, einen make check -Befehl aus einem SUBDIRS-Projekt heraus zu geben, um eine ganze Testreihe auszuführen.

Die Ausführung des check Targets 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"

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

Testfälle werden oft mit QTest oder TestCase geschrieben, aber es ist keine Voraussetzung, CONFIG+=testcase und make check zu verwenden. Die einzige Hauptanforderung ist, dass das Testprogramm im Erfolgsfall mit einem Exit-Code von Null und im Fehlerfall mit einem Exit-Code ungleich Null endet.

Erstellen einer Bibliothek

Die Vorlage lib weist qmake an, ein Makefile zu erzeugen, das eine Bibliothek baut. Bei Verwendung dieser Schablone wird zusätzlich zu den Systemvariablen, die die app Schablone unterstützt, auch die VERSION Variable unterstützt. Verwenden Sie die Variablen in Ihrer .pro-Datei, um Informationen über die Bibliothek anzugeben.

Bei Verwendung der Schablone lib können die folgenden Optionen zur CONFIG-Variable hinzugefügt werden, um den Typ der zu erstellenden Bibliothek zu bestimmen:

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

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

Der Zieldateiname für die Bibliothek ist plattformabhängig. Unter X11, macOS und iOS wird dem Bibliotheksnamen beispielsweise das Präfix lib vorangestellt. Unter Windows wird dem Dateinamen kein Präfix hinzugefügt.

Erstellen eines Plugins

Plugins werden mit der Vorlage lib erstellt, wie im vorherigen Abschnitt beschrieben. Damit wird qmake angewiesen, ein Makefile für das Projekt zu erzeugen, das ein Plugin in einer für die jeweilige Plattform geeigneten Form erstellt, normalerweise 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 mit einem bestimmten Satz von Konfigurationseinstellungen erstellt, die davon abhängen, wie Qt für Ihr System konfiguriert wurde. Der Einfachheit halber können diese Einstellungen durch Hinzufügen von designer zur QT-Variable aktiviert werden. Ein Beispiel:

QT          += widgets designer

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

Bauen und Installieren im Debug- und Release-Modus

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

Bauen 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 Bereich im obigen Schnipsel ändert das Erstellungsziel in jedem Modus, um sicherzustellen, dass die resultierenden Ziele unterschiedliche Namen haben. Unterschiedliche Namen für Targets stellen sicher, dass das eine das andere nicht überschreibt.

Wenn qmake die Projektdatei verarbeitet, generiert es eine Makefile-Regel, damit das Projekt in beiden Modi gebaut werden kann. Dies kann auf die folgende Weise geschehen:

make all

Die Option build_all kann zu der Variable CONFIG in der Projektdatei hinzugefügt werden, um sicherzustellen, dass das Projekt standardmäßig in beiden Modi gebaut wird:

CONFIG += build_all

Dadurch kann das Makefile mit der Standardregel verarbeitet werden:

make

Installieren in beiden Modi

Die Option build_all stellt auch sicher, dass beide Versionen des Targets installiert werden, wenn die Installationsregel aufgerufen wird:

make install

Es ist möglich, die Namen der Build-Targets abhängig von der Zielplattform anzupassen. Beispielsweise kann eine Bibliothek oder ein Plugin unter Windows anders benannt werden als auf Unix-Plattformen:

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

Das Standardverhalten im obigen Schnipsel ist die Änderung des Namens, der für das Build-Ziel verwendet wird, wenn im Debug-Modus gebaut wird. Eine else Klausel könnte dem Bereich hinzugefügt werden, um das gleiche für den Release-Modus zu tun. So wie es ist, bleibt der Zielname unverändert.