Nicht dokumentiertes QMake

pro, QMake, Qt

Einführung

Qmake ist ein sehr leistungsfähiges "Meta-Make"-System, das zum Generieren von Makefiles für verschiedene Compiler und Plattformen aus derselben qmake-Projektdatei (.pro) verwendet werden kann. Dokumentation für qmake hat sich seit Qt3 stark verbessert, aber einige Informationen fehlen noch. In diesem Artikel erklären wir alles anhand von Beispielen.

Bitte beachten Sie, dass die Informationen für Qt4 geschrieben wurden, einige davon jedoch möglicherweise in Qt3 funktionieren. Sollte übrigens in Qt5 funktionieren oder erwägen, es zu löschen.

Undokumentierte Variablen

Die einfachste Art der Kontrolle, die Sie über ein generiertes Makefile haben können, ist die Verwendung der eingebauten Variablen, die von qmake bereitgestellt werden. Das Problem ist natürlich, dass viele dieser Variablen nicht in der qmake-Dokumentation aufgeführt sind. Aber Sie haben hier eine praktische Liste von allen (zusammen mit einer reichen Quelle von Tricks und Hacks, die von Trolltech (derzeit Qt Company - Hrsg.) geschrieben und sorgfältig für Sie abgebaut wurden). In Ihrem qmake-Installationsverzeichnis gibt es ein Unterverzeichnis namens "mkspecs". Es enthält Definitionen für alle Plattform/Compiler-Kombinationen, die qmake unterstützt (beachten Sie, dass nicht alle "formal" unterstützt werden!) An verschiedenen Stellen gibt es Verzeichnisse mit dem Namen "features", dort finden Sie qmake-Code für viele Dinge, die Sie aktivieren können die CONFIG-Variable.

Wenn Sie also versuchen, etwas herauszufinden wie: "Wie ändere ich den Namen des Compilers, der im Makefile verwendet wird?" oder "Wie kann ich ändern, wie die Kopierdatei für 'make install' aufgerufen wird?" und dergleichen, sollten Sie im mkspecs-Verzeichnis nach dem Namen der Variablen suchen, die Sie ändern möchten.

Hier sind einige besonders nützliche (ab v4.3.4), die bei der Untersuchung der qmake-Quelle gefunden wurden:

• DATE - aktuelles Datum und Uhrzeit. (V4.3.4)
• FILE ist der aktuelle Dateiname, den qmake analysiert. (V4.3.4)
• LINE ist die aktuelle Zeilennummer, wie sie von qmake geparst wird. (V4.3.4)
• QMAKE_CACHE ist der Pfad zu jeder verwendeten .qmake.cache-Datei. (V4.3.4)
• DIR_SEPARATOR oder QMAKE_DIR_SEP ist je nach Hostplattform ein Vorwärts- oder Backslash-Zeichen.
• IN_PWD - Basisverzeichnis des Quellbaums. (V4.3.4)
• QMAKE_NOFORCE - Verzichte auf die Verwendung des "FORCE"-Targets.
• QMAKE_utility ist der Befehl für das Dienstprogramm, das dem Makro mit dem Namen Dienstprogramm in den generierten Makefiles zugewiesen wird. Utility-Makronamen werden für verschiedene Standardzwecke geeignet verwendet. Der Wert dieser Variablen kann geändert werden, um verschiedene Dienstprogrammbefehle anzugeben, und die Variablen – in der Form $$variable_name oder $(macro_name) – können verwendet werden, wenn Befehle für QMAKE_EXTRA_TARGETS definiert werden. Utility-Namen:
  QMAKE_CHK_DIR_EXISTS
• QMAKE_COPY
• QMAKE_COPY_DIR
• QMAKE_COPY_FILE
• QMAKE_DEL_DIR
• QMAKE_DEL_FILE
• QMAKE_INSTALL_DIR
• QMAKE_INSTALL_FILE
• QMAKE_INSTALL_PROGRAM
• QMAKE_LINK (wird verwendet, um ausführbare Dateien zu verknüpfen)
• QMAKE_LINK_SHLIB
• QMAKE_MKDIR
• QMAKE_MOVE
• QMAKE_QMAKE
• QMAKE_STRIP
• QMAKE_SYMBOLIC_LINK (wird dem Makro SYMLINK zugewiesen)
• QMAKE_ARGS - Parameter, die zum Aufrufen von qmake verwendet werden.
• QMAKE_PROJECT_DEPTH - Wenn Sie eine große Anzahl von .pro (und Unterordnern) in der .pro-Hauptdatei verwenden, kann es praktisch sein, einen Wert größer als 4 für diese Variable festzulegen, dies stellt die Anzahl der Unterordner dar, auf die sich qmake in relativen Pfaden bezieht (die Tiefe wird in makefile.cpp = 4 gesetzt). Dies ist besonders nützlich, wenn Sie Windows (nmake/jom) mit Leerzeichen im Stammpfad des Projekts verwenden.

