Variablen

Das grundlegende Verhalten von qmake wird durch Variablendeklarationen beeinflusst, die den Build-Prozess jedes Projekts definieren. Einige davon deklarieren Ressourcen wie Header- und Quelldateien, die für alle Plattformen gleich sind. Andere dienen dazu, das Verhalten von Compilern und Linkern auf bestimmten Plattformen anzupassen.

Plattformspezifische Variablen folgen dem Namensmuster der Variablen, die sie erweitern oder modifizieren, enthalten jedoch den Namen der jeweiligen Plattform in ihrem Namen. Beispielsweise kann eine „makespec“ die Variable „ QMAKE_LIBS “ verwenden, um eine Liste von Bibliotheken anzugeben, gegen die jedes Projekt verlinkt werden muss, und „ QMAKE_LIBS_X11 “ würde verwendet werden, um diese Liste zu erweitern.

ANDROID_ABIS

Gibt eine Liste der ABIs für Android-Ziele an. Gültige Werte sind: armeabi-v7a, arm64-v8a, x86, x86_64.

Sie können die ABIs als qmake-Argument angeben:

qmake ANDROID_ABIS="armeabi-v7a arm64-v8a"

ANDROID_API_VERSION

Gibt die Nummer der Android-API-Stufe an. Weitere Informationen finden Sie unter Android-Build-Nummern.

ANDROID_APPLICATION_ARGUMENTS

Gibt zusätzliche Befehlszeilenargumente für die Android-App an, die über die „ AndroidManifest.xml “ mit dem Tag „android.app.arguments“ verwendet werden. Hierfür wird eine Zeichenfolge mit Argumenten übergeben:

ANDROID_APPLICATION_ARGUMENTS = "arg1 arg2 arg3"

ANDROID_BUNDLED_JAR_DEPENDENCIES

Dies ist beim Schreiben eines Qt-Moduls nützlich. Sie gibt eine Liste der vom Modul verwendeten, vorab gebündelten Abhängigkeiten im Format „ .jar “ an, zum Beispiel:

ANDROID_BUNDLED_JAR_DEPENDENCIES += jar/Qt6Android.jar

ANDROID_DEPLOYMENT_DEPENDENCIES

Standardmäßig erkennt „androiddeployqt“ die Abhängigkeiten Ihrer Anwendung. Da jedoch die Nutzung von Plugins zur Laufzeit nicht erkannt werden kann, kann es zu Fehlalarmen kommen, da Ihre Anwendung möglicherweise von jedem Plugin abhängt, das eine potenzielle Abhängigkeit darstellt. Wenn Sie die Größe Ihrer ` APK` minimieren möchten, können Sie die automatische Erkennung mithilfe dieser Variablen überschreiben. Diese sollte eine Liste aller Qt-Dateien enthalten, die eingebunden werden müssen, wobei die Pfade relativ zum Qt-Installationsstammverzeichnis angegeben werden.

ANDROID_DEPLOYMENT_SETTINGS_FILE

Gibt den Pfad zur Datei „ android-deployment-settings.json “ an, die von „androiddeployqt“ und „ androidtestrunner “ benötigt wird. Dies überschreibt den von „qmake“ generierten Pfad zur Einstellungsdatei; daher müssen Sie sicherstellen, dass Sie eine gültige Einstellungsdatei bereitstellen.

ANDROID_EXTRA_LIBS

Eine Liste externer Bibliotheken, die in den Ordner „ libs “ Ihrer Anwendung kopiert und beim Start geladen werden. Dies kann beispielsweise verwendet werden, um OpenSSL in Ihrer Anwendung zu aktivieren. Weitere Informationen finden Sie unter „OpenSSL-Unterstützung für Android hinzufügen“.

Um externe Bibliotheken für mehrere ABIs einzubinden, wobei jede ABI über ein eigenes Verzeichnis verfügt, verwenden Sie Folgendes:

for (abi, ANDROID_ABIS): ANDROID_EXTRA_LIBS += $$PWD/$${abi}/library_name.so

Andernfalls, wenn die ABI im Bibliotheksnamen enthalten ist, verwenden Sie Folgendes:

for (abi, ANDROID_ABIS): ANDROID_EXTRA_LIBS += $$PWD/library_name_$${abi}.so

ANDROID_EXTRA_PLUGINS

Gibt einen Pfad zu C++-Plugins oder Ressourcen an, die Ihre Anwendung bündeln muss, die aber nicht über das Assets-System bereitgestellt werden können, wie beispielsweise QML-Plugins. Mit dieser Variablen stellt „androiddeployqt“ sicher, dass alles ordnungsgemäß gepackt und bereitgestellt wird.

ANDROID_EXTRA_PLUGINS muss auf das Verzeichnis verweisen, in dem die zusätzlichen Plugins erstellt wurden. Außerdem muss die Verzeichnisstruktur des Builds einer Namenskonvention folgen, die der von Qt-Plugins ähnelt, d. h. plugins/<Plugin-Name>.

Die Plugin-Bibliotheken sollten das Namensformat libplugins_<Typ>_<Name>_<abi>.so haben. Um dies zu erreichen, könnte die Plugin-Pro-Datei wie folgt definiert werden:

TEMPLATE = lib
CONFIG += plugin

PLUGIN_TYPE = imageformats
DESTDIR = $$top_builddir/plugins/myplugin
TARGET = $$qt5LibraryTarget(myplugin, "plugins/$$PLUGIN_TYPE/")

wobei `top_builddir` in `.qmake.conf` wie folgt definiert ist:

top_builddir=$$shadowed($$PWD)

Dadurch wird sichergestellt, dass die richtige Namensumwandlung auf die Plugin-Bibliothek angewendet wird (plugins/myplugin/libplugins_imageformats_myplugin_armeabi-v7a.so).

Angenommen, ein zusätzliches Bildformat-Plugin „myplugin“ wird unter $$DESTDIR/plugins/myplugin/ erstellt, dann stellt Folgendes sicher, dass es korrekt verpackt wird:

ANDROID_EXTRA_PLUGINS += $$top_builddir/plugins

ANDROID_FEATURES

Legt die Liste der Funktionen eines Moduls fest:

ANDROID_FEATURES += android.hardware.location.gps

Weitere Informationen finden Sie in der Android-Dokumentation zu <uses-feature>.

ANDROID_LIB_DEPENDENCIES

Dies ist beim Erstellen eines Qt-Moduls hilfreich. Sie gibt eine Liste der vom Modul verwendeten vorgefertigten Abhängigkeiten an, zum Beispiel:

ANDROID_LIB_DEPENDENCIES += \
    plugins/libplugins_platforms_qtforandroid.so

ANDROID_MIN_SDK_VERSION

Gibt die minimale Android-API-Stufe für das Projekt an. Standardmäßig ist diese Variable auf API-Stufe 23 gesetzt.

ANDROID_PACKAGE_SOURCE_DIR

Gibt den Pfad für eine benutzerdefinierte Android-Paketvorlage an. Die Android-Paketvorlage enthält:

• die Datei „AndroidManifest.xml“
• Datei „build.gradle“ und weitere Gradle-Skripte
• Datei „res/values/libs.xml“

Der durch diese Variable angegebene Pfad kann benutzerdefinierte Java-Klassen im Verzeichnis „ src “ enthalten. Standardmäßig kopiert das Tool „androiddeployqt“ die Anwendungsvorlage aus dem Installationspfad von „Qt for Android“ in das Build-Verzeichnis Ihres Projekts und fügt anschließend den Inhalt des durch diese Variable angegebenen Pfads hinzu, wobei bereits vorhandene Dateien überschrieben werden. Sie können beispielsweise eine benutzerdefinierte Datei „ AndroidManifest.xml “ für Ihre Anwendung erstellen und diese dann direkt in das durch diese Variable angegebene Verzeichnis kopieren.

ANDROID_PERMISSIONS

Gibt die Berechtigungsliste eines Moduls an:

ANDROID_PERMISSIONS += android.permission.ACCESS_FINE_LOCATION

Weitere Informationen finden Sie in der Android-Dokumentation zu <uses-permission>.

ANDROID_TARGET_SDK_VERSION

Legt die Ziel-Android-API-Stufe für das Projekt fest. Standardmäßig ist diese Variable auf API-Stufe 37 gesetzt.

ANDROID_VERSION_CODE

Gibt die Versionsnummer der Anwendung an. Weitere Informationen finden Sie unter „Android-App-Versionierung“.

ANDROID_VERSION_NAME

Gibt die Version der Anwendung als für Menschen lesbare Zeichenfolge an. Weitere Informationen finden Sie unter „Android-App-Versionierung“.

CONFIG

Gibt Projektkonfigurations- und Compiler-Optionen an. Die Werte werden intern von qmake erkannt und haben eine besondere Bedeutung.

Die folgenden „ CONFIG “-Werte steuern Compiler- und Linker-Flags:

Wenn Sie die Option „ debug_and_release “ verwenden (was unter Windows die Standardeinstellung ist), wird das Projekt dreimal verarbeitet: einmal zur Erstellung eines „Meta“-Makefiles und zweimal zur Erstellung eines „Makefile.Debug“ sowie eines „Makefile.Release“.

Während der letztgenannten Durchläufe werden „ build_pass “ sowie die jeweilige Option „ debug “ oder „ release “ an „ CONFIG “ angehängt. Dies ermöglicht die Ausführung von buildspezifischen Aufgaben. Zum Beispiel:

build_pass:CONFIG(debug, debug|release) {
    unix: TARGET = $$join(TARGET,,,_debug)
    else: TARGET = $$join(TARGET,,,d)
}

Als Alternative zum manuellen Schreiben von Bedingungen für den Build-Typ bieten einige Variablen buildspezifische Varianten an, zum Beispiel `QMAKE_LFLAGS_RELEASE ` zusätzlich zur allgemeinen ` QMAKE_LFLAGS`. Diese sollten verwendet werden, sofern sie verfügbar sind.

Das Meta-Makefile macht die Teil-Builds über die Ziele „ debug “ und „ release “ aufrufbar und einen kombinierten Build über das Ziel „ all “. Wenn die Option „ build_all “ CONFIG verwendet wird, ist der kombinierte Build die Standardeinstellung. Andernfalls bestimmt die zuletzt angegebene Option „ CONFIG “ aus der Gruppe (debug, release) die Standardeinstellung. In diesem Fall können Sie das Ziel „ all “ explizit aufrufen, um beide Konfigurationen gleichzeitig zu erstellen:

make all

Beim Verknüpfen einer Bibliothek verlässt sich qmake darauf, dass die zugrunde liegende Plattform weiß, mit welchen anderen Bibliotheken diese Bibliothek verknüpft ist. Bei einer statischen Verknüpfung erhält qmake diese Informationen jedoch nur, wenn wir die folgenden „ CONFIG “-Optionen verwenden:

Die folgenden Optionen definieren den Anwendungs- oder Bibliothekstyp:

Diese Optionen definieren spezifische Funktionen, die nur unter Windows verfügbar sind:

Weitere Informationen zu den Optionen zum Einbetten von Manifestdateien finden Sie in den Plattformhinweisen.

Die folgenden Optionen wirken sich nur unter macOS aus:

Der Erstellungsprozess für Bundles wird zudem durch den Inhalt der Variablen QMAKE_BUNDLE_DATA beeinflusst.

Die folgenden Optionen wirken sich nur auf Linux-/Unix-Plattformen aus:

Die Variable „ CONFIG “ wird ebenfalls beim Auflösen von Gültigkeitsbereichen überprüft. Sie können dieser Variable einen beliebigen Wert zuweisen.

Beispiel:

CONFIG += console newstuff
...
newstuff {
    SOURCES += new.cpp
    HEADERS += new.h
}

DEFINES

qmake fügt die Werte dieser Variable als C-Präprozessor-Makros des Compilers hinzu (Option -D).

Beispiel:

DEFINES += USE_MY_STUFF

DEFINES_DEBUG

Legt Präprozessor-Definitionen für die Debug-Konfiguration fest. Die Werte dieser Variablen werden nach dem Laden des Projekts zu DEFINES hinzugefügt. Diese Variable wird in der Regel in qmake.conf festgelegt und muss nur selten geändert werden.

Diese Variable wurde in Qt 5.13.2 eingeführt.

DEFINES_RELEASE

Legt Präprozessor-Definitionen für die Release-Konfiguration fest. Die Werte dieser Variablen werden nach dem Laden des Projekts zu DEFINES hinzugefügt. Diese Variable wird in der Regel in der Datei „qmake.conf“ festgelegt und muss nur selten geändert werden.

Diese Variable wurde in Qt 5.13.2 eingeführt.

DEF_FILE

Gibt eine „ .def “-Datei an, die in das Projekt eingebunden werden soll.

DEPENDPATH

Gibt eine Liste von Verzeichnissen an, die qmake durchsuchen soll, um Abhängigkeiten aufzulösen. Diese Variable wird verwendet, wenn qmake die Header-Dateien durchforstet, die Sie in Ihrem Quellcode mit „ #include “ einbinden.

DESTDIR

Gibt an, wo die Zieldatei abgelegt werden soll.

Beispiel:

DESTDIR = ../../lib

DISTFILES

Gibt eine Liste von Dateien an, die in das „dist“-Ziel aufgenommen werden sollen. Diese Funktion wird nur von UnixMake-Spezifikationen unterstützt.

Beispiel:

DISTFILES += ../program.txt

DLLDESTDIR

Gibt an, wohin die Ziel -DLL kopiert werden soll.

EXTRA_TRANSLATIONS

Gibt eine Liste von Übersetzungsdateien (.ts) an, die Übersetzungen des Benutzeroberflächentextes in andere Sprachen enthalten.

Im Gegensatz zu TRANSLATIONS werden Übersetzungsdateien im Verzeichnis „ EXTRA_TRANSLATIONS “ nur von lrelease verarbeitet, nicht von lupdate.

Sie können CONFIG += lrelease verwenden, um die Dateien während des Builds automatisch zu kompilieren, und CONFIG += lrelease embed_translations, um sie im Qt-Ressourcensystem verfügbar zu machen.

Weitere Informationen zur Internationalisierung (i18n) und Lokalisierung (l10n) mit Qt finden Sie im Handbuch zu „Qt Linguist “.

FORMS

Gibt die UI-Dateien an (siehe Handbuch zum „Qt Widgets Designer“), die vor der Kompilierung von „ uic “ verarbeitet werden sollen. Alle Abhängigkeiten, Header- und Quelldateien, die zum Erstellen dieser UI-Dateien erforderlich sind, werden dem Projekt automatisch hinzugefügt.

Beispiel:

FORMS = mydialog.ui \
    mywidget.ui \
        myconfig.ui

GUID

Gibt die GUID an, die in einer „ .vcproj “-Datei festgelegt wird. Die GUID wird in der Regel zufällig generiert. Sollten Sie jedoch eine feste GUID benötigen, kann diese über diese Variable festgelegt werden.

Diese Variable gilt ausschließlich für „ .vcproj “-Dateien; in anderen Fällen wird sie ignoriert.

HEADERS

Definiert die Header-Dateien für das Projekt.

qmake erkennt automatisch, ob moc für die Klassen in den Header-Dateien benötigt wird, und fügt dem Projekt die entsprechenden Abhängigkeiten und Dateien hinzu, um die moc-Dateien zu generieren und zu verknüpfen.

Beispiel:

HEADERS = myclass.h \
          login.h \
          mainwindow.h

Siehe auch SOURCES.

ICON

Diese Variable wird nur unter Mac OS verwendet, um das Anwendungssymbol festzulegen. Weitere Informationen finden Sie in der Dokumentation zum Anwendungssymbol.

IDLSOURCES

Diese Variable wird ausschließlich unter Windows bei der Erstellung von Visual Studio-Projekten verwendet, um die angegebenen Dateien in den Ordner „Generated Files“ zu kopieren.

INCLUDEPATH

Gibt die #include-Verzeichnisse an, die beim Kompilieren des Projekts durchsucht werden sollen.

Beispiel:

INCLUDEPATH = c:/msdev/include d:/stl/include

Um einen Pfad anzugeben, der Leerzeichen enthält, setzen Sie den Pfad in Anführungszeichen, wie unter „Leerzeichen“ beschrieben.

win32:INCLUDEPATH += "C:/mylibs/extra headers"
unix:INCLUDEPATH += "/home/user/extra headers"

INSTALLS

Gibt eine Liste von Ressourcen an, die bei der Ausführung von „ make install “ oder einem ähnlichen Installationsvorgang installiert werden. Jeder Eintrag in der Liste wird in der Regel mit Attributen definiert, die Angaben zum Installationsort enthalten.

Beispielsweise beschreibt die folgende „ target.path “-Definition, wo das Build-Ziel installiert wird, und die Zuweisung „ INSTALLS “ fügt das Build-Ziel zur Liste der zu installierenden Ressourcen hinzu:

target.path += $$[QT_INSTALL_PLUGINS]/imageformats
INSTALLS += target

INSTALLS verfügt über ein „ .CONFIG “-Element, das verschiedene Werte annehmen kann:

Weitere Informationen finden Sie unter „Dateien installieren“.

Diese Variable wird auch verwendet, um anzugeben, welche zusätzlichen Dateien auf eingebettete Geräte bereitgestellt werden sollen.

JAVA_HOME

Gibt den Installationspfad des JDK/OpenJDK an, der zum Erstellen des Projekts verwendet wird.

LEXIMPLS

Gibt eine Liste von Lex-Implementierungsdateien an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

LEXOBJECTS

Gibt die Namen der Lex-Zwischenobjektdateien an. Der Wert dieser Variablen wird in der Regel von qmake verwaltet und muss nur selten geändert werden.

LEXSOURCES

Gibt eine Liste von Lex-Quelldateien an. Alle Abhängigkeiten, Header- und Quelldateien werden automatisch zum Projekt hinzugefügt, um diese Lex-Dateien zu erstellen.

Beispiel:

LEXSOURCES = lexer.l

LIBS

Gibt eine Liste der Bibliotheken an, die in das Projekt eingebunden werden sollen. Wenn Sie die Unix-Flags „ -l “ (Bibliothek) und „-L“ (Bibliothekspfad) verwenden, behandelt qmake die Bibliotheken unter Windows korrekt (d. h., es übergibt den vollständigen Pfad der Bibliothek an den Linker). Die Bibliothek muss vorhanden sein, damit qmake das Verzeichnis finden kann, in dem sich eine „ -l “-Bibliothek befindet.

Beispiel:

unix:LIBS += -L/usr/local/lib -lmath
win32:LIBS += c:/mylibs/math.lib

