Variables

Le comportement fondamental de qmake est influencé par des déclarations de variables qui définissent le processus de construction de chaque projet. Certaines d'entre elles déclarent des ressources, telles que les en-têtes et les fichiers source, qui sont communes à chaque plate-forme. D'autres sont utilisées pour personnaliser le comportement des compilateurs et des éditeurs de liens sur des plates-formes spécifiques.

Les variables spécifiques à une plate-forme suivent le modèle de dénomination des variables qu'elles étendent ou modifient, mais incluent le nom de la plate-forme concernée dans leur nom. Par exemple, un makespec peut utiliser QMAKE_LIBS pour spécifier une liste de bibliothèques avec lesquelles chaque projet doit établir un lien, et QMAKE_LIBS_X11 sera utilisé pour étendre cette liste.

ANDROID_ABIS

Spécifie une liste d'ABI pour les cibles Android. Les valeurs valides sont : armeabi-v7a, arm64-v8a, x86, x86_64.

Vous pouvez fournir les ABI en tant qu'argument de qmake :

qmake ANDROID_ABIS="armeabi-v7a arm64-v8a"

ANDROID_API_VERSION

Spécifie le numéro de niveau de l'API Android. Pour plus d'informations, voir Numéros de build d'Android.

ANDROID_APPLICATION_ARGUMENTS

Spécifie des arguments de ligne de commande supplémentaires pour l'application Android à l'aide de AndroidManifest.xml avec la balise "android.app.arguments". Cette variable prend une chaîne d'arguments :

ANDROID_APPLICATION_ARGUMENTS = "arg1 arg2 arg3"

ANDROID_BUNDLED_JAR_DEPENDENCIES

Elle est utile lors de l'écriture d'un module Qt. Elle spécifie une liste de dépendances pré-groupées utilisées par le module dans un format .jar, par exemple :

ANDROID_BUNDLED_JAR_DEPENDENCIES += jar/Qt6Android.jar

ANDROID_DEPLOYMENT_DEPENDENCIES

Par défaut, androiddeployqt détectera les dépendances de votre application. Cependant, comme l'utilisation des plugins pendant l'exécution ne peut pas être détectée, il peut y avoir des faux positifs, car votre application peut dépendre de n'importe quel plugin qui est une dépendance potentielle. Si vous souhaitez minimiser la taille de votre site APK, il est possible de passer outre la détection automatique en utilisant la variable this. Celle-ci doit contenir une liste de tous les fichiers Qt qui doivent être inclus, avec des chemins relatifs à la racine de l'installation de Qt.

ANDROID_DEPLOYMENT_SETTINGS_FILE

Spécifie le chemin d'accès au fichier android-deployment-settings.json nécessaire à androiddeployqt et androidtestrunner. Cela remplace le chemin vers le fichier de configuration généré par qmake, vous devez donc vous assurer de fournir un fichier de configuration valide.

ANDROID_EXTRA_LIBS

Une liste de bibliothèques externes qui seront copiées dans le dossier libs de votre application et chargées au démarrage. Cette liste peut être utilisée, par exemple, pour activer OpenSSL dans votre application. Pour plus d'informations, voir Ajouter la prise en charge d'OpenSSL pour Android.

Pour inclure des bibliothèques externes pour plusieurs ABI, où chaque ABI a son propre répertoire, utilisez ce qui suit :

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

Sinon, si l'ABI est incluse dans le nom de la bibliothèque, utilisez ce qui suit :

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

ANDROID_EXTRA_PLUGINS

Spécifie un chemin d'accès aux plugins C++ ou aux ressources que votre application doit regrouper mais qui ne peuvent pas être fournis par le système d'actifs, tels que les plugins QML. Avec cette variable, androiddeployqt s'assurera que tout est empaqueté et déployé correctement.

ANDROID_EXTRA_PLUGINS doit pointer vers le répertoire où le(s) plugin(s) supplémentaire(s) est (sont) construit(s). De plus, la structure du répertoire de construction doit suivre une convention de nommage similaire à celle des plugins Qt, c'est-à-dire plugins/<nom du plugin>.

Les bibliothèques de plugins doivent avoir le format de nom libplugins_<type>_<nom>_<abi>.so. Pour ce faire, le fichier plugin pro pourrait être défini comme suit :

TEMPLATE = lib
CONFIG += plugin

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

avec top_builddir défini dans .qmake.conf comme :

top_builddir=$$shadowed($$PWD)

Cela garantira que la manipulation correcte des noms est appliquée à la bibliothèque du plugin(plugins/myplugin/libplugins_imageformats_myplugin_armeabi-v7a.so).

Ensuite, en supposant qu'un plugin de format d'image supplémentaire myplugin soit construit en tant que $$DESTDIR/plugins/myplugin/, ce qui suit garantit qu'il est correctement empaqueté :

ANDROID_EXTRA_PLUGINS += $$top_builddir/plugins

ANDROID_FEATURES

Spécifie la liste des fonctionnalités d'un module :

ANDROID_FEATURES += android.hardware.location.gps

Pour plus d'informations, voir Android <uses-feature> Docs.

ANDROID_LIB_DEPENDENCIES

Cette variable est utile lors de l'écriture d'un module Qt. Elle spécifie une liste de dépendances préconstruites utilisées par le module, par exemple :

ANDROID_LIB_DEPENDENCIES += \
    plugins/libplugins_platforms_qtforandroid.so

ANDROID_MIN_SDK_VERSION

Spécifie le niveau minimum de l'API Android pour le projet. Par défaut, cette variable est définie sur le niveau d'API 23.

ANDROID_PACKAGE_SOURCE_DIR

Indique le chemin d'accès à un modèle de paquetage Android personnalisé. Le modèle de paquetage Android contient les éléments suivants

• le fichier AndroidManifest.xml
• le fichier build.gradle et d'autres scripts Gradle
• le fichier res/values/libs.xml

Le chemin spécifié par cette variable peut contenir des classes Java personnalisées dans le répertoire src. Par défaut, l'outil androiddeployqt copie le modèle d'application à partir du chemin d'installation de Qt pour Android dans le répertoire de construction de votre projet, puis il copie le contenu du chemin spécifié par cette variable par-dessus, en écrasant tous les fichiers existants. Par exemple, vous pouvez créer un site AndroidManifest.xml personnalisé pour votre application, puis le placer directement dans le répertoire spécifié par cette variable.

ANDROID_PERMISSIONS

Spécifie la liste des autorisations d'un module :

ANDROID_PERMISSIONS += android.permission.ACCESS_FINE_LOCATION

Pour plus d'informations, voir Android <uses-permission> Docs.

ANDROID_TARGET_SDK_VERSION

Spécifie le niveau de l'API Android cible pour le projet. Par défaut, cette variable est définie sur le niveau d'API 36.

ANDROID_VERSION_CODE

Indique le numéro de version de l'application. Pour plus d'informations, voir Versionnement des applications Android.

ANDROID_VERSION_NAME

Indique la version de l'application sous la forme d'une chaîne lisible par l'homme. Pour plus d'informations, voir Versionnement des applications Android.

CONFIG

Spécifie la configuration du projet et les options du compilateur. Les valeurs sont reconnues en interne par qmake et ont une signification particulière.

Les valeurs suivantes CONFIG contrôlent les drapeaux du compilateur et de l'éditeur de liens :

Lorsque vous utilisez l'option debug_and_release (qui est la valeur par défaut sous Windows), le projet sera traité trois fois : une fois pour produire un Makefile "meta", et deux autres fois pour produire un Makefile.Debug et un Makefile.Release.