Benutzerdefinierte Tools

Die Dokumentation für qmake in Qt4 erwähnt kurz die Möglichkeit von benutzerdefinierten "Compilern", aber leider nicht viel zu beschreiben.

Es gibt einige spezielle Pseudovariablen, die Sie in benutzerdefinierten Compilern verwenden können. Ich sage "Pseudo-Variablen" aus zwei Gründen: Erstens verwenden sie nur ein Dollarzeichen; und zweitens werden sie später ausgewertet als alles, was Sie verwenden möchten. Aus diesem Grund tun Funktionen wie $$replace(...) und Operatoren wie ~= nicht das, was sie sollten - sie verhalten sich so, als würden Sie ihnen eine leere Variable übergeben.

Ich hoffe, Trolltech (Qt Company) hat Ihnen bereits gegeben, was Sie brauchen!

• QMAKE_FILE_IN ist der Eingabename der Datei(en) mit einem Pfad, falls angegeben, den der Compiler verarbeitet,
• QMAKE_FILE_OUT - der Inhalt der Variable "compiler.output" für den aktuellen Wert von ${QMAKE_FILE_IN}, d. h. die aktuelle Ausgabedatei,
• QMAKE_FILE_IN_BASE (oder QMAKE_FILE_BASE) - Name der aktuellen Eingabedatei ohne Erweiterung,
• QMAKE_FILE_IN_PATH (oder QMAKE_FILE_PATH) ist nur der Pfad zur aktuellen Eingabedatei,
• QMAKE_FILE_OUT_BASE - aktueller Ausgabedateiname ohne Erweiterung,
• QMAKE_FILE_OUT_PATH - nur der Pfad zur aktuellen Ausgabedatei,
• QMAKE_FILE_EXT ist die Dateierweiterung der Eingabedatei, einschließlich des Punktes.

Die einfachste Definition eines benutzerdefinierten Tools sieht normalerweise so aus:

idl_c.output = ${QMAKE_FILE_IN}.c
idl_c.input = IDL
idl_c.commands = $${QMAKE_IDL} ${QMAKE_FILE_IN} $${IDLFLAGS} \
                 /h ${QMAKE_FILE_IN}.h /iid ${QMAKE_FILE_IN}.c
idl_c.variable_out = SOURCES
idl_c.name = MIDL

QMAKE_EXTRA_COMPILERS += idl_c

In diesem Beispiel wird der Microsoft MIDL-Compiler für eine .ODL-Datei ausgeführt und ein .c- und .h-Paar mit COM-Hostinformationen generiert.

Um ein benutzerdefiniertes Werkzeug zu definieren, müssen Sie zunächst einen Namen für die zu definierende zusammengesetzte Variable (ähnlich einer Struktur) auswählen. Im obigen Beispiel habe ich "idl.c" gewählt.

Es gibt mehrere Eigenschaften, die in eine benutzerdefinierte Werkzeugdefinition aufgenommen werden können:

• .commands - Gibt den Befehl an, der für jede der Quelldateien ausgeführt werden soll. Beachten Sie, dass Sie für alle normalen qmake-Variablen, die Sie erweitern möchten, ein doppeltes $ verwenden müssen (dies schließt QMAKE_FILE_IN und Co. nicht ein).
• .clean_commands - gibt die Befehle an, die ausgeführt werden sollen, um die extra generierten Ausgabedateien zu bereinigen,
• .clean - installiert Dateien, die mit make clean entfernt werden sollten,
• .depend_command - gibt den Befehl an, der ausgeführt werden soll, um Abhängigkeitsinformationen zu generieren,
• .dependency_type - verwendet einen der Standardalgorithmen zur Umgehung von Abhängigkeiten, die in qmake eingebaut sind. Seit Version 4.3.3 sind TYPE_C und TYPE_UI gültig.
• .depends - Installiert Dateien, die Abhängigkeiten für diesen Schritt sind. Die Ausgabe von .depend_command, sofern verwendet, sollte hier aufgelistet werden. Dies kann auch verwendet werden, um zu überprüfen, ob sich die ausführbare Compiler-Datei selbst geändert hat,
• .input - setzt eine qmake-Variable, die eine Liste von Dateien enthält, auf denen dieser Compiler laufen soll,
• .name scheint nur ein interner Name zu sein, der in qmake verwendet wird; Stellen Sie einfach sicher, dass Sie für jeden benutzerdefinierten Compiler unterschiedliche Werte verwenden.
• .output - legt den Namen der Ausgabedatei fest, die der Schritt generiert. Die Variable ${QMAKE_FILE_IN} kann verwendet werden, um dies auf den Namen der Eingabedatei zu basieren. Der Standardwert ist GENERATED_SOURCES,
• .output_function - Benennt die mit defineReplace definierte Funktion, die verwendet wird, um den Namen der Ausgabedatei zu bestimmen. An diese Funktion wird die Variable ${QMAKE_FILE_IN} übergeben und ihr Rückgabewert als Name der Ausgabedatei verwendet. Stellen Sie sicher, dass die Funktion existiert und tatsächlich etwas zurückgibt, da Sie sonst irreführende Fehlermeldungen erhalten.
• .variable_out - generierte Zieldateien, die während des Erstellungsschritts ausgegeben werden, werden dieser Variablen hinzugefügt. In diesem Fall generiert der Schritt eine .c-Datei, sodass die Dateien zu SOURCES hinzugefügt werden müssen.
• .variables - Es ist nicht genau klar, was diese Funktion macht.
• .verify_function - verbunden mit dem function_verify-Flag in .CONFIG - es ist nicht genau klar, was diese Funktion tut.

Es gibt auch eine .CONFIG-Eigenschaft, die selbst mehrere spezielle Flags hat, die Sie mit einer Syntax setzen können, die mit der Haupt-CONFIG-Variable identisch ist:

• kombinieren (kombinieren) - Rufen Sie den Compiler mit einer Liste aller Dateien in der Quellvariable auf, und nicht einmal für jede Datei,
• xplicit_dependencies - Quellkommentar: "compiler.CONFIG + =xplicit_dependencies bedeutet, dass NUR compiler.depends Makefile-Abhängigkeiten aufrufen kann",
• function_verify - siehe auch .verify_function oben,
  *ignore_no_exist - Ignoriert (nicht verarbeitet) Dateien in der Eingabeliste, die nicht existieren. Wenn diese Funktion nicht gesetzt ist, wird eine Warnung ausgegeben, dass die Eingabedatei noch verarbeitet wird,
• moc_verify - stellt höchstwahrscheinlich sicher, dass die Datei durch den moc-Präprozessor geleitet werden muss, bevor sie als moc-Ziel hinzugefügt wird.
• no_dependencies - erzeuge keine Abhängigkeiten von Dateien in der Quellvariable,
• no_link - erstellte Dateien sollten nicht zu OBJECTS hinzugefügt werden - d.h. sie sind kein kompilierter Code, der gelinkt werden muss,
• target_predeps - garantiert höchstwahrscheinlich, dass der benutzerdefinierte Compiler zuerst im Projekt ausgeführt wird,
• verifizieren (prüfen) - es wird nicht verraten, was diese Funktion macht. Der benutzerdefinierte Compiler wird nie aufgerufen, wenn er aktiviert ist.

Nachdem Sie eine Verbundvariable für ein Tool definiert haben, müssen Sie diese Verbundvariable zu QMAKE_EXTRA_COMPILERS hinzufügen. Dies weist qmake an, sich die von Ihnen angegebenen Dateien anzusehen und dieses Tool darauf auszuführen.

Beispiele

Hier ist ein weiteres und ungewöhnliches Beispiel:

CFLAGS_FILE = .   # Need to give some bogus input
compile_inp.output = compile.inp
compile_inp.input = CFLAGS_FILE
compile_inp.commands = echo >\$(OBJECTS_DIR)compile.inp \$(CXXFLAGS)
compile_inp.name = compile.inp
compile_inp.variable_out = JUNK
compile_inp.CONFIG = no_link
QMAKE_EXTRA_COMPILERS += compile_inp

Dieses Tool gibt einfach den Inhalt der CXXFLAGS-Variablen in eine Datei namens „compile.inp“ aus. Da dieses Tool darauf ausgelegt ist, eine Datei mit einem festen Namen zu erstellen, enthält die an .input übergebene Variable nur "." (aktuelles Verzeichnis), das immer vorhanden sein wird (aber in der Regel nirgendwo verwendet wird). Diese Regel verwendet das Konstrukt \$(foo), das die Variablenerweiterung im GNU Make- oder NMAKE-Format ausgibt und die Variablenerweiterung grundsätzlich verzögert, bis make oder NMAKE im generierten Makefile aufgerufen wird.

