Compilation de types de projets courants

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 en grande partie les mêmes variables, chacun d'entre eux utilise des variables spécifiques au projet pour personnaliser les fichiers de sortie.

Les variables spécifiques à chaque plateforme ne sont pas décrites ici. Pour plus d’informations, consultez Qt pour Windows - Déploiement et Qt pour macOS.

Compilation d'une application

Le modèle « app » indique à qmake de générer un Makefile qui permettra de compiler 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 concernant votre application. Pour connaître les variables système supplémentaires spécifiques à la plate-forme, vous pouvez consulter les Notes sur les plates-formes.

• HEADERS - Liste des fichiers d'en-tête de 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 d'Qt Widgets Designer).
• LEXSOURCES - Liste des fichiers source Lex de l'application.
• YACCSOURCES - Liste des fichiers source Yacc de 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éprocesseur 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 pour trouver les fichiers fournis.
• DEF_FILE - Windows uniquement : un fichier .def à lier à l'application.

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

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, on utilise « = » ; mais pour les éléments à valeurs multiples, on utilise « += » afin d’ajouter des éléments à ceux déjà existants de ce type. L’utilisation de « = » remplace la valeur de la variable par la nouvelle valeur. Par exemple, si l’on écrit « DEFINES=USE_MY_STUFF », toutes les autres définitions sont supprimées.

Création d’un cas de test

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

Pour les projets de cas de test, qmake insérera 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 avec un code de sortie égal à zéro.

La cible check parcourt automatiquement de manière récursive les projets SUBDIRS. Cela signifie qu’il est possible d’exécuter la commande make check depuis un projet SUBDIRS pour lancer l’ensemble d’une suite de tests.

L’exécution de la cible « check » peut être personnalisée à l’aide de 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 cas de test peuvent être personnalisés davantage à l’aide des options d’ CONFIG suivantes :

Les cas de test sont souvent écrits avec les options « 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 se termine avec un code de sortie égal à zéro en cas de réussite, et avec un code de sortie différent de zéro en cas d’échec.

Compilation d’une bibliothèque

Le modèle lib indique à qmake de générer un Makefile qui permettra de compiler une bibliothèque. Lorsque vous utilisez ce modèle, la variable VERSION est prise en charge, en plus des variables système prises en charge par le modèle app. Utilisez ces 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 à construire :

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 plateforme. Par exemple, sous 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.

Compilation d'un plugin

Les plug-ins sont créés à l’aide du 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 permettra de créer un plug-in sous une forme adaptée à chaque plateforme, généralement sous la forme d’une bibliothèque. Comme pour les bibliothèques classiques, la variable VERSION est utilisée pour spécifier des informations concernant le plug-in.

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

Compilation d’un plugin Designer pour l’ Qt Widgets

Qt Widgets Les plugins Qt Designer sont compilés à l’aide d’un ensemble spécifique de paramètres de configuration qui dépendent de la manière dont Qt a été configuré sur 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

Consultez les exemples de Designer d'Qt Widgets pour découvrir d'autres exemples de projets basés sur des plug-ins.

Compilation et installation en modes débogage et production

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

Compilation dans les deux modes

Pour permettre la compilation d’un projet 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 compilation dans chaque mode afin de garantir que les cibles résultantes portent des noms différents. Le fait de donner des noms différents aux cibles garantit qu’aucune ne remplace l’autre.

Lorsque qmake traite le fichier de projet, il génère une règle Makefile permettant de compiler le projet dans les deux modes. Celle-ci 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 garantir que le projet soit compilé dans les deux modes par défaut :

CONFIG += build_all

Cela permet de traiter le Makefile à l’aide de 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 sera invoquée :

make install

Il est possible de personnaliser les noms des cibles de compilation en fonction de la plate-forme cible. Par exemple, une bibliothèque ou un plugin peut être nommé selon une convention différente sous Windows de celle utilisée sur les plates-formes 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 consiste à 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 de même en mode production. Tel quel, le nom de la cible reste inchangé.