Lors de ces derniers passages, build_pass et l'option debug ou release correspondante sont ajoutés à CONFIG, ce qui permet d'effectuer des tâches spécifiques à la construction. Par exemple :

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

Comme alternative à l'écriture manuelle des conditionnelles de type de compilation, certaines variables offrent des variantes spécifiques à la compilation, par exemple QMAKE_LFLAGS_RELEASE en plus de l'option générale QMAKE_LFLAGS. Celles-ci doivent être utilisées lorsqu'elles sont disponibles.

Le métafichier Makefile rend les sous-constructions invocables via les cibles debug et release, et une construction combinée via la cible all. Lorsque l'option build_all CONFIG est utilisée, la compilation combinée est la valeur par défaut. Sinon, la dernière option CONFIG spécifiée de l'ensemble (debug, release) détermine la valeur par défaut. Dans ce cas, vous pouvez invoquer explicitement la cible all pour construire les deux configurations à la fois :

make all

Lors de l'édition de liens d'une bibliothèque, qmake s'appuie sur la plateforme sous-jacente pour savoir quelles sont les autres bibliothèques avec lesquelles cette bibliothèque est liée. Cependant, si l'édition de liens est statique, qmake n'obtiendra pas cette information à moins d'utiliser les options suivantes CONFIG:

Les options suivantes définissent le type d'application ou de bibliothèque :

Ces options définissent des caractéristiques spécifiques pour Windows uniquement :

Voir les notes relatives à la plate-forme pour plus d'informations sur les options d'intégration des fichiers de manifeste.

Les options suivantes n'ont d'effet que sur macOS :

Le processus de construction des bundles est également influencé par le contenu de la variable QMAKE_BUNDLE_DATA.

Les options suivantes n'ont d'effet que sur les plates-formes Linux/Unix :

La variable CONFIG sera également vérifiée lors de la résolution des champs d'application. Vous pouvez assigner n'importe quoi à cette variable.

Vous pouvez assigner n'importe quoi à cette variable, par exemple :

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

DEFINES

qmake ajoute les valeurs de cette variable en tant que macros du préprocesseur C du compilateur (option -D).

Par exemple : DEFINES

DEFINES += USE_MY_STUFF

DEFINES_DEBUG

Spécifie les définitions du préprocesseur pour la configuration de débogage. Les valeurs de cette variable sont ajoutées à DEFINES après le chargement du projet. Cette variable est généralement définie dans qmake.conf et a rarement besoin d'être modifiée.

Cette variable a été introduite dans Qt 5.13.2.

DEFINES_RELEASE

Spécifie les définitions du préprocesseur pour la configuration de la version. Les valeurs de cette variable sont ajoutées à DEFINES après le chargement du projet. Cette variable est généralement définie dans qmake.conf et a rarement besoin d'être modifiée.

Cette variable a été introduite dans Qt 5.13.2.

DEF_FILE

Spécifie un fichier .def à inclure dans le projet.

DEPENDPATH

Spécifie une liste de répertoires que qmake doit analyser pour résoudre les dépendances. Cette variable est utilisée lorsque qmake parcourt les fichiers d'en-tête que vous #include dans votre code source.

DESTDIR

Spécifie où placer le fichier cible.

Par exemple, DESTDIR

DESTDIR = ../../lib

DISTFILES

Spécifie une liste de fichiers à inclure dans la cible dist. Cette fonctionnalité n'est prise en charge que par les spécifications d'UnixMake.

Par exemple :

DISTFILES += ../program.txt

DLLDESTDIR

Spécifie l'endroit où copier la dll cible.

EXTRA_TRANSLATIONS

Spécifie une liste de fichiers de traduction (.ts) qui contiennent des traductions du texte de l'interface utilisateur dans des langues autres que la langue maternelle.

Contrairement à TRANSLATIONS, les fichiers de traduction contenus dans EXTRA_TRANSLATIONS ne seront traités que par lrelease, et non par lupdate.

Vous pouvez utiliser CONFIG += lrelease pour compiler automatiquement les fichiers pendant la construction, et CONFIG += lrelease embed_translations pour les rendre disponibles dans le Qt Resource System.

Voir le manuelQt Linguist pour plus d'informations sur l'internationalisation (i18n) et la localisation (l10n) avec Qt.

FORMS

Spécifie les fichiers d'interface utilisateur (voir le manuelQt Widgets Designer ) à traiter par uic avant la compilation. Toutes les dépendances, les en-têtes et les fichiers sources nécessaires à la construction de ces fichiers d'interface utilisateur seront automatiquement ajoutés au projet.

Par exemple :

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

GUID

Spécifie le GUID qui est défini dans un fichier .vcproj. Le GUID est généralement déterminé de manière aléatoire. Cependant, si vous avez besoin d'un GUID fixe, il peut être défini à l'aide de cette variable.

Cette variable est spécifique aux fichiers .vcproj uniquement ; elle est ignorée dans les autres cas.

HEADERS

Définit les fichiers d'en-tête pour le projet.

qmake détecte automatiquement si moc est requis par les classes dans les en-têtes, et ajoute les dépendances et les fichiers appropriés au projet pour générer et lier les fichiers moc.

Par exemple :

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

Voir aussi SOURCES.

ICON

Cette variable est utilisée uniquement sous Mac OS pour définir l'icône de l'application. Veuillez consulter la documentation relative à l'icône de l'application pour plus d'informations.

IDLSOURCES

Cette variable est utilisée uniquement sous Windows pour la génération du projet Visual Studio afin de placer les fichiers spécifiés dans le dossier Generated Files.

INCLUDEPATH

Spécifie les répertoires #include qui doivent être recherchés lors de la compilation du projet.

Par exemple, pour spécifier un chemin contenant des espaces, mettez des guillemets :

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

Pour spécifier un chemin d'accès contenant des espaces, citez le chemin d'accès en utilisant la technique décrite dans Whitespace.

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

INSTALLS

Spécifie une liste de ressources qui seront installées lors de l'exécution de make install ou d'une procédure d'installation similaire. Chaque élément de la liste est généralement défini par des attributs qui fournissent des informations sur l'endroit où il sera installé.

Par exemple, la définition suivante target.path décrit l'endroit où la cible de construction sera installée, et l'affectation INSTALLS ajoute la cible de construction à la liste des ressources existantes à installer :

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

INSTALLS possède un membre .CONFIG qui peut prendre plusieurs valeurs :

Pour plus d'informations, voir Installation des fichiers.

Cette variable est également utilisée pour spécifier les fichiers supplémentaires qui seront déployés sur les dispositifs embarqués.

JAVA_HOME

Spécifie le chemin d'installation du JDK/OpenJDK utilisé pour construire le projet.

LEXIMPLS

Spécifie une liste de fichiers d'implémentation de Lex. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

LEXOBJECTS

Spécifie les noms des fichiers d'objets Lex intermédiaires. La valeur de cette variable est généralement gérée par qmake et doit rarement être modifiée.

LEXSOURCES

Spécifie une liste de fichiers source Lex. Toutes les dépendances, les en-têtes et les fichiers source seront automatiquement ajoutés au projet pour la construction de ces fichiers Lex.

Par exemple :

LEXSOURCES = lexer.l

LIBS