Möglichkeit, verschiedene Dateien mit unterschiedlichen CXXFLAGS zu kompilieren (basierend auf qt/src/gui/painting/painting.pri):

SOURCES_NOOPTIMIZE = somefile.cpp
nooptimize.name = nooptimize
nooptimize.input = SOURCES_NOOPTIMIZE
nooptimize.dependency_type = TYPE_C
nooptimize.variable_out = OBJECTS
nooptimize.output = ${QMAKE_VAR_OBJECTS_DIR}${QMAKE_FILE_IN_BASE}$${first(QMAKE_EXT_OBJ)}
nooptimize.commands = $${QMAKE_CXX} $(CXXFLAGS) -O0 $(INCPATH) -c ${QMAKE_FILE_IN} -o ${QMAKE_FILE_OUT} # Note the -O0
QMAKE_EXTRA_COMPILERS += nooptimize

Natürlich können Sie anstelle von -O0, das zum Deaktivieren von Optimierungen verwendet wird, verschiedene benutzerdefinierte Flags angeben.

Und schließlich ein Beispiel, wie Sie jedes Mal, wenn Sie Ihren Code kompilieren, eine Batchdatei mit dem Namen "PreBuildEvent.bat" aufrufen (getestet in VisualStudio basierend auf qt-creator-enterprise-src-3.1.0\share\qtcreator\static. pro) :

PRE_BUILD_FILE = ../Applications/PreBuildEvents.bat
# должен использовать переменную в качестве входных данных
PHONY_DEPS = .
PreBuildEvent.input = PHONY_DEPS
# использовать несуществующий файл для выполнения каждый раз
PreBuildEvent.output = phony.txt
# tсистемный вызов командного файла
PreBuildEvent.commands = call $$PRE_BUILD_FILE
# какое-то имя, которое отображается во время исполнения
PreBuildEvent.name = running Pre-Build steps...
# «no_link» сообщает qmake, что нам не нужно добавлять выходные данные в объектные файлы для компоновки, а «no_clean» означает, что для них нет чистого шага.
# «target_predeps» сообщает qmake, что выходные данные этого должны существовать, прежде чем мы сможем выполнить остальную часть нашей компиляции.
PreBuildEvent.CONFIG += no_link no_clean target_predeps
# Добавьте компилятор в список «дополнительных компиляторов».
QMAKE_EXTRA_COMPILERS += PreBuildEvent

Konfigurationsfunktionen

Es gibt mehrere "Schalter", die der CONFIG-Variablen hinzugefügt werden können, die sich auf das Verhalten von qmake auswirken (beachten Sie, dass dies keine CONFIG-Funktionen enthält, die für benutzerdefinierte Tools oder Installer spezifisch sind):