Um einen Pfad anzugeben, der Leerzeichen enthält, setzen Sie den Pfad in Anführungszeichen, wie unter „Leerzeichen“ beschrieben.

win32:LIBS += "C:/mylibs/extra libs/extra.lib"
unix:LIBS += "-L/home/user/extra libs" -lextra

Standardmäßig wird die in „ LIBS “ gespeicherte Liste der Bibliotheken vor ihrer Verwendung auf eine Liste eindeutiger Namen reduziert. Um dieses Verhalten zu ändern, fügen Sie die Option „ no_lflags_merge “ zur CONFIG-Variablen hinzu:

CONFIG += no_lflags_merge

LIBS_PRIVATE

Gibt eine Liste von Bibliotheken an, die privat in das Projekt eingebunden werden sollen. Das Verhalten dieser Variablen entspricht dem von LIBS, mit der Ausnahme, dass für Unix erstellte Projekte mit gemeinsam genutzten Bibliotheken diese Abhängigkeiten nicht in ihrer Link-Schnittstelle offenlegen.

Dies hat zur Folge: Wenn Projekt C von Bibliothek B abhängt, die wiederum privat von Bibliothek A abhängt, C aber auch Symbole aus A direkt verwenden möchte, muss es explizit mit A verknüpft werden. Anders ausgedrückt: Privat verknüpfte Bibliotheken werden beim Erstellen nicht transitiv offengelegt.

LITERAL_HASH