Spécifie une liste de bibliothèques à lier au projet. Si vous utilisez les drapeaux Unix -l (library) et -L (library path), qmake gère les bibliothèques correctement sous Windows (c'est-à-dire qu'il transmet le chemin complet de la bibliothèque à l'éditeur de liens). La bibliothèque doit exister pour que qmake trouve le répertoire où se trouve une bibliothèque -l.

Par exemple :

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

Pour spécifier un chemin contenant des espaces, citez le chemin en utilisant la technique décrite dans Whitespace.

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

Par défaut, la liste des bibliothèques stockées dans LIBS est réduite à une liste de noms uniques avant d'être utilisée. Pour modifier ce comportement, ajoutez l'option no_lflags_merge à la variable CONFIG:

CONFIG += no_lflags_merge

LIBS_PRIVATE

Spécifie une liste de bibliothèques à lier de manière privée dans le projet. Le comportement de cette variable est identique à celui de LIBS, sauf que les projets de bibliothèques partagées construits pour Unix n'exposent pas ces dépendances dans leur interface de liaison.

Cela signifie que si le projet C dépend de la bibliothèque B qui dépend de la bibliothèque A de manière privée, mais que C souhaite également utiliser des symboles de A directement, il doit lier A de manière explicite. En d'autres termes, les bibliothèques liées de manière privée ne sont pas exposées de manière transitive au moment de la compilation.

LITERAL_HASH

Cette variable est utilisée chaque fois qu'un caractère de hachage littéral (#) est nécessaire dans une déclaration de variable, par exemple dans le cadre d'un nom de fichier ou d'une chaîne transmise à une application externe.

Par exemple :

# 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))

En utilisant LITERAL_HASH de cette manière, le caractère # peut être utilisé pour construire une URL que la fonction message() imprimera sur la console.

MAKEFILE

Spécifie le nom du fichier Makefile généré. La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

MAKEFILE_GENERATOR

Spécifie le nom du générateur de Makefile à utiliser lors de la génération d'un Makefile. La valeur de cette variable est typiquement gérée en interne par qmake et a rarement besoin d'être modifiée.

MSVCPROJ_*

Ces variables sont gérées en interne par qmake et ne doivent pas être modifiées ou utilisées.

MOC_DIR

Spécifie le répertoire dans lequel tous les fichiers moc intermédiaires doivent être placés.

Par exemple :

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

OBJECTIVE_HEADERS

Définit les fichiers d'en-tête Objective-C++ pour le projet.

qmake détecte automatiquement si moc est requis par les classes dans les en-têtes, et ajoute les dépendances et les fichiers appropriés au projet pour générer et lier les fichiers moc.

Cette variable est similaire à la variable HEADERS, mais elle permet de compiler les fichiers moc générés avec le compilateur Objective-C++.

Voir aussi OBJECTIVE_SOURCES.

SOURCES_OBJECTIVES

Spécifie les noms de tous les fichiers sources Objective-C/C++ du projet.

Cette variable est désormais obsolète, les fichiers Objective-C/C++ (.m et .mm) peuvent être ajoutés à la variable SOURCES.

Voir également OBJECTIVE_HEADERS.

OBJECTS

Cette variable est automatiquement remplie à partir de la variable SOURCES. L'extension de chaque fichier source est remplacée par .o (Unix) ou .obj (Win32). Vous pouvez ajouter des objets à la liste.

OBJECTS_DIR

Spécifie le répertoire dans lequel tous les objets intermédiaires doivent être placés.

Par exemple : post_targetdeps

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

POST_TARGETDEPS

Liste les bibliothèques dont dépend la cible. Certains backends, tels que les générateurs de fichiers de projets Visual Studio et Xcode, ne supportent pas cette variable. En général, cette variable est supportée en interne par ces outils de construction, et elle est utile pour lister explicitement les bibliothèques statiques dépendantes.

Cette liste est placée après toutes les dépendances intégrées (et $$PRE_TARGETDEPS).

PRE_TARGETDEPS

Liste les bibliothèques dont la cible dépend. Certains backends, tels que les générateurs de fichiers de projets Visual Studio et Xcode, ne supportent pas cette variable. En général, cette variable est supportée en interne par ces outils de construction, et elle est utile pour lister explicitement les bibliothèques statiques dépendantes.

Cette liste est placée avant toutes les dépendances intégrées.

PRECOMPILED_HEADER

Indique le fichier d'en-tête pour la création d'un fichier d'en-tête précompilé, afin d'augmenter la vitesse de compilation d'un projet. Les en-têtes précompilés ne sont actuellement supportés que sur certaines plateformes (Windows - tous les types de projets MSVC, Apple - Xcode, Makefile, Unix - gcc 3.3 et plus).

PWD

Spécifie le chemin complet menant au répertoire contenant le fichier en cours d'analyse. Cela peut être utile pour faire référence à des fichiers dans l'arborescence des sources lors de l'écriture de fichiers de projet pour prendre en charge les "shadow builds".

Voir aussi _PRO_FILE_PWD_.

OUT_PWD

Spécifie le chemin complet menant au répertoire où qmake place le Makefile généré.

QM_FILES_RESOURCE_PREFIX

Spécifie le répertoire dans le système de ressources où les fichiers .qm seront rendus disponibles par CONFIG += embed_translations.

La valeur par défaut est :/i18n/.

QM_FILES_INSTALL_PATH

Spécifie le répertoire cible dans lequel seront installés les fichiers .qm générés par CONFIG += lrelease. N'a pas d'effet si CONFIG += embed_translations est défini.

QML_IMPORT_PATH

Cette variable n'est utilisée que par Qt Creator. Si vous avez un module supplémentaire qui est conservé en dehors de votre installation de Qt, vous pouvez spécifier son chemin ici.

Voir Qt Creator: Using QML Modules with Plugins pour plus de détails.

QMLPATHS

Attend une liste de chemins d'importation qui pointent vers les répertoires racines des arborescences des modules QML. Par exemple, si vous avez un emplacement personnalisé pour vos modules QML, vous pouvez le spécifier ici.

QMAKE

Spécifie le nom du programme qmake lui-même et est placé dans les Makefiles générés. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKESPEC

Une variable système qui contient le chemin complet de la configuration de qmake qui est utilisée lors de la génération des Makefiles. La valeur de cette variable est calculée automatiquement.

QMAKE_APPLE_DEVICE_ARCHS

Spécifie une liste d'architectures pour lesquelles construire. Par défaut, un projet est construit pour l'architecture de la machine de développement. Cette variable permet d'outrepasser la valeur par défaut et de construire pour une architecture différente ou de créer des binaires multi-architectures.

Cette variable est généralement spécifiée sur la ligne de commande ou dans le fichier de projet.

Voir Qt pour macOS pour plus d'informations.

QMAKE_AR_CMD

Spécifie la commande à exécuter lors de la création d'une bibliothèque partagée. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_BUNDLE_DATA

Spécifie les données qui seront installées avec un bundle de bibliothèque, et est souvent utilisée pour spécifier une collection de fichiers d'en-tête.

Par exemple, les lignes suivantes ajoutent path/to/header_one.h et path/to/header_two.h à un groupe contenant des informations sur les en-têtes fournis avec le framework :

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

La dernière ligne ajoute les informations sur les en-têtes à la collection de ressources qui seront installées avec le paquet de bibliothèques.

Les paquets de bibliothèques sont créés lorsque l'option lib_bundle est ajoutée à la variable CONFIG.

Voir les notes relatives à la plate-forme pour plus d'informations sur la création d'ensembles de bibliothèques.

Un projet peut également utiliser cette variable pour regrouper des fichiers de traduction d'applications. La syntaxe exacte dépend de l'utilisation par le projet du système de construction de Xcode ou de son nouveau système de construction.

Par exemple, lorsque l'extrait de projet suivant est construit en utilisant le système de construction traditionnel, Xcode ignorera l'emplacement d'origine des fichiers de traduction :

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

Xcode ignorera l'emplacement original de InfoPlist.strings et le fichier sera placé dans le répertoire bundle Resources sous le chemin fourni translations_en.path, donc Resources/en.lproj/InfoPlist.strings

Avec le nouveau système de construction, l'emplacement relatif du fichier est préservé, ce qui signifie que le fichier sera incorrectement placé dans le répertoire sous le chemin d'accès fourni. Resources/en.lproj/en.lproj/InfoPlist.strings

Pour garantir un placement correct du fichier, le projet peut soit déplacer le fichier original pour qu'il ne soit pas dans un sous-répertoire, soit choisir de ne pas spécifier la variable translations_en.path.

# 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

Voir QTBUG-98417 pour plus de détails sur la façon dont le système de construction de Xcode a changé son comportement dans le regroupement des fichiers de traduction.

QMAKE_BUNDLE_EXTENSION

Spécifie l'extension à utiliser pour les bundles de bibliothèques. Cela permet de créer des frameworks avec des extensions personnalisées au lieu de l'extension standard du nom de répertoire .framework.

Par exemple, la définition suivante donnera lieu à un framework avec l'extension .myframework:

QMAKE_BUNDLE_EXTENSION = .myframework

QMAKE_CC

Spécifie le compilateur C qui sera utilisé lors de la construction de projets contenant du code source C. Seul le nom de fichier de l'exécutable du compilateur doit être spécifié tant qu'il se trouve sur un chemin contenu dans la variable PATH lorsque le Makefile est traité.

QMAKE_CFLAGS

Spécifie les drapeaux du compilateur C pour la construction d'un projet. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée. Les drapeaux spécifiques aux modes debug et release peuvent être ajustés en modifiant les variables QMAKE_CFLAGS_DEBUG et QMAKE_CFLAGS_RELEASE, respectivement.

QMAKE_CFLAGS_DEBUG

Spécifie les drapeaux du compilateur C pour les compilations de débogage. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_CFLAGS_RELEASE

Spécifie les drapeaux du compilateur C pour les versions release. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO

Spécifie les drapeaux du compilateur C pour les versions où force_debug_info est défini dans CONFIG. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_CFLAGS_SHLIB

Spécifie les drapeaux du compilateur pour la création d'une bibliothèque partagée. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_CFLAGS_THREAD

Spécifie les drapeaux du compilateur pour la création d'une application multithread. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_CFLAGS_WARN_OFF

Cette variable n'est utilisée que lorsque l'option warn_off CONFIG est activée. La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_CFLAGS_WARN_ON

Cette variable n'est utilisée que lorsque l'option warn_on CONFIG est activée. La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_CLEAN

Spécifie une liste de fichiers générés (par moc et uic, par exemple) et de fichiers objets à supprimer par make clean.

QMAKE_CXX

Spécifie le compilateur C++ qui sera utilisé lors de la construction de projets contenant du code source C++. Seul le nom de fichier de l'exécutable du compilateur doit être spécifié tant qu'il se trouve sur un chemin contenu dans la variable PATH lorsque le Makefile est traité.

QMAKE_CXXFLAGS

Spécifie les drapeaux du compilateur C++ pour la construction d'un projet. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée. Les drapeaux spécifiques aux modes debug et release peuvent être ajustés en modifiant les variables QMAKE_CXXFLAGS_DEBUG et QMAKE_CXXFLAGS_RELEASE, respectivement.

QMAKE_CXXFLAGS_DEBUG

Spécifie les drapeaux du compilateur C++ pour les compilations de débogage. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_CXXFLAGS_RELEASE

Spécifie les drapeaux du compilateur C++ pour les versions release. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO

Spécifie les drapeaux du compilateur C++ pour les versions où force_debug_info est défini dans CONFIG. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_CXXFLAGS_SHLIB

Spécifie les drapeaux du compilateur C++ pour la création d'une bibliothèque partagée. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_CXXFLAGS_THREAD

Spécifie les drapeaux du compilateur C++ pour la création d'une application multithread. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_CXXFLAGS_WARN_OFF

Spécifie les drapeaux du compilateur C++ pour supprimer les avertissements du compilateur. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_CXXFLAGS_WARN_ON

Spécifie les drapeaux du compilateur C++ pour générer des avertissements du compilateur. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_DEVELOPMENT_TEAM

L'identifiant d'une équipe de développement à utiliser pour la signature des certificats et le provisionnement des profils.

QMAKE_DISTCLEAN

Spécifie une liste de fichiers à supprimer par make distclean.

QMAKE_EXTENSION_SHLIB

Contient l'extension pour les bibliothèques partagées. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_EXTENSION_STATICLIB

Contient l'extension pour les bibliothèques statiques partagées. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_EXT_MOC

Contient l'extension utilisée pour les fichiers moc inclus.

Voir aussi Extensions de fichiers.

QMAKE_EXT_UI

Contient l'extension utilisée pour les fichiers Qt Widgets Designer UI.

Voir aussi Extensions de fichiers.

QMAKE_EXT_PRL

Contient l'extension utilisée pour les fichiers PRL créés.

Voir aussi Extensions de fichiers, Dépendances de la bibliothèque.

QMAKE_EXT_LEX

Contient l'extension utilisée pour les fichiers donnés à Lex.

Voir aussi Extensions de fichiers, LEXSOURCES.

QMAKE_EXT_YACC

Contient l'extension utilisée pour les fichiers donnés à Yacc.

Voir aussi Extensions de fichiers, YACCSOURCES.

QMAKE_EXT_OBJ

Contient l'extension utilisée pour les fichiers objets générés.

Voir aussi Extensions de fichiers.

QMAKE_EXT_CPP

Contient des suffixes pour les fichiers qui doivent être interprétés comme du code source C++.

Voir aussi Extensions de fichiers.

QMAKE_EXT_H

Contient des suffixes pour les fichiers qui doivent être interprétés comme des fichiers d'en-tête C.

Voir aussi Extensions de fichiers.

QMAKE_EXTRA_COMPILERS

Spécifie une liste de compilateurs ou de préprocesseurs supplémentaires.

Voir aussi Ajout de compilateurs.

QMAKE_EXTRA_TARGETS

Spécifie une liste de cibles qmake supplémentaires.

Voir aussi Ajout de cibles personnalisées.

QMAKE_FAILED_REQUIREMENTS

Contient la liste des exigences qui ont échoué. La valeur de cette variable est fixée par qmake et ne peut pas être modifiée.

Voir aussi requires() et REQUIRES.

QMAKE_FRAMEWORK_BUNDLE_NAME

Dans un projet de framework, cette variable contient le nom à utiliser pour le framework qui est construit.

Par défaut, cette variable contient la même valeur que la variable TARGET.

Voir Création de frameworks pour plus d'informations sur la création de frameworks et de bundles de bibliothèques.

QMAKE_FRAMEWORK_VERSION

Pour les projets où la cible de construction est un framework macOS, iOS, tvOS ou watchOS, cette variable est utilisée pour spécifier le numéro de version qui sera appliqué au framework construit.

Par défaut, cette variable contient la même valeur que la variable VERSION.

Voir Création de frameworks pour plus d'informations sur la création de frameworks.

QMAKE_HOST

Fournit des informations sur la machine hôte qui exécute qmake. Par exemple, vous pouvez récupérer l'architecture de la machine hôte à partir de QMAKE_HOST.arch.

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

QMAKE_INCDIR

Spécifie la liste des chemins d'accès à l'en-tête du système qui sont ajoutés à INCLUDEPATH. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_INCDIR_EGL

Spécifie l'emplacement des fichiers d'en-tête EGL à ajouter à INCLUDEPATH lors de la construction d'une cible avec le support OpenGL/ES ou OpenVG. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_INCDIR_OPENGL

Spécifie l'emplacement des fichiers d'en-tête OpenGL à ajouter à INCLUDEPATH lors de la construction d'une cible avec le support OpenGL. La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

Si l'implémentation d'OpenGL utilise EGL (la plupart des systèmes OpenGL/ES), alors QMAKE_INCDIR_EGL doit également être défini.

QMAKE_INCDIR_OPENGL_ES2

Cette variable spécifie l'emplacement des fichiers d'en-tête OpenGL à ajouter à INCLUDEPATH lors de la construction d'une cible avec le support d'OpenGL ES 2.

La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

Si l'implémentation d'OpenGL utilise EGL (la plupart des systèmes OpenGL/ES), alors QMAKE_INCDIR_EGL doit également être défini.

QMAKE_INCDIR_OPENVG

Spécifie l'emplacement des fichiers d'en-tête OpenVG à ajouter à INCLUDEPATH lors de la construction d'une cible avec le support OpenVG. La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

Si l'implémentation d'OpenVG utilise EGL, alors QMAKE_INCDIR_EGL peut aussi avoir besoin d'être défini.

QMAKE_INCDIR_X11

Spécifie l'emplacement des chemins des fichiers d'en-tête X11 à ajouter à INCLUDEPATH lors de la construction d'une cible X11. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_INFO_PLIST

Spécifie le nom du fichier de liste de propriétés, .plist, que vous souhaitez inclure dans votre bundle d'applications macOS, iOS, tvOS et watchOS.

Dans le fichier .plist, vous pouvez définir certaines variables que qmake remplacera par les valeurs appropriées :

Si l'on construit pour iOS, et que le fichier .plist contient la clé NSPhotoLibraryUsageDescription, qmake inclura un plugin supplémentaire à la construction qui ajoute le support de l'accès aux photos (à, par exemple, QFile/QFileDialog). Voir la documentation Info.plist d'Apple pour plus d'informations sur cette clé.

QMAKE_IOS_DEPLOYMENT_TARGET

Spécifie la version minimale d'iOS prise en charge par l'application.

Pour plus d'informations, voir Exprimer les versions iOS prises en charge.

QMAKE_IOS_LAUNCH_SCREEN

Spécifie l'écran de lancement utilisé par l'application. Si cette variable n'est pas définie, un écran de lancement par défaut est utilisé.

QMAKE_LFLAGS

Spécifie un ensemble général de drapeaux qui sont transmis à l'éditeur de liens. Si vous devez modifier les drapeaux utilisés pour une plate-forme ou un type de projet particulier, utilisez l'une des variables spécialisées à cet effet au lieu de cette variable.

QMAKE_LFLAGS_CONSOLE

Spécifie les drapeaux de l'éditeur de liens pour la construction de programmes en mode console. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LFLAGS_DEBUG

Spécifie les drapeaux de l'éditeur de liens pour la construction de programmes de débogage. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LFLAGS_PLUGIN

Spécifie les drapeaux de l'éditeur de liens pour la construction des plugins. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LFLAGS_RPATH

Spécifie les drapeaux de l'éditeur de liens nécessaires pour utiliser les valeurs de QMAKE_RPATHDIR.

La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_LFLAGS_REL_RPATH

Spécifie les drapeaux de l'éditeur de liens nécessaires pour activer les chemins relatifs dans QMAKE_RPATHDIR.

La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_REL_RPATH_BASE

Spécifie la chaîne de caractères que l'éditeur de liens dynamiques comprend comme étant l'emplacement de l'exécutable ou de la bibliothèque référente.

La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_LFLAGS_RPATHLINK

Spécifie les drapeaux de l'éditeur de liens nécessaires pour utiliser les valeurs de QMAKE_RPATHLINKDIR.

La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_LFLAGS_RELEASE

Spécifie les drapeaux de l'éditeur de liens pour les compilations release. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO

Spécifie les drapeaux de l'éditeur de liens pour les versions où force_debug_info est défini dans CONFIG. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_LFLAGS_APP

Spécifie les drapeaux de l'éditeur de liens pour la construction d'applications. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LFLAGS_SHLIB

Spécifie les drapeaux de l'éditeur de liens utilisés pour la construction des bibliothèques partagées. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LFLAGS_SONAME

Spécifie les drapeaux de l'éditeur de liens pour définir le nom des objets partagés, tels que .so ou .dll. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LFLAGS_THREAD

Spécifie les drapeaux de l'éditeur de liens pour la construction de projets multithreads. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LFLAGS_WINDOWS

Spécifie les drapeaux de l'éditeur de liens pour la construction des projets d'interface graphique Windows (c'est-à-dire les applications non-consoles). La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LIBDIR

Spécifie une liste de chemins de recherche de bibliothèques pour tous les projets. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

Pour spécifier des chemins de recherche supplémentaires dans les fichiers de projet, utilisez LIBS comme ceci, à la place :

LIBS += -L/path/to/libraries

QMAKE_LIBDIR_POST

Spécifie une liste de chemins de recherche de la bibliothèque système pour tous les projets. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LIBDIR_FLAGS

Spécifie l'emplacement de tous les répertoires de bibliothèques avec le préfixe -L. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_LIBDIR_EGL

Spécifie l'emplacement du répertoire de la bibliothèque EGL, lorsque EGL est utilisé avec OpenGL/ES ou OpenVG. La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_LIBDIR_OPENGL

Spécifie l'emplacement du répertoire de la bibliothèque OpenGL. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

Si l'implémentation d'OpenGL utilise EGL (la plupart des systèmes OpenGL/ES), alors QMAKE_LIBDIR_EGL doit également être défini.

QMAKE_LIBDIR_OPENVG

Spécifie l'emplacement du répertoire de la bibliothèque OpenVG. La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

Si l'implémentation d'OpenVG utilise EGL, alors QMAKE_LIBDIR_EGL peut aussi avoir besoin d'être défini.

QMAKE_LIBDIR_X11

Spécifie l'emplacement du répertoire de la bibliothèque X11. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et n'a que rarement besoin d'être modifiée.

QMAKE_LIBS

Spécifie les bibliothèques supplémentaires avec lesquelles chaque projet doit établir des liens. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

Pour spécifier des bibliothèques dans un fichier de projet, utilisez LIBS à la place.

QMAKE_LIBS_PRIVATE

Spécifie les bibliothèques privées supplémentaires avec lesquelles chaque projet doit établir des liens. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

Pour spécifier des bibliothèques privées dans un fichier de projet de bibliothèque, utilisez LIBS_PRIVATE à la place.

QMAKE_LIBS_EGL

Spécifie toutes les bibliothèques EGL lors de la construction de Qt OpenGL/ES ou OpenVG. La valeur de cette variable est typiquement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée. La valeur habituelle est -lEGL.

QMAKE_LIBS_OPENGL

Spécifie toutes les bibliothèques OpenGL. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

Si l'implémentation OpenGL utilise EGL (la plupart des systèmes OpenGL/ES), alors QMAKE_LIBS_EGL doit aussi être définie.

QMAKE_LIBS_OPENGL_ES1, QMAKE_LIBS_OPENGL_ES2

Ces variables spécifient toutes les bibliothèques OpenGL pour OpenGL ES 1 et OpenGL ES 2.

La valeur de ces variables est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

Si l'implémentation d'OpenGL utilise EGL (la plupart des systèmes OpenGL/ES), alors QMAKE_LIBS_EGL peut également être nécessaire.

QMAKE_LIBS_OPENVG

Spécifie toutes les bibliothèques OpenVG. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée. La valeur habituelle est -lOpenVG.

Certains moteurs OpenVG sont implémentés au-dessus d'OpenGL. Ceci sera détecté au moment de la configuration et QMAKE_LIBS_OPENGL sera implicitement ajouté à QMAKE_LIBS_OPENVG partout où les bibliothèques OpenVG sont liées.

Si l'implémentation d'OpenVG utilise EGL, alors QMAKE_LIBS_EGL peut également être nécessaire.

QMAKE_LIBS_THREAD

Spécifie toutes les bibliothèques qui doivent être liées lors de la construction d'une cible multithread. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_LIBS_X11

Spécifie toutes les bibliothèques X11. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LIB_FLAG

Cette variable n'est pas vide si le modèle lib est spécifié. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LINK

Spécifie l'éditeur de liens qui sera utilisé lors de la construction de projets basés sur des applications. Seul le nom de fichier de l'exécutable de l'éditeur de liens doit être spécifié tant qu'il se trouve sur un chemin contenu dans la variable PATH lorsque le Makefile est traité. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_LINK_SHLIB_CMD

Spécifie la commande à exécuter lors de la création d'une bibliothèque partagée. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LN_SHLIB

Spécifie la commande à exécuter lors de la création d'un lien vers une bibliothèque partagée. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_LRELEASE_FLAGS

Liste d'options supplémentaires passées à lrelease lorsqu'elles sont activées par CONFIG += lrelease.

QMAKE_OBJECTIVE_CFLAGS

Spécifie les drapeaux du compilateur Objective C/C++ pour la construction d'un projet. Ces drapeaux sont utilisés en plus de QMAKE_CFLAGS et QMAKE_CXXFLAGS.

QMAKE_POST_LINK

Spécifie la commande à exécuter après avoir lié la TARGET ensemble. Cette variable est normalement vide et rien n'est donc exécuté.

QMAKE_PRE_LINK

Spécifie la commande à exécuter avant de lier la TARGET entre elles. Cette variable est normalement vide et n'est donc pas exécutée.

QMAKE_PROJECT_NAME

Détermine le nom du projet lors de la génération de fichiers de projet pour les IDE. La valeur par défaut est le nom de la cible. La valeur de cette variable est généralement gérée par qmake et doit rarement être modifiée.

QMAKE_PROVISIONING_PROFILE

L'UUID d'un profil de provisionnement valide. À utiliser avec QMAKE_DEVELOPMENT_TEAM pour spécifier le profil de provisionnement.

QMAKE_MAC_SDK

Cette variable est utilisée sur macOS lors de la construction de binaires universels.

QMAKE_MACOSX_DEPLOYMENT_TARGET

Spécifie la version minimale de macOS prise en charge par l'application.

Pour plus d'informations, voir Configurations prises en charge par macOS.

QMAKE_MAKEFILE

Spécifie le nom du Makefile à créer. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

QMAKE_QMAKE

Contient le chemin absolu de l'exécutable qmake.

QMAKE_RESOURCE_FLAGS

Cette variable est utilisée pour personnaliser la liste des options passées à qmake dans chacune des règles de construction où il est utilisé. Resource Compiler dans chacune des règles de construction où elle est utilisée. Par exemple, la ligne suivante garantit que les options -threshold et -compress sont utilisées avec des valeurs particulières chaque fois que rcc est invoqué :

QMAKE_RESOURCE_FLAGS += -threshold 0 -compress 9

QMAKE_RPATHDIR

Spécifie une liste de chemins d'accès aux bibliothèques qui sont ajoutés à l'exécutable au moment de la liaison afin que les chemins soient recherchés de préférence au moment de l'exécution.

Lorsque des chemins relatifs sont spécifiés, qmake les transforme en une forme comprise par l'éditeur de liens dynamiques comme étant relative à l'emplacement de l'exécutable ou de la bibliothèque référente. Ceci n'est supporté que par certaines plates-formes (actuellement Linux et les plates-formes basées sur Darwin) et est détectable en vérifiant si QMAKE_REL_RPATH_BASE est défini.

QMAKE_RPATHLINKDIR

Spécifie une liste de chemins d'accès aux bibliothèques pour que l'éditeur de liens statiques recherche les dépendances implicites des bibliothèques partagées. Pour plus d'informations, voir la page de manuel de ld(1).

QMAKE_RUN_CC

Spécifie la règle individuelle nécessaire pour construire un objet. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_RUN_CC_IMP

Spécifie la règle individuelle nécessaire à la construction d'un objet. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_RUN_CXX

Spécifie la règle individuelle nécessaire pour construire un objet. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_RUN_CXX_IMP

Spécifie la règle individuelle nécessaire pour construire un objet. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_SONAME_PREFIX

Si elle est définie, la valeur de cette variable est utilisée comme chemin à ajouter à l'identifiant SONAME de la bibliothèque partagée construite. L'identifiant SONAME est l'identifiant que l'éditeur de liens dynamiques utilisera ultérieurement pour référencer la bibliothèque. En général, cette référence peut être un nom de bibliothèque ou un chemin complet de bibliothèque. Sur macOS, iOS, tvOS et watchOS, le chemin peut être spécifié de manière relative en utilisant les caractères génériques suivants :

Dans la plupart des cas, l'utilisation de @rpath est suffisante et recommandée :

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

Toutefois, le préfixe peut également être spécifié à l'aide de différents caractères génériques ou d'un chemin absolu, tel que l'un des suivants :

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

Pour plus d'informations, voir la documentation dyld sur les noms d'installation des bibliothèques dynamiques.

QMAKE_TARGET

Spécifie le nom de la cible du projet. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

QMAKE_TARGET_COMPANY

Windows uniquement. Spécifie la société pour la cible du projet ; ceci est utilisé le cas échéant pour mettre le nom de la société dans les propriétés de l'application. Ce paramètre n'est utilisé que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

QMAKE_TARGET_DESCRIPTION

Windows uniquement. Spécifie la description de la cible du projet ; elle est utilisée, le cas échéant, pour mettre la description dans les propriétés de l'application. Elle n'est utilisée que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

QMAKE_TARGET_COPYRIGHT

Windows uniquement. Spécifie les informations de copyright pour la cible du projet ; ceci est utilisé le cas échéant pour mettre les informations de copyright dans les propriétés de l'application. Elle n'est utilisée que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

QMAKE_TARGET_PRODUCT

Windows uniquement. Spécifie le produit pour la cible du projet ; ceci est utilisé le cas échéant pour mettre le produit dans les propriétés de l'application. Ce paramètre n'est utilisé que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

QMAKE_TARGET_ORIGINAL_FILENAME

Windows uniquement. Spécifie le nom de fichier original pour la cible du projet ; il est utilisé, le cas échéant, pour indiquer le nom de fichier original dans les propriétés de l'application. Ce nom n'est utilisé que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

QMAKE_TARGET_INTERNALNAME

Windows uniquement. Spécifie le nom interne de la cible du projet ; il est utilisé, le cas échéant, pour indiquer le nom interne dans les propriétés de l'application. Ce nom n'est utilisé que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

QMAKE_TARGET_COMMENTS

Windows uniquement. Spécifie les commentaires pour la cible du projet ; ceci est utilisé le cas échéant pour mettre les commentaires dans les propriétés de l'application. Ce paramètre n'est utilisé que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

QMAKE_TARGET_TRADEMARKS

Windows uniquement. Spécifie les informations de marque pour la cible du projet ; ceci est utilisé le cas échéant pour mettre les informations de marque dans les propriétés de l'application. Elle n'est utilisée que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

QMAKE_MANIFEST

Windows uniquement. Spécifie le fichier manifeste pour la cible du projet. Il n'est utilisé que si les variables RC_FILE et RES_FILE ne sont pas définies. N'oubliez pas de supprimer embed_manifest_exe et embed_manifest_dll de la variable CONFIG, sinon il y aura conflit avec celui généré par le compilateur.

QMAKE_TVOS_DEPLOYMENT_TARGET

Spécifie la version minimale de tvOS que l'application prend en charge.

Pour plus d'informations, voir Exprimer les versions iOS prises en charge.

QMAKE_UIC_FLAGS

Cette variable est utilisée pour personnaliser la liste des options transmises à la commande User Interface Compiler dans chacune des règles de construction où elle est utilisée.

QMAKE_WATCHOS_DEPLOYMENT_TARGET

Spécifie la version minimale de watchOS que l'application supporte.

Pour plus d'informations, voir Exprimer les versions iOS supportées.

QML_IMPORT_MAJOR_VERSION

Indique la version majeure à utiliser pour les enregistrements de types QML générés automatiquement. Pour plus d'informations, voir Définir des types QML à partir de C++.

QML_IMPORT_MINOR_VERSION

Lors de l'enregistrement automatique des types QML définis en C++, enregistrer une version supplémentaire du module en utilisant cette version mineure. En général, les versions mineures à enregistrer sont déduites des méta-objets.

Vous pouvez utiliser cette variable si les métaobjets n'ont pas changé et que vous souhaitez toujours importer un module QML avec un numéro de version mineure plus récent. Par exemple, les métaobjets de MyModule sont au niveau 1.1, mais vous souhaitez importer le module en tant que 1.3.

QML_IMPORT_VERSION

Spécifie QML_IMPORT_MAJOR_VERSION et QML_IMPORT_MINOR_VERSION en tant que chaîne de version <major>.<minor>.

QML_IMPORT_NAME

Spécifie le nom du module à utiliser pour les enregistrements de types QML générés automatiquement. Pour plus d'informations, voir Définir des types QML à partir de C++.

QML_FOREIGN_METATYPES

Spécifie des fichiers JSON supplémentaires contenant des métatypes à prendre en compte lors de la génération des fichiers qmltypes. A utiliser lorsque des bibliothèques externes fournissent des types qui sont exposés à QML, soit directement, soit en tant que types de base ou propriétés d'autres types. Les types Qt seront automatiquement pris en compte et n'ont pas besoin d'être ajoutés ici.

QT

Spécifie les modules Qt utilisés par votre projet. Pour connaître la valeur à ajouter pour chaque module, consultez la documentation du module.

Au niveau de l'implémentation C++, l'utilisation d'un module Qt rend ses en-têtes disponibles pour l'inclusion et entraîne sa liaison avec le binaire.

Par défaut, QT contient core et gui, ce qui permet de construire des applications GUI standard sans autre configuration.

Si vous souhaitez construire un projet sans le module Qt GUI vous devez exclure la valeur gui à l'aide de l'opérateur "-=". La ligne suivante aboutira à la construction d'un projet Qt minimal :

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

Si votre projet est un plugin Qt Widgets Designer, utilisez la valeur uiplugin pour spécifier que le projet doit être construit comme une bibliothèque, mais avec un support de plugin spécifique pour Qt Widgets Designer. Pour plus d'informations, voir Construction et installation du plugin.

QTPLUGIN

Spécifie une liste de noms de plugins statiques Qt qui doivent être liés à une application afin qu'ils soient disponibles en tant que ressources intégrées.

qmake ajoute automatiquement les plugins qui sont typiquement nécessaires aux modules Qt utilisés (voir QT). Les paramètres par défaut sont conçus pour offrir une expérience optimale dès la sortie de la boîte. Voir Static Plugins pour une liste des plugins disponibles, et les moyens d'outrepasser la liaison automatique.

Cette variable n'a actuellement aucun effet lors de l'édition de liens avec une version partagée/dynamique de Qt, ou lors de l'édition de liens avec des bibliothèques. Elle pourra être utilisée ultérieurement pour le déploiement de plugins dynamiques.

QT_VERSION

Contient la version actuelle de Qt.

QT_MAJOR_VERSION

Contient la version majeure actuelle de Qt.

QT_MINOR_VERSION

Contient la version mineure actuelle de Qt.

QT_PATCH_VERSION

Contient la version actuelle du correctif de Qt.

RC_FILE

Windows uniquement. Spécifie le nom du fichier de ressources Windows (.rc) pour la cible. Voir Ajout de fichiers de ressources Windows.

RC_CODEPAGE

Windows uniquement. Indique la page de code qui doit être spécifiée dans un fichier .rc généré. Cette variable n'est utilisée que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne le sont pas.

RC_DEFINES

Windows uniquement. qmake ajoute les valeurs de cette variable en tant que macros de préprocesseur RC (option /d). Si cette variable n'est pas définie, la variable DEFINES est utilisée à la place.

RC_DEFINES += USE_MY_STUFF

RC_ICONS

Windows uniquement. Spécifie les icônes qui doivent être incluses dans un fichier .rc généré. Cette variable n'est utilisée que si les variables RC_FILE et RES_FILE ne sont pas définies. Pour plus de détails sur la génération des fichiers .rc, voir les Notes de Plateforme.

RC_LANG

Windows uniquement. Indique la langue qui doit être spécifiée dans un fichier .rc généré. Cette variable n'est utilisée que si la variable VERSION ou RC_ICONS est définie et que les variables RC_FILE et RES_FILE ne sont pas définies.

RC_INCLUDEPATH

Spécifie les chemins d'inclusion qui sont transmis à l'application Windows Resource Compiler.

RCC_DIR

Spécifie le répertoire des fichiers de sortie de Qt Resource Compiler.

Par exemple :

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

REQUIRES

Spécifie une liste de valeurs qui sont évaluées en tant que conditions. Si l'une des conditions est fausse, qmake ignore ce projet (et ses sous-répertoires) lors de la construction.

RESSOURCES

Spécifie le nom des fichiers de collecte des ressources (qrc) pour la cible. Pour plus d'informations sur les fichiers de collecte de ressources, voir Le système de ressources Qt.

RES_FILE

Windows uniquement. Spécifie le nom du fichier de sortie du compilateur de ressources Windows pour cette cible. Voir RC_FILE et Ajouter des fichiers de ressources Windows.

La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

SOURCES

Spécifie les noms de tous les fichiers sources du projet.

Note sur les fichiers sources inclus

Par défaut, QMake analyse les fichiers sources à la recherche de dépendances et exclut automatiquement les fichiers .cpp qui sont inclus dans d'autres fichiers .cpp afin d'éviter les erreurs de compilation et d'édition de liens en double. Cette exclusion automatique comporte d'importantes limitations :

• L'exclusion se produit sans tenir compte des conditionnels du préprocesseur (#ifdef, #ifndef, etc.).
• Un fichier .cpp #included situé n'importe où dans le projet sera exclu de SOURCES, même si l'inclusion est conditionnelle.

Pour forcer la compilation des fichiers exclus, ajoutez CONFIG += compile_included_sources à votre fichier .pro. Sinon, supprimez les fichiers inclus de SOURCES et assurez-vous qu'ils ne sont compilés que par le biais de leur fichier d'inclusion. Ceci s'applique à tous les fichiers dont l'extension est QMAKE_EXT_CPP.

Par exemple :

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

Voir aussi HEADERS.

SUBDIRS

Cette variable, lorsqu'elle est utilisée avec le modèle subdirs, spécifie les noms de tous les sous-répertoires ou fichiers de projet qui contiennent des parties du projet qui doivent être construites. Chaque sous-répertoire spécifié à l'aide de cette variable doit contenir son propre fichier de projet.

Il est recommandé que le fichier de projet de chaque sous-répertoire ait le même nom de base que le sous-répertoire lui-même, car cela permet d'omettre le nom du fichier. Par exemple, si le sous-répertoire s'appelle myapp, le fichier de projet dans ce répertoire doit s'appeler myapp.pro.

Vous pouvez également spécifier un chemin relatif vers un fichier .pro dans n'importe quel répertoire. Il est fortement recommandé de ne spécifier que des chemins dans le répertoire parent du projet en cours ou dans ses sous-répertoires.

Par exemple :

SUBDIRS = kernel \
          tools \
          myapp

Si vous devez vous assurer que les sous-répertoires sont construits dans un ordre particulier, utilisez le modificateur .depends sur les éléments SUBDIRS concernés.

Par exemple, la configuration ci-dessus permet de s'assurer que le site est construit dans un ordre particulier :

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

La configuration ci-dessus garantit que my_library est construit avant my_executable et que my_executable est construit avant tests. Cependant, doc peut être construit en parallèle avec les autres sous-répertoires, ce qui accélère le processus de construction.

Outre la définition de l'ordre de construction, il est possible de modifier le comportement par défaut de SUBDIRS en attribuant des modificateurs supplémentaires aux éléments de SUBDIRS. Les modificateurs pris en charge sont les suivants :

Par exemple, définir deux sous-répertoires, qui résident tous deux dans un répertoire différent de la valeur SUBDIRS, et l'un des sous-répertoires doit être construit avant l'autre :

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

TARGET

Spécifie le nom du fichier cible. Contient par défaut le nom de base du fichier du projet.

Par exemple, le fichier de projet ci-dessus produirait un fichier exécutable :

TEMPLATE = app
TARGET = myapp
SOURCES = main.cpp

Le fichier projet ci-dessus produirait un exécutable nommé myapp sous Unix et myapp.exe sous Windows.

TARGET_EXT

Spécifie l'extension de TARGET. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et a rarement besoin d'être modifiée.

TARGET_x

Spécifie l'extension de TARGET avec un numéro de version majeure. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

TARGET_x.y.z

Spécifie l'extension de TARGET avec un numéro de version. La valeur de cette variable est généralement gérée par qmake ou qmake.conf et doit rarement être modifiée.

TEMPLATE

Spécifie le nom du modèle à utiliser lors de la génération du projet. Les valeurs autorisées sont les suivantes :

Par exemple, le modèle peut être remplacé en spécifiant un nouveau type de modèle avec l'option de ligne de commande

TEMPLATE = lib
SOURCES = main.cpp
TARGET = mylib

Le modèle peut être remplacé en spécifiant un nouveau type de modèle avec l'option de ligne de commande -t. Cette option remplace le type de modèle après le traitement du fichier .pro. Avec les fichiers .pro qui utilisent le type de modèle pour déterminer comment le projet est construit, il est nécessaire de déclarer TEMPLATE sur la ligne de commande plutôt que d'utiliser l'option -t.

TRADUCTIONS

Spécifie une liste de fichiers de traduction (.ts) qui contiennent des traductions du texte de l'interface utilisateur dans des langues autres que la langue maternelle.

Les fichiers de traduction contenus dans TRANSLATIONS seront traités à la fois par l'outil lrelease et par l'outil lupdate. Utilisez EXTRA_TRANSLATIONS si vous souhaitez que seul lrelease traite un fichier.

Vous pouvez utiliser CONFIG += lrelease pour compiler automatiquement les fichiers pendant la construction, et CONFIG += lrelease embed_translations pour les rendre disponibles dans The Qt Resource System.

Voir le manuelQt Linguist pour plus d'informations sur l'internationalisation (i18n) et la localisation (l10n) avec Qt.

TR_EXCLUDE

Spécifie une liste de chemins (fichiers source, sous-répertoires et chemins d'inclusion C++) à exclure de la manipulation dans lupdate. Les chemins peuvent contenir des caractères génériques. Les chemins relatifs sont considérés comme relatifs à _PRO_FILE_PWD_.

Par exemple, pour exclure les fichiers source :

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

Pour exclure des sous-répertoires d'un projet SUBDIRS:

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

Pour accélérer l'analyseur C++ de lupdate, exclure les chemins d'inclusion :

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

UI_DIR

Spécifie le répertoire dans lequel tous les fichiers intermédiaires d'uic doivent être placés.

Par exemple :

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

VERSION

Spécifie le numéro de version de l'application si le modèle app est spécifié ou le numéro de version de la bibliothèque si le modèle lib est spécifié.

Sous Windows, déclenche la génération automatique d'un fichier .rc si les variables RC_FILE et RES_FILE ne sont pas définies. Le fichier .rc généré aura les entrées FILEVERSION et PRODUCTVERSION remplies avec major, minor, patch level et build number. Chaque numéro doit être compris entre 0 et 65535. Vous trouverez plus de détails sur la génération des fichiers .rc dans les notes de la plate-forme.

En voici un exemple :

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

VERSION_PE_HEADER

Windows uniquement. Spécifie le numéro de version que l'éditeur de liens Windows place dans l'en-tête du fichier .exe ou .dll via l'option /VERSION. Seules une version majeure et une version mineure peuvent être spécifiées. Si l'option VERSION_PE_HEADER n'est pas définie, elle reprend les versions majeure et mineure de VERSION (si elle est définie).

VERSION_PE_HEADER = 1.2

VER_MAJ

Indique le numéro de version majeure de la bibliothèque si le modèle lib est spécifié.

VER_MIN

Indique le numéro de version mineure de la bibliothèque si le modèle lib est spécifié.

VER_PAT

Indique le numéro de version du correctif de la bibliothèque si le modèle lib est spécifié.

VPATH

Indique à qmake où rechercher les fichiers qu'il ne peut pas ouvrir. Par exemple, si qmake recherche SOURCES et trouve une entrée qu'il ne peut pas ouvrir, il parcourt toute la liste VPATH pour voir s'il peut trouver le fichier par lui-même.

Voir aussi DEPENDPATH.

WINDOWS_TARGET_PLATFORM_VERSION

Spécifie la version de Windows ciblée ; cela correspond à la balise WindowsTargetPlatformVersion dans les fichiers vcxproj.

Sous Windows desktop, la valeur par défaut est la valeur de la variable d'environnement WindowsSDKVersion.

WINDOWS_TARGET_PLATFORM_MIN_VERSION

Spécifie la version minimale de la plate-forme cible Windows ; cela correspond à la balise WindowsTargetPlatformMinVersion dans les fichiers vcxproj.

La valeur par défaut est WINDOWS_TARGET_PLATFORM_VERSION.

YACCSOURCES

Spécifie une liste de fichiers source Yacc à inclure dans le projet. Toutes les dépendances, les en-têtes et les fichiers source seront automatiquement inclus dans le projet.

Par exemple :

YACCSOURCES = moc.y

_PRO_FILE_

Contient le chemin d'accès au fichier de projet utilisé.

Par exemple, la ligne suivante permet d'écrire dans la console l'emplacement du fichier de projet :

message($$_PRO_FILE_)

_PRO_FILE_PWD

Contient le chemin d'accès au répertoire contenant le fichier de projet utilisé.

Par exemple, la ligne suivante fait en sorte que l'emplacement du répertoire contenant le fichier de projet soit écrit dans la console :

message($$_PRO_FILE_PWD_)