• app_bundle - Verwandelt das Ziel in ein Bundle und nicht in eine eigenständige ausführbare Datei (nur Mac).
• compile_libtool - Verwendet "libtool" zum Kompilieren, Linken usw. anstelle eines regulären Compilers (nur *nix).
• echo_depend_creation - gibt während der Erstellung von Abhängigkeiten Meldungen auf dem Bildschirm aus (nur *nix).
• generate_pbxbuild_makefile - Generiert einen Makefile-Wrapper für ein PowerBuilder-Projekt (nur Mac).
• GNUmake - Erlaubt dem GNU-Make-Tool, Abhängigkeiten zu bestimmen (nur *nix).
• lib_bundle - Verwandelt das Ziel in ein Bundle statt in eine eigenständige Bibliothek (nur Mac).
• no_autoqmake - Verhindert, dass das Ausgabe-Makefile qmake aufruft, wenn sich die .pro-Datei geändert hat.
• no_empty_targets - stellt sicher, dass Projekte, die auf SUBDIR basieren, keine Ziele haben, die nichts tun (sie werden stattdessen mit "cd." gefüllt).
• no_fix_and_continue - Deaktiviert die "Fix and Continue"-Funktion von GCC (nur Mac).
• no_include_pwd - überspringt das aktuelle Verzeichnis ab dem letzten INCLUDEPATH.
• no_pb_munge_key - Verhindert, dass qmake den MD5-Projektschlüssel zwischenspeichert (nur Mac).
• no_pbx_xcode - deaktiviert die XCode-Unterstützung (nur Mac).
• no_smart_library_merge, no_lflags_merge - Verhindert das Entfernen doppelter Einträge in Linker-Flags (nur *nix).
• no_zero_link - Deaktiviert die "Zero-Link"-Funktion von GCC (nur Mac).
• object_parallel_to_source - stellt den ursprünglichen Ordnerbaum für Objektdateien wieder her (ersetzt object_with_source).
• object_with_source - gibt jede Objektdatei in dasselbe Verzeichnis wie ihre Quelldatei aus (in neueren Versionen durch object_parallel_to_source ersetzt).
• rpath_libdirs - Fügt QMAKE_LFLAGS_RPATH zu Link-Flags hinzu (nur *nix).
• geordnet - stellt sicher, dass die Projekte in der angegebenen Reihenfolge erstellt werden.
• static_and_shared - generiert Makefiles für statische und gemeinsam genutzte Builds. Beachten Sie, dass shared_and_static ignoriert wird. Erstellt ein Haupt-Makefile namens $$MAKEFILE (Standard-Makefile) und untergeordnete Makefiles namens $$MAKEFILE.StaticRelease und $$MAKEFILE.SharedRelease, wenn CONFIG Release enthält (Standard für Unix-Plattformen), oder $$MAKEFILE .StaticDebug und $$MAKEFILE.SharedDebug wenn CONFIG debug enthält (Standard für win32), oder beides, wenn CONFIG debug_and_release enthält (insgesamt fünf Makefiles). Das primäre Makefile enthält einen Satz von {statischen, gemeinsam genutzten} {debug, release}[-xxx]-Zielen, die sekundären Makefiles entsprechen, die verwendet werden können, um die entsprechenden Makefile-Regeln aufzurufen. Die primären Standardziele (sowie Installation und Entfernung) haben jedoch nur eine Vorbedingung (standardmäßig wird nur eine Bibliotheksdatei erstellt), abhängig von der aktiven KONFIG: static-release, static-debug, shared-release oder shared- debuggen; fügen Sie static oder shared zu CONFIG hinzu, zusätzlich zu static_and_shared, und release oder debug, zusätzlich zu debug_and_release, damit qmake das geeignete Ziel für die erste Zielvoraussetzung auswählt.

Es gibt auch einige Werte, die qmake dynamisch in CONFIG setzt, wenn es ein Makefile schreibt (und nicht beim Schreiben von XCode-Projektdateien), außer dem Haupt-Makefile - d.h. zusätzliche Hilfs-Makefiles, wenn debug_and_release und/oder static_and_shared gesetzt sind:

• build_pass - Ein Hilfs-Makefile wird geschrieben (build_pass wird nicht gesetzt, wenn das Haupt-Makefile geschrieben wird).
• Debug und DebugBuild - wenn debug_and_release gesetzt ist und die Makefile-Erweiterung "Debug" enthält.
• Release und ReleaseBuild - wenn debug_and_release gesetzt ist und die Makefile-Dateinamenerweiterung "Release" enthält.
• Static und StaticBuild - wenn static_and_shared gesetzt ist und die Makefile-Dateinamenerweiterung "Static" enthält.
• Shared und SharedBuild - wenn static_and_shared gesetzt ist und die Makefile-Erweiterung "Shared" enthält.

Wenn debug_and_release und static_and_shared verwendet werden, werden zusätzlich zu build_pass alle vier Kombinationen von Debug / Release und Static / Shared hinzugefügt.

Indem Sie diese Werte im build_pass-Bereich überprüfen, können Sie den Inhalt des Makefiles entsprechend anpassen. Wenn Ihr Quellcode beispielsweise Debug-Ausgabeabschnitte enthält, die von der Definition des Präprozessormakros DEBUG_SECTION abhängig sind, können Sie mit der folgenden qmake-Syntax den Wert des Makros zur Kompilierzeit bestimmen:

build_pass: DebugBuild {
    # Provide compile-time DEBUG_SECTION.
    DEFINES += DEBUG_SECTION=$(DEBUG_SECTION)
    # Provide console output on MS/Windows.
    win32: CONFIG += console
    }

Nach dem Ausführen von qmake mit einer .pro-Datei, die das Obige enthält, kann ein Entwickler eine Debug-Version des Codes wie folgt erstellen:

make DEBUG_SECTION=ENABLED_SECTION debug

