Erweiterte Verwendung

Hinzufügen neuer Konfigurationsmerkmale

Mit qmake können Sie Ihre eigenen features erstellen, die in Projektdateien eingefügt werden können, indem Sie ihre Namen der Liste der Werte hinzufügen, die durch die CONFIG-Variable angegeben werden. Features sind Sammlungen von benutzerdefinierten Funktionen und Definitionen in .prf Dateien, die sich in einem von vielen Standardverzeichnissen befinden können. Die Orte dieser Verzeichnisse sind an verschiedenen Stellen definiert, und qmake überprüft jedes dieser Verzeichnisse in der folgenden Reihenfolge, wenn es nach .prf Dateien sucht:

1. In einem Verzeichnis, das in der Umgebungsvariablen QMAKEFEATURES aufgeführt ist, die eine Liste von Verzeichnissen enthält, die durch das Pfadlisten-Trennzeichen der Plattform (Doppelpunkt für Unix, Semikolon für Windows) getrennt sind.
2. In einem Verzeichnis, das in der Eigenschaftsvariablen QMAKEFEATURES aufgeführt ist und eine Liste von Verzeichnissen enthält, die durch das Pfadlisten-Trennzeichen der Plattform getrennt sind.
3. In einem Feature-Verzeichnis, das sich innerhalb eines mkspecs -Verzeichnisses befindet. mkspecs -Verzeichnisse können sich unter jedem der Verzeichnisse befinden, die in der Umgebungsvariablen QMAKEPATH aufgeführt sind, die eine Liste von Verzeichnissen enthält, die durch das Pfadlisten-Trennzeichen der Plattform getrennt sind. Zum Beispiel: $QMAKEPATH/mkspecs/<features>.
4. In einem Feature-Verzeichnis, das sich unterhalb des Verzeichnisses befindet, das durch die Umgebungsvariable QMAKESPEC bereitgestellt wird. Zum Beispiel: $QMAKESPEC/<features>.
5. In einem Feature-Verzeichnis, das sich im Verzeichnis data_install/mkspecs befindet. Zum Beispiel: data_install/mkspecs/<features>.
6. In einem Feature-Verzeichnis, das als Geschwisterverzeichnis des durch die Umgebungsvariable QMAKESPEC angegebenen Verzeichnisses existiert. Beispiel: $QMAKESPEC/../<features>.

Die folgenden Feature-Verzeichnisse werden nach Feature-Dateien durchsucht:

1. features/unix, features/win32, oder features/macx, je nach verwendeter Plattform
2. features/

Betrachten Sie zum Beispiel die folgende Zuordnung in einer Projektdatei:

CONFIG += myfeatures

Mit diesem Zusatz zur Variable CONFIG sucht qmake nach dem Parsen der Projektdatei an den oben genannten Stellen nach der Datei myfeatures.prf. Auf Unix-Systemen wird es nach der folgenden Datei suchen:

1. $QMAKEFEATURES/myfeatures.prf (für jedes Verzeichnis, das in der Umgebungsvariablen QMAKEFEATURES aufgeführt ist)
2. $$QMAKEFEATURES/myfeatures.prf (für jedes Verzeichnis, das in der Eigenschaftsvariable QMAKEFEATURES aufgeführt ist)
3. myfeatures.prf (im Stammverzeichnis des Projekts). Das Stammverzeichnis des Projekts wird durch die Datei der obersten Ebene .pro bestimmt. Wenn Sie jedoch die Datei .qmake.cache in einem Unterverzeichnis oder dem Verzeichnis eines Unterprojekts ablegen, wird das Stammverzeichnis des Projekts zum Unterverzeichnis selbst.
4. $QMAKEPATH/mkspecs/features/unix/myfeatures.prf und $QMAKEPATH/mkspecs/features/myfeatures.prf (für jedes in der Umgebungsvariablen QMAKEPATH aufgeführte Verzeichnis)
5. $QMAKESPEC/features/unix/myfeatures.prf und $QMAKESPEC/features/myfeatures.prf
6. data_install/mkspecs/features/unix/myfeatures.prf und data_install/mkspecs/features/myfeatures.prf
7. $QMAKESPEC/../features/unix/myfeatures.prf und $QMAKESPEC/../features/myfeatures.prf

