Création de types de projets communs

Ce chapitre décrit comment configurer les fichiers de projet qmake pour trois types de projets courants basés sur Qt : application, bibliothèque et plugin. Bien que tous les types de projets utilisent un grand nombre de variables identiques, chacun d'entre eux utilise des variables spécifiques au projet pour personnaliser les fichiers de sortie.

Les variables spécifiques à la plate-forme ne sont pas décrites ici. Pour plus d'informations, voir Qt pour Windows - Deployment et Qt pour macOS.

Construire une application

Le modèle app indique à qmake de générer un Makefile qui construira une application. Avec ce modèle, le type d'application peut être spécifié en ajoutant l'une des options suivantes à la définition de la variable CONFIG:

Lorsque vous utilisez ce modèle, les variables système qmake suivantes sont reconnues. Vous devez les utiliser dans votre fichier .pro pour spécifier des informations sur votre application. Pour d'autres variables système dépendant de la plate-forme, vous pouvez consulter les notes relatives à la plate-forme.

• HEADERS - Une liste de fichiers d'en-tête pour l'application.
• SOURCES - Liste des fichiers source C++ de l'application.
• FORMS - Liste des fichiers d'interface utilisateur de l'application (créés à l'aide de Qt Widgets Designer).
• LEXSOURCES - Liste des fichiers source Lex de l'application.
• YACCSOURCES - Liste des fichiers source Yacc pour l'application.
• TARGET - Nom de l'exécutable de l'application. Par défaut, il s'agit du nom du fichier de projet. (L'extension, le cas échéant, est ajoutée automatiquement).
• DESTDIR - Répertoire dans lequel l'exécutable cible est placé.
• DEFINES - Liste des définitions de pré-processeurs supplémentaires nécessaires à l'application.
• INCLUDEPATH - Liste des chemins d'inclusion supplémentaires nécessaires à l'application.
• DEPENDPATH - Chemin de recherche des dépendances pour l'application.
• VPATH - Chemin de recherche des fichiers fournis.
• DEF_FILE - Windows uniquement : Un fichier .def avec lequel l'application doit être liée.

Vous ne devez utiliser que les variables système pour lesquelles vous disposez de valeurs. Par exemple, si vous n'avez pas de INCLUDEPATH supplémentaire, vous n'avez pas besoin d'en spécifier. qmake ajoutera les valeurs par défaut nécessaires. Un exemple de fichier de projet pourrait ressembler à ceci :

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

Pour les éléments à valeur unique, tels que le modèle ou le répertoire de destination, nous utilisons "=" ; mais pour les éléments à valeur multiple, nous utilisons "+=" pour les ajouter aux éléments existants de ce type. L'utilisation de "=" remplace la valeur de la variable par la nouvelle valeur. Par exemple, si nous écrivons DEFINES=USE_MY_STUFF, toutes les autres définitions sont supprimées.

Construction d'un scénario de test

Un projet de testcase est un projet app destiné à être exécuté en tant que test automatisé. Tout app peut être marqué comme testcase en ajoutant la valeur testcase à la variable CONFIG.

Pour les projets testcase, qmake insère une cible check dans le Makefile généré. Cette cible exécutera l'application. Le test est considéré comme réussi s'il se termine par un code de sortie égal à zéro.

La cible check parcourt automatiquement les projets SUBDIRS. Cela signifie qu'il est possible de lancer une commande make check à partir d'un projet SUBDIRS pour exécuter une suite de tests complète.

L'exécution de la cible check peut être personnalisée par certaines variables du Makefile. Ces variables sont les suivantes :

# Run tests through test-wrapper and use JUnit XML output format.
# In this example, test-wrapper is a fictional wrapper script which terminates
# a test if it does not complete within the amount of seconds set by "--timeout".
# The "-o result.xml,junitxml" options are interpreted by QTestLib.
make check TESTRUNNER="test-wrapper --timeout 120" TESTARGS="-o result.xml,junitxml"

Les projets de testcase peuvent être personnalisés davantage avec les options CONFIG suivantes :