Hier ist ENABLED_SECTION das im Quellcode definierte Symbol zur Ausgabe des zu aktivierenden Debug-Abschnitts. Shared-Debug- und/oder Static-Debug-Ziele müssen angegeben werden, wenn static_and_shared in der CONFIG-Liste festgelegt wurde.

Außerdem gibt es mehrere Werte mit undefiniertem Wert:

• Explicitlib - Wert nicht gesetzt,
• no_delete_multiple_files - bezogen auf benutzerdefinierte Ziele und "Make clean",
• no_fixpath - Ändert, wie qmake Dateipfade relativ ändert (obwohl nicht genau klar ist, wie),
• subdir_first_pro, cd_change_global - beziehen sich auf Projekte, die die SUBDIRS-Vorlage verwenden.

Ein weiterer interessanter Wert für diejenigen, die genug von langen Kompilierungsprotokollen haben:

*silent - das generierte Makefile verwendet den "echo"-Befehl, um Zeilen wie "compiling x.cpp", "moc xh", "linking x.exe" auszugeben.

Verwenden Sie für Aufrufe keine temporäre Datei, die z. B. Befehlszeilen-Flags enthält. Compiler oder Linker (@C:\TEMP\nm1234.tmp), aber schreiben Sie alles direkt in die Befehlszeile (nmake-spezifisch). Nützlich für reproduzierbare Build-Logs:

• no_batch -? (Als Win32 NMAKE)

Ein weiteres interessantes Merkmal von qmake, zumindest seit Qt4, ist, dass es einen (undokumentierten) "config"-Schalter hat, der den Wert der CONFIG-Variablen zur Laufzeit ändert, ohne den Inhalt der verarbeiteten Datei zu ändern. Dies ist besonders nützlich, um Build-Ziele zu ersetzen. Tatsächlich kann qmake keine anderen Build-Targets als die klassischen 'release', 'debug', 'clean' und 'install' generieren. Da die CONFIG-Variable beim Auflösen von Bereichen überprüft wird, können Sie eine komplexe, zielbasierte Projektstruktur erstellen, die für Menschen lesbar bleibt.

#sample project

TARGET = sample
TEMPLATE = app

SOURCES += main.cpp someclass.cpp
HEADERS += someclass.h

target_one {
    DEFINES += _BUILD_ONE_
    SOURCES += someclass_one.cpp
    HEADERS += someclass_one.h
}

target_two {
    DEFINES += _BUILD_TWO_
    SOURCES += someclass_two.cpp
    HEADERS += someclass_two.h
}

Das obige Projekt wird 4 mögliche Ausgänge haben:

• einfache Anwendung mit nur "someclass" implementiert
• Dieselbe Anwendung, aber mit hinzugefügtem someclass_one, die Makefile-Generierung erfolgt mit dem folgenden Befehl:

qmake -config target_one

• Dieselbe Anwendung, aber mit hinzugefügtem someclass_two, Makefile-Generierung erfolgt mit dem folgenden Befehl:

qmake -config target_two

• Dieselbe Anwendung, aber mit hinzugefügten optionalen Klassen, die Makefile-Generierung erfolgt mit dem folgenden Befehl:

qmake -config "target_one target_two"

Dieser Trick wird von Edyuk verwendet, damit das .pro-Format so leistungsfähig wird wie bekannte Standards wie .cbp, das von Code::Blocks verwendet wird, und *.vcproj, das von MSVC verwendet wird.

Installation mit benutzerdefinierter Konfiguration

Die folgenden undokumentierten Schalter können der .CONFIG-Eigenschaft eines benutzerdefinierten Installationsziels (d. h. myInstallTarget.CONFIG) hinzugefügt werden. Das Ziel ist das benutzerdefinierte Installationsziel, wenn es zur Liste INSTALLS hinzugefügt wurde. Es sollte beachtet werden, dass "Ziel" auch als benutzerdefiniertes Installationsziel gilt, wenn seine Eigenschaft .files explizit in der Projektdatei definiert wurde.

• no_check_exist - Erzeugt ein Installationsziel, selbst wenn die zu installierenden Dateien zum Zeitpunkt der Ausführung von qmake nicht existieren.

