Utilisation avancée

Ajout de nouvelles fonctionnalités de configuration

qmake vous permet de créer vos propres fonctionnalités de configuration ( features ) pouvant être incluses dans les fichiers de projet en ajoutant leurs noms à la liste des valeurs spécifiées par la variable CONFIG. Les fonctionnalités sont des ensembles de fonctions et de définitions personnalisées contenues dans des fichiers d’ .prf s pouvant se trouver dans l’un des nombreux répertoires standard. Les emplacements de ces répertoires sont définis à plusieurs endroits, et qmake les parcourt dans l’ordre suivant lorsqu’il recherche des fichiers d’ .prf:

1. Dans un répertoire figurant dans la variable d’environnement QMAKEFEATURES, qui contient une liste de répertoires délimités par le séparateur de chemin de la plate-forme (deux-points pour Unix, point-virgule pour Windows).
2. Dans un répertoire répertorié dans la variable de propriété ` QMAKEFEATURES `, qui contient une liste de répertoires délimités par le séparateur de liste de chemins de la plate-forme.
3. Dans un répertoire features situé à l’intérieur d’un répertoire mkspecs. Les répertoires « mkspecs » peuvent se trouver sous n’importe lequel des répertoires répertoriés dans la variable d’environnement QMAKEPATH, qui contient une liste de répertoires délimités par le séparateur de chemin de la plate-forme. Par exemple : $QMAKEPATH/mkspecs/<features>.
4. Dans un répertoire features situé sous le répertoire indiqué par la variable d’environnement QMAKESPEC. Par exemple : $QMAKESPEC/<features>.
5. Dans un répertoire « features » situé dans le répertoire « data_install/mkspecs ». Par exemple : data_install/mkspecs/<features>.
6. Dans un répertoire « features » situé au même niveau que le répertoire spécifié par la variable d’environnement QMAKESPEC. Par exemple : $QMAKESPEC/../<features>.

Les répertoires de fonctionnalités suivants sont parcourus à la recherche de fichiers de fonctionnalités :

1. features/unix, features/win32 ou features/macx, selon la plate-forme utilisée
2. features/

Prenons par exemple l’affectation suivante dans un fichier de projet :

CONFIG += myfeatures

Grâce à cet ajout à la variable CONFIG, qmake recherchera le fichier myfeatures.prf dans les emplacements indiqués ci-dessus une fois l’analyse de votre fichier de projet terminée. Sur les systèmes Unix, il recherchera le fichier suivant :

1. $QMAKEFEATURES/myfeatures.prf (pour chaque répertoire répertorié dans la variable d’environnement QMAKEFEATURES )
2. $$QMAKEFEATURES/myfeatures.prf (pour chaque répertoire répertorié dans la variable de propriété QMAKEFEATURES )
3. myfeatures.prf (dans le répertoire racine du projet). La racine du projet est déterminée par le fichier .pro de niveau supérieur. Toutefois, si vous placez le fichier .qmake.cache dans un sous-répertoire ou dans le répertoire d'un sous-projet, la racine du projet devient alors ce sous-répertoire lui-même.
4. $QMAKEPATH/mkspecs/features/unix/myfeatures.prf et $QMAKEPATH/mkspecs/features/myfeatures.prf (pour chaque répertoire répertorié dans la variable d’environnement QMAKEPATH )
5. $QMAKESPEC/features/unix/myfeatures.prf et $QMAKESPEC/features/myfeatures.prf
6. data_install/mkspecs/features/unix/myfeatures.prf et data_install/mkspecs/features/myfeatures.prf
7. $QMAKESPEC/../features/unix/myfeatures.prf et $QMAKESPEC/../features/myfeatures.prf

Installation de fichiers

Sous Unix, il est courant d’utiliser également l’outil de compilation pour installer des applications et des bibliothèques ; par exemple, en exécutant la commande ` make install`. C’est pourquoi qmake intègre le concept d’ install set, un objet qui contient des instructions sur la manière dont une partie d’un projet doit être installée. Par exemple, un ensemble de fichiers de documentation peut être décrit de la manière suivante :