Les cas de test seront souvent écrits avec QTest ou TestCase, mais il n'est pas obligatoire d'utiliser CONFIG+=testcase et make check. La seule exigence principale est que le programme de test sorte avec un code de sortie nul en cas de succès, et un code de sortie non nul en cas d'échec.

Construction d'une bibliothèque

Le modèle lib indique à qmake de générer un Makefile qui construira une bibliothèque. Lorsque vous utilisez ce modèle, la variable VERSION est prise en charge, en plus des variables système que le modèle app prend en charge. Utilisez les variables dans votre fichier .pro pour spécifier des informations sur la bibliothèque.

Lorsque vous utilisez le modèle lib, les options suivantes peuvent être ajoutées à la variable CONFIG pour déterminer le type de bibliothèque qui est construit :

L'option suivante peut également être définie pour fournir des informations supplémentaires sur la bibliothèque.

• VERSION - Le numéro de version de la bibliothèque cible. Par exemple, 2.3.1.

Le nom du fichier cible de la bibliothèque dépend de la plate-forme. Par exemple, sur X11, macOS et iOS, le nom de la bibliothèque sera préfixé par lib. Sous Windows, aucun préfixe n'est ajouté au nom du fichier.

Création d'un plugin

Les plugins sont construits en utilisant le modèle lib, comme décrit dans la section précédente. Cela indique à qmake de générer un Makefile pour le projet qui construira un plugin sous une forme appropriée pour chaque plateforme, habituellement sous la forme d'une bibliothèque. Comme pour les bibliothèques ordinaires, la variable VERSION est utilisée pour spécifier des informations sur le greffon.

• VERSION - Le numéro de version de la bibliothèque cible. Par exemple, 2.3.1.

Construire un plugin Qt Widgets Designer

Qt Widgets Designer Les plugins sont construits en utilisant un ensemble spécifique de paramètres de configuration qui dépendent de la façon dont Qt a été configuré pour votre système. Pour plus de commodité, ces paramètres peuvent être activés en ajoutant designer à la variable QT. Par exemple :

QT          += widgets designer

Voir Qt Widgets Designer Examples pour plus d'exemples de projets basés sur des plugins.

Construction et installation en modes Debug et Release

Il est parfois nécessaire de construire un projet à la fois en mode debug et en mode release. Bien que la variable CONFIG puisse contenir les options debug et release, seule l'option spécifiée en dernier est appliquée.

Construire dans les deux modes

Pour permettre à un projet d'être construit dans les deux modes, vous devez ajouter l'option debug_and_release à la variable CONFIG:

CONFIG += debug_and_release

CONFIG(debug, debug|release) {
    TARGET = debug_binary
} else {
    TARGET = release_binary
}

La portée dans l'extrait ci-dessus modifie la cible de construction dans chaque mode pour s'assurer que les cibles résultantes ont des noms différents. Le fait de fournir des noms différents pour les cibles permet de s'assurer qu'une cible n'écrasera pas l'autre.

Lorsque qmake traite le fichier de projet, il génère une règle Makefile pour permettre au projet d'être construit dans les deux modes. Cette règle peut être invoquée de la manière suivante :

make all

L'option build_all peut être ajoutée à la variable CONFIG dans le fichier de projet pour s'assurer que le projet est construit dans les deux modes par défaut :

CONFIG += build_all

Cela permet au fichier Makefile d'être traité en utilisant la règle par défaut :

make

Installation dans les deux modes

L'option build_all garantit également que les deux versions de la cible seront installées lorsque la règle d'installation est invoquée :

make install

Il est possible de personnaliser les noms des cibles de compilation en fonction de la plateforme cible. Par exemple, une bibliothèque ou un plugin peut être nommé selon une convention différente sous Windows et sous Unix :

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

Le comportement par défaut dans l'extrait ci-dessus est de modifier le nom utilisé pour la cible de compilation lors de la compilation en mode débogage. Une clause else pourrait être ajoutée à la portée pour faire la même chose en mode release. En l'état, le nom de la cible n'est pas modifié.