Installieren von Dateien

Unter Unix ist es üblich, das Build-Tool auch für die Installation von Anwendungen und Bibliotheken zu verwenden, zum Beispiel durch den Aufruf von make install. Aus diesem Grund hat qmake das Konzept eines install set, ein Objekt, das Anweisungen darüber enthält, wie ein Teil eines Projekts zu installieren ist. Zum Beispiel kann eine Sammlung von Dokumentationsdateien auf folgende Weise beschrieben werden:

documentation.path = /usr/local/program/doc
documentation.files = docs/*

Der Member path teilt qmake mit, dass die Dateien in /usr/local/program/doc (dem Path-Member) installiert werden sollen, und der Member files gibt die Dateien an, die in das Installationsverzeichnis kopiert werden sollen. In diesem Fall wird alles, was sich im Verzeichnis docs befindet, nach /usr/local/program/doc kopiert.

Sobald ein Installationssatz vollständig beschrieben wurde, können Sie ihn mit einer Zeile wie dieser an die Installationsliste anhängen:

INSTALLS += documentation

qmake wird sicherstellen, dass die angegebenen Dateien in das Installationsverzeichnis kopiert werden. Wenn Sie mehr Kontrolle über diesen Prozess benötigen, können Sie auch eine Definition für das extra Member des Objekts angeben. Die folgende Zeile weist qmake zum Beispiel an, eine Reihe von Befehlen für dieses Installationsset auszuführen:

unix:documentation.extra = create_docs; mv master.doc toc.doc

Der Bereich unix stellt sicher, dass diese speziellen Befehle nur auf Unix-Plattformen ausgeführt werden. Geeignete Befehle für andere Plattformen können mit anderen Bereichsregeln definiert werden.

Die im Member extra angegebenen Befehle werden ausgeführt, bevor die Anweisungen in den anderen Membern des Objekts ausgeführt werden.

Wenn Sie einen eingebauten Installationssatz an die Variable INSTALLS anhängen und keine files oder extra Member angeben, wird qmake entscheiden, was für Sie kopiert werden muss. Zurzeit werden die Installationssätze target und dlltarget unterstützt. Ein Beispiel:

target.path = /usr/local/myprogram
INSTALLS += target

In den obigen Zeilen weiß qmake, was kopiert werden muss, und führt den Installationsprozess automatisch durch.

Hinzufügen von benutzerdefinierten Targets

qmake versucht, alles zu tun, was von einem plattformübergreifenden Build-Tool erwartet wird. Das ist oft nicht ideal, wenn Sie spezielle plattformabhängige Befehle ausführen müssen. Dies kann mit spezifischen Anweisungen an die verschiedenen qmake-Backends erreicht werden.

Die Anpassung der Makefile-Ausgabe erfolgt über eine objektähnliche API, wie sie auch an anderen Stellen in qmake zu finden ist. Objekte werden automatisch definiert, indem man ihre Mitglieder angibt. Ein Beispiel:

mytarget.target = .buildfile
mytarget.commands = touch $$mytarget.target
mytarget.depends = mytarget2

mytarget2.commands = @echo Building $$mytarget.target

Die obigen Definitionen definieren ein qmake-Target namens mytarget, das ein Makefile-Target namens .buildfile enthält, das wiederum mit dem Befehl touch erzeugt wird. Schließlich gibt das Mitglied .depends an, dass mytarget von mytarget2 abhängt, einem anderen Ziel, das danach definiert wird. mytarget2 ist ein Dummy-Ziel. Es wird nur definiert, um einen Text auf der Konsole auszugeben.

Der letzte Schritt besteht darin, die Variable QMAKE_EXTRA_TARGETS zu verwenden, um qmake mitzuteilen, dass dieses Objekt ein Ziel ist, das gebaut werden soll:

QMAKE_EXTRA_TARGETS += mytarget mytarget2

Das ist alles, was Sie tun müssen, um benutzerdefinierte Targets zu erstellen. Natürlich kann es sein, dass Sie eines dieser Targets mit dem qmake-Build-Target verknüpfen möchten. Um dies zu tun, müssen Sie einfach Ihr Makefile-Target in die Liste der PRE_TARGETDEPS aufnehmen.

Benutzerdefinierte Targetspezifikationen unterstützen die folgenden Member:

Hinzufügen von Compilern

Es ist möglich, qmake anzupassen, um neue Compiler und Präprozessoren zu unterstützen:

new_moc.output  = moc_${QMAKE_FILE_BASE}.cpp
new_moc.commands = moc ${QMAKE_FILE_NAME} -o ${QMAKE_FILE_OUT}
new_moc.depend_command = g++ -E -M ${QMAKE_FILE_NAME} | sed "s,^.*: ,,"
new_moc.input = NEW_HEADERS
QMAKE_EXTRA_COMPILERS += new_moc

Mit den obigen Definitionen können Sie einen Drop-in-Ersatz für moc verwenden, wenn einer verfügbar ist. Der Befehl wird mit allen Argumenten ausgeführt, die der Variablen NEW_HEADERS (aus dem Element input ) übergeben werden, und das Ergebnis wird in die Datei geschrieben, die durch das Element output definiert ist. Diese Datei wird zu den anderen Quelldateien im Projekt hinzugefügt. Zusätzlich führt qmake depend_command aus, um Abhängigkeitsinformationen zu generieren und legt diese Informationen ebenfalls im Projekt ab.

Benutzerdefinierte Compiler-Spezifikationen unterstützen die folgenden Member:

Das CONFIG-Mitglied unterstützt die folgenden Optionen:

Abhängigkeiten von Bibliotheken

Oft verlässt sich qmake beim Linken gegen eine Bibliothek darauf, dass die zugrundeliegende Plattform weiß, gegen welche anderen Bibliotheken diese Bibliothek linkt, und lässt die Plattform diese einbinden. In vielen Fällen ist dies jedoch nicht ausreichend. Wenn zum Beispiel eine Bibliothek statisch gelinkt wird, werden keine anderen Bibliotheken gelinkt und somit auch keine Abhängigkeiten zu diesen Bibliotheken erzeugt. Eine Anwendung, die später gegen diese Bibliothek linkt, muss jedoch wissen, wo die Symbole zu finden sind, die die statische Bibliothek benötigt. qmake versucht, die Abhängigkeiten einer Bibliothek gegebenenfalls zu verfolgen, wenn Sie das Tracking explizit aktivieren.

Der erste Schritt besteht darin, die Verfolgung von Abhängigkeiten in der Bibliothek selbst zu aktivieren. Dazu müssen Sie qmake anweisen, Informationen über die Bibliothek zu speichern:

CONFIG += create_prl

Dies ist nur für das lib Template relevant und wird für alle anderen ignoriert. Wenn diese Option aktiviert ist, erstellt qmake eine Datei mit der Endung .prl, die einige Meta-Informationen über die Bibliothek speichert. Diese Metadatei ist genau wie eine gewöhnliche Projektdatei, enthält aber nur interne Variablendeklarationen. Wenn Sie diese Bibliothek installieren, indem Sie sie als Ziel in einer INSTALLS-Deklaration angeben, kopiert qmake die .prl-Datei automatisch in den Installationspfad.

Der zweite Schritt in diesem Prozess besteht darin, das Lesen dieser Metainformationen in den Anwendungen zu aktivieren, die die statische Bibliothek verwenden:

CONFIG += link_prl

Wenn dies aktiviert ist, verarbeitet qmake alle Bibliotheken, die von der Applikation gelinkt werden, und findet deren Meta-Informationen. qmake verwendet diese, um die relevanten Linking-Informationen zu bestimmen, insbesondere um Werte zur Liste der DEFINES und LIBS in der Projektdatei der Applikation hinzuzufügen. Sobald qmake diese Datei verarbeitet hat, durchsucht es die neu hinzugefügten Bibliotheken in der Variable LIBS und findet deren abhängige .prl-Dateien, bis alle Bibliotheken aufgelöst sind. An diesem Punkt wird das Makefile wie üblich erstellt, und die Bibliotheken werden explizit mit der Anwendung gelinkt.

Die .prl-Dateien sollten nur von qmake erstellt werden und nicht zwischen Betriebssystemen übertragen werden, da sie plattformabhängige Informationen enthalten können.