Diese Variable wird immer dann verwendet, wenn ein Hash-Zeichen (#) in einer Variablendeklaration benötigt wird, beispielsweise als Teil eines Dateinamens oder in einer Zeichenkette, die an eine externe Anwendung übergeben wird.

Beispiel:

# To include a literal hash character, use the $$LITERAL_HASH variable:
urlPieces = http://doc.qt.io/qt-5/qtextdocument.html pageCount
message($$join(urlPieces, $$LITERAL_HASH))

Durch die Verwendung von „ LITERAL_HASH “ auf diese Weise kann das Zeichen „ # “ genutzt werden, um eine URL für die Funktion „ message() “ zu erstellen, die auf der Konsole ausgegeben wird.

MAKEFILE

Gibt den Namen der generierten Makefile-Datei an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

MAKEFILE_GENERATOR

Gibt den Namen des Makefile-Generators an, der beim Erstellen eines Makefiles verwendet werden soll. Der Wert dieser Variablen wird in der Regel intern von qmake verwaltet und muss nur selten geändert werden.

MSVCPROJ_*

Diese Variablen werden intern von qmake verwaltet und sollten weder geändert noch verwendet werden.

MOC_DIR

Gibt das Verzeichnis an, in dem alle temporären moc-Dateien abgelegt werden sollen.

Beispiel:

unix:MOC_DIR = ../myproject/tmp
win32:MOC_DIR = c:/myproject/tmp

OBJECTIVE_HEADERS

Definiert die Objective-C++-Header-Dateien für das Projekt.

qmake erkennt automatisch, ob die Klassen in den Header-Dateien moc erfordern, und fügt dem Projekt die entsprechenden Abhängigkeiten und Dateien hinzu, um die moc-Dateien zu generieren und zu verknüpfen.

Dies ähnelt der Variablen HEADERS, bewirkt jedoch, dass die generierten moc-Dateien mit dem Objective-C++-Compiler kompiliert werden.

Siehe auch OBJECTIVE_SOURCES.

OBJECTIVE_SOURCES

Gibt die Namen aller Objective-C/C++-Quelldateien im Projekt an.

Diese Variable ist mittlerweile veraltet; Objective-C/C++-Dateien (.m und .mm) können der Variable „SOURCES“ hinzugefügt werden.

Siehe auch OBJECTIVE_HEADERS.

OBJECTS

Diese Variable wird automatisch aus der Variable „SOURCES“ gefüllt. Die Erweiterung jeder Quelldatei wird durch „.o“ (Unix) oder „.obj“ (Win32) ersetzt. Sie können Objekte zur Liste hinzufügen.

OBJECTS_DIR

Gibt das Verzeichnis an, in dem alle Zwischenobjekte abgelegt werden sollen.

Beispiel:

unix:OBJECTS_DIR = ../myproject/tmp
win32:OBJECTS_DIR = c:/myproject/tmp

POST_TARGETDEPS

Listet die Bibliotheken auf, von denen das Ziel abhängt. Einige Backends, wie beispielsweise die Generatoren für Visual Studio- und Xcode-Projektdateien, unterstützen diese Variable nicht. Im Allgemeinen wird diese Variable intern von diesen Build-Tools unterstützt und ist nützlich, um abhängige statische Bibliotheken explizit aufzulisten.

Diese Liste wird hinter allen integrierten (und $$PRE_TARGETDEPS) Abhängigkeiten platziert.

PRE_TARGETDEPS

Listet Bibliotheken auf, von denen das Ziel abhängt. Einige Backends, wie beispielsweise die Generatoren für Visual Studio- und Xcode-Projektdateien, unterstützen diese Variable nicht. Im Allgemeinen wird diese Variable intern von diesen Build-Tools unterstützt und ist nützlich, um abhängige statische Bibliotheken explizit aufzulisten.

Diese Liste wird vor allen integrierten Abhängigkeiten eingefügt.

PRECOMPILED_HEADER

Gibt die Header-Datei zur Erstellung einer vorkompilierten Header-Datei an, um die Kompilierungsgeschwindigkeit eines Projekts zu erhöhen. Vorkompilierte Header werden derzeit nur auf einigen Plattformen unterstützt (Windows – alle MSVC-Projekttypen, Apple – Xcode, Makefile, Unix – gcc 3.3 und höher).

PWD

Gibt den vollständigen Pfad zu dem Verzeichnis an, das die aktuell analysierte Datei enthält. Dies kann nützlich sein, um beim Schreiben von Projektdateien auf Dateien innerhalb des Quellbaums zu verweisen und so Shadow-Builds zu unterstützen.

Siehe auch _PRO_FILE_PWD_.

OUT_PWD

Gibt den vollständigen Pfad zu dem Verzeichnis an, in dem qmake die generierte Makefile-Datei ablegt.

QM_FILES_RESOURCE_PREFIX

Gibt das Verzeichnis im Ressourcensystem an, in dem die „ .qm “-Dateien durch „CONFIG += embed_translations“ bereitgestellt werden.

Der Standardwert ist „ :/i18n/ “.

QM_FILES_INSTALL_PATH

Gibt das Zielverzeichnis an, in das die durch `CONFIG += lrelease ` generierten ` .qm `-Dateien installiert werden. Hat keine Auswirkung, wenn `CONFIG += embed_translations ` gesetzt ist.

QML_IMPORT_PATH

Diese Variable wird nur von Qt Creator. Wenn Sie über ein zusätzliches Modul verfügen, das außerhalb Ihrer Qt-Installation gespeichert ist, können Sie dessen Pfad hier angeben.

Weitere Informationen finden Sie unter Qt Creator: Verwendung von QML-Modulen mit Plugins.

QMLPATHS

Erwartet eine Liste von Importpfaden, die auf die Stammverzeichnisse von Verzeichnisbäumen mit QML-Modulen verweisen. Wenn Sie beispielsweise einen benutzerdefinierten Speicherort für Ihre QML-Module haben, können Sie diesen hier angeben.

QMAKE

Gibt den Namen des qmake-Programms selbst an und wird in generierte Makefiles eingefügt. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKESPEC

Eine Systemvariable, die den vollständigen Pfad der qmake-Konfiguration enthält, die bei der Erstellung von Makefiles verwendet wird. Der Wert dieser Variablen wird automatisch berechnet.

QMAKE_APPLE_DEVICE_ARCHS

Gibt eine Liste der Architekturen an, für die kompiliert werden soll. Standardmäßig wird ein Projekt für die Architektur des Entwicklungsrechners kompiliert. Mit dieser Variablen kann die Standardeinstellung überschrieben und für eine andere Architektur kompiliert werden oder es können Binärdateien für mehrere Architekturen erstellt werden.

Diese Variable wird in der Regel über die Befehlszeile oder in der Projektdatei angegeben.

Weitere Informationen finden Sie unter Qt für macOS.

QMAKE_AR_CMD

Gibt den Befehl an, der beim Erstellen einer gemeinsam genutzten Bibliothek ausgeführt werden soll. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_BUNDLE_DATA

Gibt die Daten an, die zusammen mit einem Bibliotheksbündel installiert werden sollen, und wird häufig verwendet, um eine Sammlung von Header-Dateien anzugeben.

Die folgenden Zeilen fügen beispielsweise „ path/to/header_one.h “ und „ path/to/header_two.h “ zu einer Gruppe hinzu, die Informationen zu den mit dem Framework bereitgestellten Header-Dateien enthält:

FRAMEWORK_HEADERS.version = Versions
FRAMEWORK_HEADERS.files = path/to/header_one.h path/to/header_two.h
FRAMEWORK_HEADERS.path = Headers
QMAKE_BUNDLE_DATA += FRAMEWORK_HEADERS

Die letzte Zeile fügt die Informationen zu den Header-Dateien zur Sammlung der Ressourcen hinzu, die zusammen mit dem Bibliotheksbündel installiert werden.

Bibliotheksbündel werden erstellt, wenn die Option „ lib_bundle “ zur Variablen CONFIG hinzugefügt wird.

Weitere Informationen zum Erstellen von Bibliotheksbündeln finden Sie in den Plattformhinweisen.

Ein Projekt kann diese Variable auch verwenden, um Übersetzungsdateien der Anwendung zu bündeln. Die genaue Syntax hängt davon ab, ob das Projekt das alte Build-System von Xcode oder das neue Build-System verwendet.

Beispielsweise, wenn der folgende Projektauszug mit dem alten Build-System erstellt wird:

translations_en.files = $$PWD/en.lproj/InfoPlist.strings
translations_en.path = en.lproj
QMAKE_BUNDLE_DATA += translations_en

Xcode ignoriert den ursprünglichen Speicherort von ` InfoPlist.strings ` und die Datei wird im Bundle-Verzeichnis ` Resources ` unter dem angegebenen Pfad ` translations_en.path ` abgelegt, sodass Resources/en.lproj/InfoPlist.strings

Beim neuen Build-System bleibt der relative Speicherort der Datei erhalten, was bedeutet, dass die Datei fälschlicherweise unter Resources/en.lproj/en.lproj/InfoPlist.strings

Um eine korrekte Platzierung der Datei sicherzustellen, kann das Projekt entweder die ursprüngliche Datei aus dem Unterverzeichnis verschieben oder die Variable ` translations_en.path ` nicht angeben.

# Approach 1
translations_en.files = $$PWD/InfoPlist.strings
translations_en.path = en.lproj

# Approach 2
translations_de.files = $$PWD/de.lproj/InfoPlist.strings

QMAKE_BUNDLE_DATA += translations_en translations_de

Weitere Details dazu, wie sich das Verhalten des Xcode-Build-Systems beim Bündeln von Übersetzungsdateien geändert hat, finden Sie unter QTBUG-98417.

QMAKE_BUNDLE_EXTENSION

Legt die für Bibliotheksbündel zu verwendende Dateiendung fest. Dadurch können Frameworks mit benutzerdefinierten Dateiendungen anstelle der standardmäßigen Verzeichnisnamenserweiterung „ .framework “ erstellt werden.

Die folgende Definition führt beispielsweise zu einem Framework mit der Erweiterung „ .myframework “:

QMAKE_BUNDLE_EXTENSION = .myframework

QMAKE_CC

Legt den C-Compiler fest, der beim Erstellen von Projekten mit C-Quellcode verwendet wird. Es muss lediglich der Dateiname der ausführbaren Compiler-Datei angegeben werden, sofern sich diese bei der Verarbeitung der Makefile-Datei in einem Pfad befindet, der in der Variablen „ PATH “ enthalten ist.

QMAKE_CFLAGS

Legt die C-Compiler-Flags für den Bau eines Projekts fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden. Die spezifischen Flags für den Debug- und den Release-Modus können durch Ändern der Variablen „ QMAKE_CFLAGS_DEBUG “ bzw. „ QMAKE_CFLAGS_RELEASE “ angepasst werden.

QMAKE_CFLAGS_DEBUG

Legt die C-Compiler-Flags für Debug-Builds fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CFLAGS_RELEASE

Legt die C-Compiler-Flags für Release-Builds fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO

Legt die C-Compiler-Flagge für Release-Builds fest, bei denen „ force_debug_info “ in „ CONFIG “ gesetzt ist. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CFLAGS_SHLIB

Legt die Compiler-Flags für die Erstellung einer gemeinsam genutzten Bibliothek fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CFLAGS_THREAD

Legt die Compiler-Flags für die Erstellung einer Multithread-Anwendung fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CFLAGS_WARN_OFF

Diese Variable wird nur verwendet, wenn die CONFIG-Option „ warn_off “ gesetzt ist. Der Wert dieser Variable wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CFLAGS_WARN_ON

Diese Variable wird nur verwendet, wenn die CONFIG-Option „ warn_on “ gesetzt ist. Der Wert dieser Variable wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CLEAN

Gibt eine Liste der generierten Dateien (z. B. von moc und uic) und der Objektdateien an, die von „ make clean “ entfernt werden sollen.

QMAKE_CXX

Gibt den C++-Compiler an, der beim Erstellen von Projekten mit C++-Quellcode verwendet wird. Es muss lediglich der Dateiname der ausführbaren Compiler-Datei angegeben werden, sofern sich diese bei der Verarbeitung der Makefile-Datei in einem Pfad befindet, der in der Variablen ` PATH ` enthalten ist.

QMAKE_CXXFLAGS

Legt die C++-Compiler-Flags für die Erstellung eines Projekts fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden. Die spezifischen Flags für den Debug- und den Release-Modus können durch Ändern der Variablen „ QMAKE_CXXFLAGS_DEBUG “ bzw. „ QMAKE_CXXFLAGS_RELEASE “ angepasst werden.

QMAKE_CXXFLAGS_DEBUG

Legt die C++-Compiler-Flags für Debug-Builds fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss selten geändert werden.

QMAKE_CXXFLAGS_RELEASE

Legt die C++-Compiler-Flags für Release-Builds fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO

Legt die C++-Compiler-Flags für Release-Builds fest, bei denen in „ CONFIG “ der Wert „ force_debug_info “ gesetzt ist. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CXXFLAGS_SHLIB

Legt die C++-Compiler-Flags für die Erstellung einer gemeinsam genutzten Bibliothek fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CXXFLAGS_THREAD

Legt die C++-Compiler-Flags für die Erstellung einer multithreaded Anwendung fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CXXFLAGS_WARN_OFF

Legt die C++-Compiler-Flags zur Unterdrückung von Compiler-Warnungen fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_CXXFLAGS_WARN_ON

Legt die C++-Compiler-Flags fest, mit denen Compiler-Warnungen ausgegeben werden. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_DEVELOPMENT_TEAM

Die Kennung eines Entwicklungsteams, die zum Signieren von Zertifikaten und Provisioning-Profilen verwendet wird.

QMAKE_DISTCLEAN

Gibt eine Liste von Dateien an, die von ` make distclean` entfernt werden sollen.

QMAKE_EXTENSION_SHLIB

Enthält die Dateiendung für gemeinsam genutzte Bibliotheken. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_EXTENSION_STATICLIB

Enthält die Dateiendung für gemeinsam genutzte statische Bibliotheken. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_EXT_MOC

Enthält die Dateiendung, die für eingebundene moc-Dateien verwendet wird.

Siehe auch Dateierweiterungen.

QMAKE_EXT_UI

Enthält die Dateiendung, die für UI-Dateien des „ Qt Widgets “ Designers verwendet wird.

Siehe auch „Dateierweiterungen“.

QMAKE_EXT_PRL

Enthält die Dateiendung, die für erstellte PRL-Dateien verwendet wird.

Siehe auch „Dateierweiterungen“, „Bibliotheksabhängigkeiten“.

QMAKE_EXT_LEX

Enthält die Dateiendung, die für an Lex übergebene Dateien verwendet wird.

Siehe auch Dateierweiterungen, LEXSOURCES.

QMAKE_EXT_YACC

Enthält die Dateiendung, die für an Yacc übergebene Dateien verwendet wird.

Siehe auch Dateierweiterungen, YACCSOURCES.

QMAKE_EXT_OBJ

Enthält die Dateiendung, die für generierte Objektdateien verwendet wird.

Siehe auch Dateierweiterungen.

QMAKE_EXT_CPP

Enthält die Endungen für Dateien, die als C++-Quellcode interpretiert werden sollen.

Siehe auch „Dateiendungen“.

QMAKE_EXT_H

Enthält Dateiendungen für Dateien, die als C-Header-Dateien interpretiert werden sollen.

Siehe auch „Dateierweiterungen“.

QMAKE_EXTRA_COMPILERS

Gibt eine Liste zusätzlicher Compiler oder Präprozessoren an.

Siehe auch „Hinzufügen von Compilern“.

QMAKE_EXTRA_TARGETS

Gibt eine Liste zusätzlicher qmake-Ziele an.

Siehe auch „Hinzufügen benutzerdefinierter Ziele“.

QMAKE_FAILED_REQUIREMENTS

Enthält die Liste der nicht erfüllten Anforderungen. Der Wert dieser Variablen wird von qmake festgelegt und kann nicht geändert werden.

Siehe auch „requires() “ und „REQUIRES“.

QMAKE_FRAMEWORK_BUNDLE_NAME

In einem Framework-Projekt enthält diese Variable den Namen, der für das zu erstellende Framework verwendet werden soll.

Standardmäßig enthält diese Variable denselben Wert wie die Variable TARGET.

Weitere Informationen zum Erstellen von Frameworks und Bibliotheksbündeln finden Sie unter „Frameworks erstellen “.

QMAKE_FRAMEWORK_VERSION

Bei Projekten, bei denen das Build-Ziel ein macOS-, iOS-, tvOS- oder watchOS-Framework ist, wird diese Variable verwendet, um die Versionsnummer anzugeben, die dem erstellten Framework zugewiesen wird.

Standardmäßig enthält diese Variable denselben Wert wie die Variable „VERSION “.

Weitere Informationen zum Erstellen von Frameworks finden Sie unter „Erstellen von Frameworks “.

QMAKE_HOST

Liefert Informationen über den Host-Rechner, auf dem qmake ausgeführt wird. Beispielsweise können Sie die Architektur des Host-Rechners über ` QMAKE_HOST.arch` abrufen.

win32-g++:contains(QMAKE_HOST.arch, x86_64):{
    message("Host is 64bit")
    ...
}

QMAKE_INCDIR

Gibt die Liste der System-Header-Pfade an, die an INCLUDEPATH angehängt werden. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_INCDIR_EGL

Gibt den Speicherort der EGL-Header-Dateien an, die beim Erstellen eines Ziels mit OpenGL/ES- oder OpenVG-Unterstützung an INCLUDEPATH angehängt werden sollen. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_INCDIR_OPENGL

Gibt den Speicherort der OpenGL-Header-Dateien an, die beim Erstellen eines Ziels mit OpenGL-Unterstützung zum INCLUDEPATH hinzugefügt werden sollen. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Wenn die OpenGL-Implementierung EGL verwendet (die meisten OpenGL/ES-Systeme), muss möglicherweise auch QMAKE_INCDIR_EGL gesetzt werden.

QMAKE_INCDIR_OPENGL_ES2

Diese Variable gibt den Speicherort der OpenGL-Header-Dateien an, die beim Erstellen eines Ziels mit OpenGL ES 2-Unterstützung zum INCLUDEPATH hinzugefügt werden sollen.

Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Wenn die OpenGL-Implementierung EGL verwendet (die meisten OpenGL/ES-Systeme), muss möglicherweise auch QMAKE_INCDIR_EGL gesetzt werden.

QMAKE_INCDIR_OPENVG

Gibt den Speicherort der OpenVG-Header-Dateien an, die beim Erstellen eines Ziels mit OpenVG-Unterstützung zum INCLUDEPATH hinzugefügt werden sollen. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Wenn die OpenVG-Implementierung EGL verwendet, muss möglicherweise auch QMAKE_INCDIR_EGL gesetzt werden.

QMAKE_INCDIR_X11

Gibt den Speicherort der X11-Header-Dateien an, die beim Erstellen eines X11-Ziels zum INCLUDEPATH hinzugefügt werden sollen. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_INFO_PLIST

Gibt den Namen der Eigenschaftslistendatei „ .plist “ an, die Sie in Ihr macOS-, iOS-, tvOS- und watchOS-Anwendungsbundle aufnehmen möchten.

In der Datei „ .plist “ können Sie einige Variablen definieren, die qmake durch die entsprechenden Werte ersetzt:

Wenn für iOS kompiliert wird und die Datei „ .plist “ den Schlüssel „ NSPhotoLibraryUsageDescription “ enthält, fügt qmake dem Build ein zusätzliches Plugin hinzu, das Unterstützung für den Zugriff auf Fotos bietet (z. B. für QFile/QFileDialog). Weitere Informationen zu diesem Schlüssel finden Sie in der Info.plist-Dokumentation von Apple.

QMAKE_IOS_DEPLOYMENT_TARGET

Legt die absolute Mindestversion von iOS fest, die die Anwendung unterstützt.

Weitere Informationen finden Sie unter „Angabe der unterstützten iOS-Versionen“.

QMAKE_IOS_LAUNCH_SCREEN

Gibt den Startbildschirm an, der von der Anwendung verwendet wird. Ist diese Variable nicht gesetzt, wird ein Standard-Startbildschirm verwendet.

QMAKE_LFLAGS

Legt einen allgemeinen Satz von Flags fest, die an den Linker übergeben werden. Wenn Sie die für eine bestimmte Plattform oder einen bestimmten Projekttyp verwendeten Flags ändern müssen, verwenden Sie stattdessen eine der dafür vorgesehenen speziellen Variablen.

QMAKE_LFLAGS_CONSOLE

Legt die Linker-Flags für die Erstellung von Konsolenprogrammen fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_DEBUG

Legt die Linker-Flags für Debug-Builds fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_PLUGIN

Legt die Linker-Flags für die Erstellung von Plugins fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_RPATH

Legt die Linker-Flags fest, die benötigt werden, um die Werte aus QMAKE_RPATHDIR zu verwenden.

Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_REL_RPATH

Gibt die Linker-Flags an, die erforderlich sind, um relative Pfade in QMAKE_RPATHDIR zu aktivieren.

Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_REL_RPATH_BASE

Gibt die Zeichenkette an, die der dynamische Linker als Speicherort der referenzierenden ausführbaren Datei oder Bibliothek interpretiert.

Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_RPATHLINK

Gibt die Linker-Flags an, die benötigt werden, um die Werte aus QMAKE_RPATHLINKDIR zu verwenden.

Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_RELEASE

Legt die Linker-Flags für Release-Builds fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO

Legt die Linker-Flags für Release-Builds fest, bei denen „ force_debug_info “ in „ CONFIG “ gesetzt ist. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_APP

Legt die Linker-Flags für die Erstellung von Anwendungen fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_SHLIB

Legt die Linker-Flags fest, die zum Erstellen von gemeinsam genutzten Bibliotheken verwendet werden. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_SONAME

Legt die Linker-Flags zum Festlegen des Namens von gemeinsam genutzten Objekten fest, z. B. .so oder .dll. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LFLAGS_THREAD

Legt die Linker-Flags für die Erstellung multithreaded-Projekte fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss selten geändert werden.

QMAKE_LFLAGS_WINDOWS

Legt die Linker-Flags für die Erstellung von Windows-GUI-Projekten (d. h. Nicht-Konsolenanwendungen) fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LIBDIR

Gibt eine Liste von Bibliothekssuchpfaden für alle Projekte an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Um zusätzliche Suchpfade in Projektdateien anzugeben, verwenden Sie stattdessen LIBS wie folgt:

LIBS += -L/path/to/libraries

QMAKE_LIBDIR_POST

Gibt eine Liste der Suchpfade für Systembibliotheken für alle Projekte an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss selten geändert werden.

QMAKE_LIBDIR_FLAGS

Legt den Speicherort aller Bibliotheksverzeichnisse fest, denen das Präfix „-L“ vorangestellt ist. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LIBDIR_EGL

Gibt den Speicherort des EGL-Bibliotheksverzeichnisses an, wenn EGL mit OpenGL/ES oder OpenVG verwendet wird. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LIBDIR_OPENGL

Gibt den Speicherort des OpenGL-Bibliotheksverzeichnisses an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Wenn die OpenGL-Implementierung EGL verwendet (die meisten OpenGL/ES-Systeme), muss möglicherweise auch QMAKE_LIBDIR_EGL gesetzt werden.

QMAKE_LIBDIR_OPENVG

Gibt den Speicherort des OpenVG-Bibliotheksverzeichnisses an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Wenn die OpenVG-Implementierung EGL verwendet, muss möglicherweise auch QMAKE_LIBDIR_EGL gesetzt werden.

QMAKE_LIBDIR_X11

Gibt den Speicherort des X11-Bibliotheksverzeichnisses an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LIBS

Gibt zusätzliche Bibliotheken an, gegen die jedes Projekt verknüpft werden muss. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Um Bibliotheken in einer Projektdatei anzugeben, verwenden Sie stattdessen LIBS.

QMAKE_LIBS_PRIVATE

Gibt zusätzliche private Bibliotheken an, gegen die jedes Projekt verknüpft werden muss. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Um private Bibliotheken in einer Bibliotheksprojektdatei anzugeben, verwenden Sie stattdessen LIBS_PRIVATE.

QMAKE_LIBS_EGL

Gibt alle EGL-Bibliotheken an, wenn Qt mit OpenGL/ES oder OpenVG kompiliert wird. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden. Der übliche Wert ist „ -lEGL “.

QMAKE_LIBS_OPENGL

Gibt alle OpenGL-Bibliotheken an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Wenn die OpenGL-Implementierung EGL verwendet (die meisten OpenGL/ES-Systeme), muss möglicherweise auch QMAKE_LIBS_EGL gesetzt werden.

QMAKE_LIBS_OPENGL_ES1, QMAKE_LIBS_OPENGL_ES2

Diese Variablen geben alle OpenGL-Bibliotheken für OpenGL ES 1 und OpenGL ES 2 an.

Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

Wenn die OpenGL-Implementierung EGL verwendet (die meisten OpenGL/ES-Systeme), muss möglicherweise auch QMAKE_LIBS_EGL gesetzt werden.

QMAKE_LIBS_OPENVG

Gibt alle OpenVG-Bibliotheken an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden. Der übliche Wert ist -lOpenVG.

Einige OpenVG-Engines sind auf OpenGL aufgesetzt. Dies wird bei der Konfiguration erkannt, und QMAKE_LIBS_OPENGL wird implizit zu QMAKE_LIBS_OPENVG hinzugefügt, wo immer die OpenVG-Bibliotheken eingebunden werden.

Wenn die OpenVG-Implementierung EGL verwendet, muss möglicherweise auch QMAKE_LIBS_EGL gesetzt werden.

QMAKE_LIBS_THREAD

Gibt alle Bibliotheken an, die beim Erstellen eines multithreaded-Ziels eingebunden werden müssen. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LIBS_X11

Gibt alle X11-Bibliotheken an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LIB_FLAG

Diese Variable ist nicht leer, wenn die Vorlage „ lib “ angegeben ist. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LINK

Gibt den Linker an, der beim Erstellen anwendungsbasierter Projekte verwendet wird. Es muss lediglich der Dateiname der ausführbaren Linker-Datei angegeben werden, sofern sich diese bei der Verarbeitung der Makefile-Datei in einem Pfad befindet, der in der Variablen ` PATH ` enthalten ist. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LINK_SHLIB_CMD

Legt den Befehl fest, der beim Erstellen einer gemeinsam genutzten Bibliothek ausgeführt werden soll. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LN_SHLIB

Gibt den Befehl an, der beim Erstellen eines Links zu einer gemeinsam genutzten Bibliothek ausgeführt werden soll. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_LRELEASE_FLAGS

Liste zusätzlicher Optionen, die an ` lrelease ` übergeben werden, wenn diese Option über `CONFIG += lrelease` aktiviert ist.

QMAKE_OBJECTIVE_CFLAGS

Legt die Objective-C-/C++-Compiler-Flags für die Erstellung eines Projekts fest. Diese Flags werden zusätzlich zu QMAKE_CFLAGS und QMAKE_CXXFLAGS verwendet.

QMAKE_POST_LINK

Legt den Befehl fest, der nach dem Verknüpfen des TARGETs ausgeführt werden soll. Diese Variable ist normalerweise leer, sodass nichts ausgeführt wird.

QMAKE_PRE_LINK

Legt den Befehl fest, der vor dem Verknüpfen des TARGETs ausgeführt werden soll. Diese Variable ist normalerweise leer, sodass nichts ausgeführt wird.

QMAKE_PROJECT_NAME

Legt den Namen des Projekts fest, wenn Projektdateien für IDEs generiert werden. Der Standardwert ist der Name des Targets. Der Wert dieser Variablen wird in der Regel von qmake verwaltet und muss nur selten geändert werden.

QMAKE_PROVISIONING_PROFILE

Die UUID eines gültigen Provisioning-Profils. Verwenden Sie diese Variable in Verbindung mit QMAKE_DEVELOPMENT_TEAM, um das Provisioning-Profil anzugeben.

QMAKE_MAC_SDK

Diese Variable wird unter macOS beim Erstellen universeller Binärdateien verwendet.

QMAKE_MACOSX_DEPLOYMENT_TARGET

Gibt die absolute Mindestversion von macOS an, die die Anwendung unterstützt.

Weitere Informationen finden Sie unter „Unterstützte Konfigurationen für macOS“.

QMAKE_MAKEFILE

Gibt den Namen der zu erstellenden Makefile an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_QMAKE

Enthält den absoluten Pfad zur ausführbaren qmake-Datei.

QMAKE_RESOURCE_FLAGS

Diese Variable dient dazu, die Liste der Optionen anzupassen, die an die Resource Compiler in jeder der Build-Regeln, in denen sie verwendet wird, übergeben werden. Die folgende Zeile stellt beispielsweise sicher, dass die Optionen „ -threshold “ und „ -compress “ bei jedem Aufruf von „ rcc “ mit bestimmten Werten verwendet werden:

QMAKE_RESOURCE_FLAGS += -threshold 0 -compress 9

QMAKE_RPATHDIR

Gibt eine Liste von Bibliothekspfaden an, die der ausführbaren Datei beim Verknüpfen hinzugefügt werden, damit diese Pfade zur Laufzeit vorrangig durchsucht werden.

Wenn relative Pfade angegeben werden, wandelt qmake diese in eine Form um, die vom dynamischen Linker als relativ zum Speicherort der referenzierenden ausführbaren Datei oder Bibliothek interpretiert wird. Dies wird nur von einigen Plattformen unterstützt (derzeit Linux und Darwin-basierte) und lässt sich durch Überprüfung feststellen, ob QMAKE_REL_RPATH_BASE gesetzt ist.

QMAKE_RPATHLINKDIR

Gibt eine Liste von Bibliothekspfaden an, die der statische Linker nach impliziten Abhängigkeiten von gemeinsam genutzten Bibliotheken durchsuchen soll. Weitere Informationen finden Sie auf der Handbuchseite zu ` ld(1)`.

QMAKE_RUN_CC

Gibt die einzelne Regel an, die zum Erstellen eines Objekts benötigt wird. Der Wert dieser Variablen wird in der Regel von `qmake` oder `qmake.conf` verwaltet und muss nur selten geändert werden.

QMAKE_RUN_CC_IMP

Gibt die einzelne Regel an, die zum Erstellen eines Objekts benötigt wird. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_RUN_CXX

Gibt die einzelne Regel an, die zum Erstellen eines Objekts benötigt wird. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_RUN_CXX_IMP

Gibt die einzelne Regel an, die zum Erstellen eines Objekts benötigt wird. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

QMAKE_SONAME_PREFIX

Wenn definiert, wird der Wert dieser Variablen als Pfad verwendet, der dem Bezeichner „ SONAME “ der erstellten gemeinsam genutzten Bibliothek vorangestellt wird. „ SONAME “ ist der Bezeichner, den der dynamische Linker später verwendet, um auf die Bibliothek zu verweisen. Im Allgemeinen kann dieser Verweis ein Bibliotheksname oder der vollständige Bibliothekspfad sein. Unter macOS, iOS, tvOS und watchOS kann der Pfad relativ unter Verwendung der folgenden Platzhalter angegeben werden:

In den meisten Fällen ist die Verwendung von „ @rpath “ ausreichend und wird empfohlen:

# <project root>/project.pro
QMAKE_SONAME_PREFIX = @rpath

Das Präfix kann jedoch auch mithilfe verschiedener Platzhalter oder eines absoluten Pfads angegeben werden, beispielsweise einer der folgenden:

# <project root>/project.pro
QMAKE_SONAME_PREFIX = @executable_path/../Frameworks
QMAKE_SONAME_PREFIX = @loader_path/Frameworks
QMAKE_SONAME_PREFIX = /Library/Frameworks

Weitere Informationen finden Sie in der dyld -Dokumentation zu den Installationsnamen dynamischer Bibliotheken.

QMAKE_TARGET

Gibt den Namen des Projektziels an. Der Wert dieser Variablen wird in der Regel von `qmake` oder `qmake.conf ` verwaltet und muss nur selten geändert werden.

QMAKE_TARGET_COMPANY

Nur unter Windows. Gibt das Unternehmen für das Projektziel an; dies wird gegebenenfalls verwendet, um den Firmennamen in die Eigenschaften der Anwendung einzutragen. Dies wird nur verwendet, wenn die Variable VERSION oder RC_ICONS gesetzt ist und die Variablen RC_FILE und RES_FILE nicht gesetzt sind.

QMAKE_TARGET_DESCRIPTION

Nur Windows. Gibt die Beschreibung für das Projektziel an; diese wird gegebenenfalls verwendet, um die Beschreibung in die Eigenschaften der Anwendung einzufügen. Dies wird nur verwendet, wenn die Variable „VERSION“ oder „RC_ICONS“ gesetzt ist und die Variablen „RC_FILE“ und „RES_FILE“ nicht gesetzt sind.

QMAKE_TARGET_COPYRIGHT

Nur Windows. Gibt die Copyright-Informationen für das Projektziel an; diese werden gegebenenfalls verwendet, um die Copyright-Informationen in die Eigenschaften der Anwendung einzufügen. Dies wird nur verwendet, wenn die Variable „VERSION“ oder „RC_ICONS“ gesetzt ist und die Variablen „RC_FILE“ und „RES_FILE“ nicht gesetzt sind.

QMAKE_TARGET_PRODUCT

Nur Windows. Gibt das Produkt für das Projektziel an; dies wird gegebenenfalls verwendet, um das Produkt in die Eigenschaften der Anwendung einzufügen. Dies wird nur verwendet, wenn die Variable „VERSION“ oder „RC_ICONS“ gesetzt ist und die Variablen „RC_FILE“ und „RES_FILE“ nicht gesetzt sind.

QMAKE_TARGET_ORIGINAL_FILENAME

Nur Windows. Gibt den ursprünglichen Dateinamen für das Projektziel an; dieser wird gegebenenfalls verwendet, um den ursprünglichen Dateinamen in die Eigenschaften der Anwendung einzutragen. Dies wird nur verwendet, wenn die Variable VERSION oder RC_ICONS gesetzt ist und die Variablen RC_FILE und RES_FILE nicht gesetzt sind.

QMAKE_TARGET_INTERNALNAME

Nur Windows. Gibt den internen Namen für das Projektziel an; dieser wird gegebenenfalls verwendet, um den internen Namen in die Eigenschaften der Anwendung einzutragen. Dies wird nur genutzt, wenn die Variable „VERSION“ oder „RC_ICONS“ gesetzt ist und die Variablen „RC_FILE“ und „RES_FILE“ nicht gesetzt sind.

QMAKE_TARGET_COMMENTS

Nur Windows. Gibt die Kommentare für das Projektziel an; diese werden gegebenenfalls zum Einfügen der Kommentare in die Eigenschaften der Anwendung verwendet. Dies wird nur verwendet, wenn die Variable „VERSION“ oder „RC_ICONS“ gesetzt ist und die Variablen „RC_FILE“ und „RES_FILE“ nicht gesetzt sind.

QMAKE_TARGET_TRADEMARKS

Nur Windows. Legt die Markeninformationen für das Projektziel fest; diese werden gegebenenfalls verwendet, um die Markeninformationen in die Eigenschaften der Anwendung einzufügen. Dies wird nur verwendet, wenn die Variable VERSION oder RC_ICONS gesetzt ist und die Variablen RC_FILE und RES_FILE nicht gesetzt sind.

QMAKE_MANIFEST

Nur Windows. Gibt die Manifestdatei für das Projektziel an. Dies wird nur verwendet, wenn die Variablen „RC_FILE“ und „RES_FILE“ nicht gesetzt sind. Vergessen Sie nicht, „embed_manifest_exe“ und „embed_manifest_dll“ aus der Variablen „CONFIG“ zu entfernen, da es sonst zu Konflikten mit der vom Compiler generierten Datei kommt.

QMAKE_TVOS_DEPLOYMENT_TARGET

Gibt die absolute Mindestversion von tvOS an, die die Anwendung unterstützt.

Weitere Informationen finden Sie unter „Angabe der unterstützten iOS-Versionen“.

QMAKE_UIC_FLAGS

Diese Variable dient dazu, die Liste der Optionen anzupassen, die an die User Interface Compiler in jeder der Build-Regeln, in denen sie verwendet wird, übergeben werden.

QMAKE_WATCHOS_DEPLOYMENT_TARGET

Gibt die absolute Mindestversion von watchOS an, die die Anwendung unterstützt.

Weitere Informationen finden Sie unter „Angabe unterstützter iOS-Versionen“.

QML_IMPORT_MAJOR_VERSION

Legt die Hauptversion fest, die für automatisch generierte QML-Typregistrierungen verwendet werden soll. Weitere Informationen finden Sie unter „Definieren von QML-Typen aus C++“.

QML_IMPORT_MINOR_VERSION

Bei der automatischen Registrierung von in C++ definierten QML-Typen wird mithilfe dieser Nebenversion eine zusätzliche Version des Moduls registriert. Im Allgemeinen werden die zu registrierenden Nebenversionen aus den Metaobjekten abgeleitet.

Sie können diese Variable verwenden, wenn sich die Metaobjekte nicht geändert haben und Sie dennoch ein QML-Modul mit einer neueren Nebenversionsnummer importieren möchten. Beispielsweise befinden sich die Metaobjekte von „ MyModule “ auf der Stufe „ 1.1 “, Sie möchten das Modul jedoch als „ 1.3 “ importieren.

QML_IMPORT_VERSION

Legt QML_IMPORT_MAJOR_VERSION und QML_IMPORT_MINOR_VERSION als <major>.<minor> -Versionszeichenfolge fest.

QML_IMPORT_NAME

Legt den Modulnamen fest, der für automatisch generierte QML-Typregistrierungen verwendet werden soll. Weitere Informationen finden Sie unter „QML-Typen aus C++ definieren“.

QML_FOREIGN_METATYPES

Gibt weitere JSON-Dateien mit Metatypen an, die bei der Generierung von qmltypes-Dateien berücksichtigt werden sollen. Verwenden Sie diese Option, wenn externe Bibliotheken Typen bereitstellen, die für QML verfügbar sind – entweder direkt oder als Basistypen oder Eigenschaften anderer Typen. Qt-Typen werden automatisch berücksichtigt und müssen hier nicht hinzugefügt werden.

QT

Gibt die Qt-Module an, die von Ihrem Projekt verwendet werden. Den für jedes Modul hinzuzufügenden Wert finden Sie in der Modul-Dokumentation.

Auf der Ebene der C++-Implementierung sorgt die Verwendung eines Qt-Moduls dafür, dass dessen Header zur Einbindung verfügbar sind und das Modul in die Binärdatei eingebunden wird.

Standardmäßig enthält „ QT “ die Module „ core “ und „ gui “, wodurch sichergestellt wird, dass Standard-GUI-Anwendungen ohne weitere Konfiguration erstellt werden können.

Wenn Sie ein Projekt ohne das Qt GUI Moduls erstellen möchten, müssen Sie den Wert „ gui “ mit dem Operator „-=“ ausschließen. Die folgende Zeile führt zur Erstellung eines minimalen Qt-Projekts:

QT -= gui # Only the core module is used.

Wenn es sich bei Ihrem Projekt um ein „ Qt Widgets Designer“-Plugin handelt, verwenden Sie den Wert „ uiplugin “, um anzugeben, dass das Projekt als Bibliothek erstellt werden soll, jedoch mit spezifischer Plugin-Unterstützung für den „ Qt Widgets Designer“. Weitere Informationen finden Sie unter „Erstellen und Installieren des Plugins“.

QTPLUGIN

Gibt eine Liste mit Namen statischer Qt-Plugins an, die mit einer Anwendung verknüpft werden sollen, damit sie als integrierte Ressourcen verfügbar sind.

qmake fügt automatisch die Plugins hinzu, die typischerweise von den verwendeten Qt-Modulen benötigt werden (siehe „ QT “). Die Standardeinstellungen sind auf eine optimale sofortige Nutzung ausgelegt. Eine Liste der verfügbaren Plugins sowie Möglichkeiten zum Überschreiben der automatischen Verknüpfung finden Sie unter „Static Plugins “.

Diese Variable hat derzeit keine Auswirkung, wenn gegen eine gemeinsam genutzte/dynamische Version von Qt verknüpft wird oder wenn Bibliotheken verknüpft werden. Sie kann möglicherweise zu einem späteren Zeitpunkt für die Bereitstellung dynamischer Plugins verwendet werden.

QT_VERSION

Enthält die aktuelle Version von Qt.

QT_MAJOR_VERSION

Enthält die aktuelle Hauptversion von Qt.

QT_MINOR_VERSION

Enthält die aktuelle Nebenversion von Qt.

QT_PATCH_VERSION

Enthält die aktuelle Patch-Version von Qt.

RC_FILE

Nur Windows. Gibt den Namen der Windows-Ressourcendatei (.rc) für das Ziel an. Siehe Hinzufügen von Windows-Ressourcendateien.

RC_CODEPAGE

Nur Windows. Gibt die Codepage an, die in einer generierten .rc-Datei angegeben werden soll. Dies wird nur verwendet, wenn die Variable VERSION oder RC_ICONS gesetzt ist und die Variablen RC_FILE und RES_FILE nicht gesetzt sind.

RC_DEFINES

Nur Windows. qmake fügt die Werte dieser Variablen als RC-Präprozessor-Makros hinzu (Option /d). Ist diese Variable nicht gesetzt, wird stattdessen die Variable DEFINES verwendet.

RC_DEFINES += USE_MY_STUFF

RC_ICONS

Nur unter Windows. Legt die Symbole fest, die in eine generierte .rc-Datei aufgenommen werden sollen. Dies wird nur verwendet, wenn die Variablen „RC_FILE“ und „RES_FILE“ nicht gesetzt sind. Weitere Details zur Generierung von .rc-Dateien finden Sie in den Plattformhinweisen.

RC_LANG

Nur Windows. Legt die Sprache fest, die in einer generierten .rc-Datei angegeben werden soll. Dies wird nur verwendet, wenn die Variable „VERSION“ oder „RC_ICONS“ gesetzt ist und die Variablen „RC_FILE“ und „RES_FILE“ nicht gesetzt sind.

RC_INCLUDEPATH

Gibt Include-Pfade an, die an den Windows- Resource Compiler, übergeben werden.

RCC_DIR

Resource Compiler Gibt das Verzeichnis für die Ausgabedateien des Qt XML-ph-0000@deepl.internal an.

Beispiel:

unix:RCC_DIR = ../myproject/resources
win32:RCC_DIR = c:/myproject/resources

REQUIRES

Gibt eine Liste von Werten an, die als Bedingungen ausgewertet werden. Ist eine der Bedingungen falsch, überspringt qmake dieses Projekt (und dessen SUBDIRS) beim Erstellen.

RESOURCES

Gibt den Namen der Ressourcensammlungsdateien (qrc) für das Ziel an. Weitere Informationen zur Ressourcensammlungsdatei finden Sie unter „Das Qt-Ressourcensystem“.

RES_FILE

Nur Windows. Gibt den Namen der Ausgabedatei des Windows-Resource Compilers für dieses Ziel an. Siehe RC_FILE und Hinzufügen von Windows-Ressourcendateien.

Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

SOURCES

Gibt die Namen aller Quelldateien im Projekt an.

Hinweis zu eingebundenen Quelldateien

Standardmäßig durchsucht QMake Quelldateien nach Abhängigkeiten und schließt automatisch .cpp-Dateien aus, die in anderen .cpp-Dateien eingebunden sind, um doppelte Kompilierungen und Linker-Fehler zu vermeiden. Dieser automatische Ausschluss unterliegt wichtigen Einschränkungen:

• Der Ausschluss erfolgt unabhängig von Präprozessor-Bedingungen (#ifdef, #ifndef usw.).
• Eine .cpp-Datei, die an beliebiger Stelle im Projekt mit „ #included “ einbezogen wird, wird von „ SOURCES “ ausgeschlossen, selbst wenn die Einbindung bedingt erfolgt.

Um die Kompilierung ausgeschlossener Dateien zu erzwingen, fügen Sie „ CONFIG += compile_included_sources “ zu Ihrer .pro-Datei hinzu. Alternativ können Sie die einbezogenen Dateien aus „SOURCES“ entfernen und sicherstellen, dass sie ausschließlich über die Datei kompiliert werden, die sie einbindet. Dies gilt für alle Dateien mit Erweiterungen, die in „QMAKE_EXT_CPP“ aufgeführt sind.

Beispiel:

SOURCES = myclass.cpp \
      login.cpp \
      mainwindow.cpp

Siehe auch HEADERS.

SUBDIRS

Diese Variable gibt in Verbindung mit der Vorlage „ subdirs “ die Namen aller Unterverzeichnisse oder Projektdateien an, die Teile des Projekts enthalten, die erstellt werden müssen. Jedes mit dieser Variable angegebene Unterverzeichnis muss eine eigene Projektdatei enthalten.

Es wird empfohlen, dass die Projektdatei in jedem Unterverzeichnis denselben Basisnamen wie das Unterverzeichnis selbst hat, da dadurch der Dateiname weggelassen werden kann. Wenn das Unterverzeichnis beispielsweise „ myapp “ heißt, sollte die Projektdatei in diesem Verzeichnis „ myapp.pro “ heißen.

Alternativ können Sie einen relativen Pfad zu einer .pro-Datei in einem beliebigen Verzeichnis angeben. Es wird dringend empfohlen, nur Pfade im übergeordneten Verzeichnis des aktuellen Projekts oder in dessen Unterverzeichnissen anzugeben.

Beispiel:

SUBDIRS = kernel \
          tools \
          myapp

Wenn Sie sicherstellen möchten, dass die Unterverzeichnisse in einer bestimmten Reihenfolge erstellt werden, verwenden Sie den Modifikator „ .depends “ für die entsprechenden „ SUBDIRS “-Elemente.

Beispiel:

SUBDIRS += my_executable my_library tests doc
my_executable.depends = my_library
tests.depends = my_executable

Die obige Konfiguration stellt sicher, dass „ my_library “ vor „ my_executable “ und „ my_executable “ vor „ tests “ erstellt wird. „ doc “ kann jedoch parallel zu den anderen Unterverzeichnissen erstellt werden, was den Erstellungsprozess beschleunigt.

Neben der Festlegung der Build-Reihenfolge ist es möglich, das Standardverhalten von „ SUBDIRS “ durch zusätzliche Modifikatoren bei „ SUBDIRS “-Elementen anzupassen. Unterstützte Modifikatoren sind:

Beispiel: Definieren Sie zwei Unterverzeichnisse, die sich beide in einem anderen Verzeichnis befinden als der Wert „ SUBDIRS “, wobei eines der Unterverzeichnisse vor dem anderen erstellt werden muss:

SUBDIRS += my_executable my_library
my_executable.subdir = app
my_executable.depends = my_library
my_library.subdir = lib

TARGET

Gibt den Namen der Zieldatei an. Enthält standardmäßig den Basisnamen der Projektdatei.

Beispiel:

TEMPLATE = app
TARGET = myapp
SOURCES = main.cpp

Die oben genannte Projektdatei würde unter Unix eine ausführbare Datei namens „ myapp “ und unter Windows eine namens „ myapp.exe “ erzeugen.

TARGET_EXT

Gibt die Dateiendung von „ TARGET “ an. Der Wert dieser Variablen wird in der Regel von „qmake“ oder „qmake.conf“ verwaltet und muss nur selten geändert werden.

TARGET_x

Legt die Erweiterung von „ TARGET “ mit einer Hauptversionsnummer fest. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

TARGET_x.y.z

Gibt die Erweiterung von „ TARGET “ mit einer Versionsnummer an. Der Wert dieser Variablen wird in der Regel von qmake oder qmake.conf verwaltet und muss nur selten geändert werden.

TEMPLATE

Gibt den Namen der Vorlage an, die beim Erstellen des Projekts verwendet werden soll. Die zulässigen Werte sind:

Beispiel:

TEMPLATE = lib
SOURCES = main.cpp
TARGET = mylib

Die Vorlage kann überschrieben werden, indem mit der Befehlszeilenoption „ -t “ ein neuer Vorlagentyp angegeben wird. Dadurch wird der Vorlagentyp nach der Verarbeitung der .pro-Datei überschrieben. Bei .pro-Dateien, die den Vorlagentyp zur Bestimmung der Projekterstellung verwenden, muss „TEMPLATE“ in der Befehlszeile deklariert werden, anstatt die Option „ -t “ zu verwenden.

TRANSLATIONS

Gibt eine Liste von Übersetzungsdateien (.ts) an, die Übersetzungen des Benutzeroberflächentextes in andere Sprachen enthalten.

Übersetzungsdateien im Verzeichnis „ TRANSLATIONS “ werden sowohl von „lrelease“ als auch von den „lupdate“-Tools verarbeitet. Verwenden Sie „EXTRA_TRANSLATIONS“, wenn Sie möchten, dass eine Datei ausschließlich von „ lrelease “ verarbeitet wird.

Sie können CONFIG += lrelease verwenden, um die Dateien während des Builds automatisch zu kompilieren, und CONFIG += lrelease embed_translations, um sie im Qt-Ressourcensystem verfügbar zu machen.

Weitere Informationen zur Internationalisierung (i18n) und Lokalisierung (l10n) mit Qt finden Sie im Qt Linguist -Handbuch.

TR_EXCLUDE

Gibt eine Liste von Pfaden (Quelldateien, Unterverzeichnisse und C++-Include-Pfade) an, die von der Verarbeitung in „ lupdate “ ausgeschlossen werden sollen. Die Pfade dürfen Platzhalter enthalten. Relative Pfade werden als relativ zu _PRO_FILE_PWD_ betrachtet.

Beispiel für den Ausschluss von Quelldateien:

SOURCES += main.cpp \
    excluded.cpp \
    3rdparty/sqlite3.h \
    3rdparty/sqlite3.c
TR_EXCLUDE += excluded.cpp 3rdparty/*

So schließen Sie Unterverzeichnisse eines „ SUBDIRS “-Projekts aus:

SUBDIRS += \
    libs \
    apps \
    tests
TR_EXCLUDE += tests

Um den C++-Parser von lupdate zu beschleunigen, schließen Sie Include-Pfade aus:

linux {
    TR_EXCLUDE += /usr/include/boost/*
}

UI_DIR

Gibt das Verzeichnis an, in dem alle Zwischendateien von uic abgelegt werden sollen.

Beispiel:

unix:UI_DIR = ../myproject/ui
win32:UI_DIR = c:/myproject/ui

VERSION

Gibt die Versionsnummer der Anwendung an, wenn die Vorlage „ app “ angegeben ist, oder die Versionsnummer der Bibliothek, wenn die Vorlage „ lib “ angegeben ist.

Unter Windows löst dies die automatische Generierung einer .rc-Datei aus, wenn die Variablen RC_FILE und RES_FILE nicht gesetzt sind. In der generierten .rc-Datei werden die Einträge „FILEVERSION“ und „PRODUCTVERSION“ mit der Haupt-, Neben- und Patch-Version sowie der Build-Nummer ausgefüllt. Jede Zahl muss im Bereich von 0 bis 65535 liegen. Weitere Details zur Generierung von .rc-Dateien finden Sie in den Plattformhinweisen.

Beispiel:

win32:VERSION = 1.2.3.4 # major.minor.patch.build
else:VERSION = 1.2.3    # major.minor.patch

VERSION_PE_HEADER

Nur Windows. Gibt die Versionsnummer an, die der Windows-Linker über die Option /VERSION in den Header der .exe- oder .dll-Datei einfügt. Es dürfen nur die Haupt- und Nebenversion angegeben werden. Ist VERSION_PE_HEADER nicht gesetzt, werden standardmäßig die Haupt- und Nebenversion aus VERSION (sofern gesetzt) verwendet.

VERSION_PE_HEADER = 1.2

VER_MAJ

Gibt die Hauptversionsnummer der Bibliothek an, wenn die Vorlage „ lib “ angegeben ist.

VER_MIN

Gibt die Nebenversionsnummer der Bibliothek an, wenn die Vorlage „ lib “ angegeben ist.

VER_PAT

Gibt die Patch-Versionsnummer der Bibliothek an, wenn die Vorlage „ lib “ angegeben ist.

VPATH

Teilt qmake mit, wo es nach Dateien suchen soll, die es nicht öffnen kann. Wenn qmake beispielsweise nach „ SOURCES “ sucht und einen Eintrag findet, den es nicht öffnen kann, durchsucht es die gesamte VPATH-Liste, um zu prüfen, ob es die Datei selbst finden kann.

Siehe auch DEPENDPATH.

WINDOWS_TARGET_PLATFORM_VERSION

Gibt die Zielversion von Windows an; dies entspricht dem Tag „ WindowsTargetPlatformVersion “ in vcxproj-Dateien.

Unter Desktop-Windows ist der Standardwert der Wert der Umgebungsvariable „ WindowsSDKVersion “.

WINDOWS_TARGET_PLATFORM_MIN_VERSION

Gibt die Mindestversion der Windows-Zielplattform an; dies entspricht dem Tag „ WindowsTargetPlatformMinVersion “ in vcxproj-Dateien.

Der Standardwert ist „ WINDOWS_TARGET_PLATFORM_VERSION “.

YACCSOURCES

Gibt eine Liste der Yacc-Quelldateien an, die in das Projekt aufgenommen werden sollen. Alle Abhängigkeiten, Header- und Quelldateien werden automatisch in das Projekt aufgenommen.

Beispiel:

YACCSOURCES = moc.y

_PRO_FILE_

Enthält den Pfad zur verwendeten Projektdatei.

Die folgende Zeile bewirkt beispielsweise, dass der Speicherort der Projektdatei in die Konsole geschrieben wird:

message($$_PRO_FILE_)

_PRO_FILE_PWD_

Enthält den Pfad zu dem Verzeichnis, in dem sich die verwendete Projektdatei befindet.

Die folgende Zeile bewirkt beispielsweise, dass der Speicherort des Verzeichnisses, in dem sich die Projektdatei befindet, in die Konsole geschrieben wird:

message($$_PRO_FILE_PWD_)