documentation.path = /usr/local/program/doc
documentation.files = docs/*

Le membre « path » indique à qmake que les fichiers doivent être installés dans « /usr/local/program/doc » (le membre « path »), et le membre « files » spécifie les fichiers à copier dans le répertoire d’installation. Dans ce cas, tout le contenu du répertoire « docs » sera copié dans « /usr/local/program/doc ».

Une fois qu’un ensemble d’installation a été entièrement décrit, vous pouvez l’ajouter à la liste d’installation à l’aide d’une ligne comme celle-ci :

INSTALLS += documentation

qmake veillera à ce que les fichiers spécifiés soient copiés dans le répertoire d’installation. Si vous souhaitez exercer un contrôle plus poussé sur ce processus, vous pouvez également fournir une définition pour le membre extra de l’objet. Par exemple, la ligne suivante indique à qmake d’exécuter une série de commandes pour cet ensemble d’installation :

unix:documentation.extra = create_docs; mv master.doc toc.doc

La portée « unix » garantit que ces commandes spécifiques ne sont exécutées que sur les plateformes Unix. Des commandes adaptées à d’autres plateformes peuvent être définies à l’aide d’autres règles de portée.

Les commandes spécifiées dans le membre ` extra ` sont exécutées avant que les instructions contenues dans les autres membres de l’objet ne soient exécutées.

Si vous ajoutez un ensemble d’installation intégré à la variable ` INSTALLS ` sans spécifier de membres ` files ` ou ` extra `, qmake déterminera à votre place ce qui doit être copié. Actuellement, les ensembles d’installation ` target ` et ` dlltarget ` sont pris en charge. Par exemple :

target.path = /usr/local/myprogram
INSTALLS += target

Dans les lignes ci-dessus, qmake sait ce qui doit être copié et gérera automatiquement le processus d’installation.

Ajout de cibles personnalisées

qmake s’efforce de remplir toutes les fonctions attendues d’un outil de compilation multiplateforme. Cela s’avère souvent insuffisant lorsque vous devez réellement exécuter des commandes spécifiques à une plateforme. Vous pouvez y parvenir en fournissant des instructions spécifiques aux différents backends de qmake.

La personnalisation de la sortie du Makefile s’effectue via une API de type « objet », comme c’est le cas ailleurs dans qmake. Les objets sont définis automatiquement en spécifiant leurs membres. Par exemple :

mytarget.target = .buildfile
mytarget.commands = touch $$mytarget.target
mytarget.depends = mytarget2

mytarget2.commands = @echo Building $$mytarget.target

Les définitions ci-dessus définissent une cible qmake appelée « mytarget », contenant une cible Makefile appelée « .buildfile », qui est à son tour générée par la commande « touch ». Enfin, le membre « .depends » spécifie que « mytarget » dépend de « mytarget2 », une autre cible définie par la suite. « mytarget2 » est une cible factice. Elle est uniquement définie pour afficher du texte à la console.

La dernière étape consiste à utiliser la variable ` QMAKE_EXTRA_TARGETS ` pour indiquer à qmake que cet objet est une cible à construire :

QMAKE_EXTRA_TARGETS += mytarget mytarget2

C’est tout ce dont vous avez besoin pour construire des cibles personnalisées. Bien sûr, vous souhaiterez peut-être associer l’une de ces cibles à la cible de construction qmake. Pour ce faire, il vous suffit d’inclure votre cible Makefile dans la liste des PRE_TARGETDEPS.

Les spécifications de cibles personnalisées prennent en charge les éléments suivants :

Ajout de compilateurs

Il est possible de personnaliser qmake pour prendre en charge de nouveaux compilateurs et préprocesseurs :

new_moc.output  = moc_${QMAKE_FILE_BASE}.cpp
new_moc.commands = moc ${QMAKE_FILE_NAME} -o ${QMAKE_FILE_OUT}
new_moc.depend_command = g++ -E -M ${QMAKE_FILE_NAME} | sed "s,^.*: ,,"
new_moc.input = NEW_HEADERS
QMAKE_EXTRA_COMPILERS += new_moc

Avec les définitions ci-dessus, vous pouvez utiliser un remplacement direct de moc si un tel outil est disponible. La commande est exécutée sur tous les arguments fournis à la variable NEW_HEADERS (provenant du membre input ), et le résultat est écrit dans le fichier défini par le membre output. Ce fichier est ajouté aux autres fichiers source du projet. De plus, qmake exécutera ` depend_command ` pour générer des informations de dépendance, et placera également ces informations dans le projet.

Les spécifications de compilateur personnalisées prennent en charge les membres suivants :

Le membre CONFIG prend en charge les options suivantes :

Dépendances de bibliothèques

Souvent, lors de la liaison à une bibliothèque, qmake s’appuie sur la plate-forme sous-jacente pour déterminer à quelles autres bibliothèques cette bibliothèque est liée, et laisse la plate-forme se charger de les intégrer. Dans de nombreux cas, cependant, cela ne suffit pas. Par exemple, lors de la liaison statique d’une bibliothèque, aucune autre bibliothèque n’est liée, et par conséquent aucune dépendance vis-à-vis de ces bibliothèques n’est créée. Or, une application qui se liera ultérieurement à cette bibliothèque devra savoir où trouver les symboles dont la bibliothèque statique aura besoin. qmake tente de suivre les dépendances d’une bibliothèque, le cas échéant, si vous activez explicitement ce suivi.

La première étape consiste à activer le suivi des dépendances dans la bibliothèque elle-même. Pour ce faire, vous devez indiquer à qmake d’enregistrer les informations relatives à la bibliothèque :

CONFIG += create_prl

Ceci ne concerne que le modèle « lib » et sera ignoré pour tous les autres. Lorsque cette option est activée, qmake créera un fichier se terminant par .prl qui enregistrera certaines méta-informations concernant la bibliothèque. Ce métafichier est similaire à un fichier de projet ordinaire, mais ne contient que des déclarations de variables internes. Lors de l’installation de cette bibliothèque, en la spécifiant comme cible dans une déclaration INSTALLS, qmake copiera automatiquement le fichier .prl vers le chemin d’installation.

La deuxième étape de ce processus consiste à activer la lecture de ces métadonnées dans les applications qui utilisent la bibliothèque statique :

CONFIG += link_prl

Lorsque cette option est activée, qmake traitera toutes les bibliothèques liées par l'application et recherchera leurs métadonnées. qmake s'en servira pour déterminer les informations de liaison pertinentes, en ajoutant notamment des valeurs à la liste des DEFINES ainsi qu'à celle des LIBS du fichier de projet de l'application. Une fois ce fichier traité par qmake, celui-ci parcourt les bibliothèques nouvellement introduites dans la variable ` LIBS ` et identifie leurs fichiers .prl associés, en poursuivant jusqu’à ce que toutes les bibliothèques aient été résolues. À ce stade, le Makefile est créé comme d’habitude, et les bibliothèques sont explicitement liées à l’application.

Les fichiers .prl doivent être créés exclusivement par qmake et ne doivent pas être transférés d’un système d’exploitation à l’autre, car ils peuvent contenir des informations dépendantes de la plate-forme.