Korrektur: Es gibt zwei Formen, die qmake verwenden kann, um Dateien zu installieren: INSTALL_FILE und INSTALL_DIR. Wenn ein vorhandenes Verzeichnis installiert wird und no_check_exist nicht angewendet wird, wird die Form INSTALL_DIR verwendet. Wenn das Verzeichnis jedoch nicht existiert, wenn qmake ausgeführt wird (z. B. ein Unterverzeichnis mit Dokumentationsdateien, die während make erstellt werden) und no_check_exist verwendet wird, wird die Form INSTALL_FILE verwendet, die auf Unix-Systemen während make fehlschlägt. Um dies zu verhindern, darf no_check_exist nicht verwendet werden und es muss beim Ausführen von qmake ein leeres Verzeichnis mit dem angegebenen Namen erstellt werden. Verwenden Sie dazu die "system"-Funktion von qmake mit dem entsprechenden Befehl (es wäre "mkdir -p" auf Unix-Systemen; nur mkdir auf Windows) und einem Verzeichnispfad (der Pfad muss durch das Hostsystem begrenzt werden).

SUBDIRS-Projekte

SUBDIRS ist eine leistungsstarke Methode, um Projekte in kleinere Stücke zu zerlegen. Obwohl es tatsächlich viel leistungsfähiger ist als in der Dokumentation angegeben.

Es gibt drei mögliche Werte für die Variable SUBDIRS. Sie können Verzeichnisse sein, wie im Handbuch angegeben, in diesem Fall sucht qmake nach einer .pro-Datei mit demselben Namen wie das Verzeichnis. Es kann auch eine .pro-Datei sein, mit oder ohne Pfad, in diesem Fall wird direkt zu dieser Datei gewechselt. Oder es könnte höchstwahrscheinlich eine Variable sein. In diesem Fall können Sie das Verhalten mit zusammengesetzten Variablen mithilfe der folgenden Schlüsselwörter anpassen:

• subdir - Pfad zur .pro-Datei. Das Programm verhält sich so, als ob Sie gerade ein Verzeichnis angegeben hätten.
• Datei - die .pro-Datei selbst. Das Programm verhält sich so, als ob Sie den vollständigen Pfad und Dateinamen angegeben hätten.
• abhängig - Liste anderer SUBDIRS-Einträge, von denen dieser Eintrag abhängt.
• Makefile - Dies scheint den Namen des Makefiles festzulegen, das zu diesem Zweck generiert und aufgerufen wird.
• Ziel - Dies legt das Ziel im aufzurufenden Makefile fest. (Wahrscheinlich am nützlichsten in Kombination mit der Option "makefile".)

Zum Beispiel:

TEMPLATE = subdirs
SUBDIRS = sub_lib sub_tests sub_app

sub_lib.subdir = lib
sub_tests.file = tests/proj.pro
sub_tests.depends = sub_lib
sub_app.subdir = app
sub_app.depends = sub_lib

Auf diese Weise können Sie make -j 4 auf Ihrem ausgefallenen Quad-Core-System mit einem Projekt verwenden, das mehrere Komponenten enthält, die voneinander abhängen. Um den Vorgang etwas zu vereinfachen, können Sie die folgende Testfunktion definieren:

# addSubdirs(subdirs,deps): Adds directories to the project that depend on
# other directories
defineTest(addSubdirs) {
    for(subdirs, 1) {
        entries = $$files($$subdirs)
        for(entry, entries) {
            name = $$replace(entry, [/\\\\], _)
            SUBDIRS += $$name
            eval ($${name}.subdir = $$entry)
            for(dep, 2):eval ($${name}.depends += $$replace(dep, [/\\\\], _))
            export ($${name}.subdir)
            export ($${name}.depends)
        }
    }
    export (SUBDIRS)
}

Sie können es wie folgt verwenden:

addSubdirs (contrib/*)

addSubdirs (src/lib/kernel, contrib/module1 contrib/module2)
addSubdirs (src/lib/gui, src/lib/kernel contrib/module3 contrib/module4)

addSubdirs (src/tests/kernel, src/lib/kernel)
addSubdirs (src/tests/gui, src/lib/gui)

addSubdirs (src/main, src/lib/gui src/lib/kernel)

addSubdirs (src/modules/*, src/lib/kernel)

Projekt mit:

• mehrere Module, die zuerst kompiliert werden müssen;
• Kernel-Bibliothek für Nicht-GUI-Zeug, das von einigen Contrib-Modulen abhängt;
• eine GUI-Bibliothek, die von der Kernel-Bibliothek und einigen anderen contrib-Modulen abhängt;
• Testbenches für Kernel und GUI-Bibliotheken;
• das Hauptprogramm, das die GUI- und Kernel-Bibliotheken verwendet;
• mehrere Module, die nur von der Kernbibliothek abhängen;
• wird nach Möglichkeit parallel kompiliert.

Undokumentierte Modi

Zusätzlich zu den bekannten „-project“- und „-makefile“-Modi unterstützt qmake mehrere andere Optionen, die es in verschiedene Modi ändern können.

• -prl schaltet es in den "prl-Generierungsmodus". Es ist nicht klar, was das bedeutet, aber es hängt sicherlich mit den .prl-Dateien zusammen, die im Verzeichnis $QTDIR/libs vorhanden sind;
• -set und -query schaltet in den "Eigenschaftenmodus". Dann kann qmake Ihnen die Werte einiger spezifischer Qt-Variablen geben, die zur Build-Zeit fest codiert sind. Darüber hinaus können vom Benutzer ausgewählte Eigenschaften ermittelt und abgefragt werden. Diese Werte können von einer Qt-Anwendung über QLibraryInfo abgerufen werden, aber der Schalter qmake informiert Shell-Skripte darüber.

Eingebaute Eigenschaftswerte:

• QMAKE_MKSPECS
• QMAKE_VERSION
• QT_INSTALL_BINS
• QT_INSTALL_CONFIGURATION
• QT_INSTALL_DATA
• QT_INSTALL_DEMOS
• QT_INSTALL_DOCS
• QT_INSTALL_EXAMPLES
• QT_INSTALL_HEADERS
• QT_INSTALL_LIBS
• QT_INSTALL_PLUGINS
• QT_INSTALL_PREFIX
• QT_INSTALL_QML
• QT_INSTALL_TRANSLATIONS
• QT_VERSION

Wenn beispielsweise Qt 4.1.3 unter /usr/local/Trolltech/Qt-4.1.3 (Standard) installiert ist:

$ qmake -query QT_VERSION
4.1.3

$ qmake -query QT_INSTALL_PREFIX
/usr/local/Trolltech/Qt-4.1.3

Benutzerdefinierte Eigenschaften gelten global für das System – sie gelten nicht für einzelne Projekte. Unter Win32 werden sie in der Registrierung unter HKEY_CURRENT_USER\Software\Trolltech\QMake\2.00a gespeichert.

Sie können die Werte dieser Variablen auch mit $$[varname] abrufen (beachten Sie die Verwendung von eckigen Klammern).

Undokumentierte Funktionen

Es gibt einige sehr praktische Funktionen, die nicht in der Qt4-Dokumentation enthalten sind. Einige davon wurden erst mit Qt 4.2 hinzugefügt, seien Sie also vorsichtig.

Programmablauffunktionen

Für qmake sind dies Testfunktionen, die in einen eigenen Abschnitt gehören:

• break() - verhält sich wie die C break-Anweisung.
• debug (level, msg) - gibt eine Nachricht an das qmake-Debug-Log aus (aktiviert mit der Option -d). Die Option "level" gibt die Anzahl der -d-Optionen an, die angegeben werden müssen, um diese Meldung anzuzeigen.
• clear (var) - Initialisiert eine zu löschende Variable.
• export (var) - Beim Schreiben einer benutzerdefinierten Funktion sind die deklarierten Variablen lokal für die Funktion. Um dem aufrufenden Kontext eine Variable zur Verfügung zu stellen, verwenden Sie export(var).
  *next() - Verhält sich wie eine C-Continue-Anweisung.
• unset (var) - entfernt die Variable vollständig (sie verhält sich so, als wäre sie nie gesetzt worden).

Ersetzen einer Funktion

Diese Funktionen geben einen Wert zurück:

• files (glob) – Gibt eine Liste von Dateien zurück, die mit dem angegebenen Glob-Muster übereinstimmen.
  Eigentlich ist diese Funktion als Testfunktion dokumentiert.

Undokumentierte Feinheiten

Qmake ist ein wirklich mächtiges Werkzeug, wenn Sie sich darüber noch nicht sicher sind, werfen Sie einen Blick darauf: Geltungsbereiche können verschachtelt, aber auch mit logischen Operatoren kombiniert werden. Die folgenden Zeilen sind gleichwertig:

win32|unix {
    VAR += value
}

win32 {
    VAR += value
}

unix {
    VAR += value
}

Der Platzhalter kann fast überall verwendet werden: Bereiche, Werte und so weiter.

win32-msvc* {
    # same as win32-msvc|win32-mscv.net
}

TEXTS += *.txt

Bestimmen, ob ein statischer Build von Qt verwendet wird:

qtConfig(static) {
 # this is a static build
}