Utilisation avancée

Ajout de nouvelles fonctions de configuration

qmake vous permet de créer vos propres features qui peuvent être inclus 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 collections de fonctions et de définitions personnalisées dans des fichiers .prf qui peuvent résider dans l'un des nombreux répertoires standard. L'emplacement de ces répertoires est défini à plusieurs endroits, et qmake vérifie chacun d'entre eux dans l'ordre suivant lorsqu'il recherche des fichiers .prf:

1. Dans un répertoire répertorié dans la variable d'environnement QMAKEFEATURES qui contient une liste de répertoires délimités par le séparateur de liste de chemins 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 de fonctionnalités résidant dans un répertoire mkspecs. Les répertoires mkspecs peuvent être situés sous n'importe lequel des répertoires énumérés dans la variable d'environnement QMAKEPATH qui contient une liste de répertoires délimités par le séparateur de liste de chemins de la plate-forme. Par exemple : $QMAKEPATH/mkspecs/<features>.
4. Dans un répertoire de caractéristiques situé sous le répertoire fourni par la variable d'environnement QMAKESPEC. Par exemple : $QMAKESPEC/<features>.
5. Dans un répertoire de fonctionnalités résidant dans le répertoire data_install/mkspecs. Par exemple : data_install/mkspecs/<features>.
6. Dans un répertoire de fonctionnalités qui existe en tant que frère du répertoire spécifié par la variable d'environnement QMAKESPEC. Par exemple : $QMAKESPEC/../<features>.

Les répertoires de fonctionnalités suivants sont recherchés pour les fichiers de fonctionnalités :

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

Prenons l'exemple de l'affectation suivante dans un fichier de projet :

CONFIG += myfeatures

Avec cet ajout à la variable CONFIG, qmake recherchera le fichier myfeatures.prf dans les emplacements énumérés ci-dessus après avoir terminé l'analyse de votre fichier de projet. 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 de premier niveau .pro. 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 le 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 des fichiers

Sous Unix, il est courant d'utiliser l'outil de compilation pour installer des applications et des bibliothèques, par exemple en invoquant make install. C'est pourquoi qmake possède le concept de install set, un objet qui contient des instructions sur la manière dont une partie d'un projet doit être installée. Par exemple, une collection de fichiers de documentation peut être décrite de la manière suivante :

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

Le membre path informe qmake que les fichiers doivent être installés dans /usr/local/program/doc (le membre path), et le membre files spécifie les fichiers qui doivent être copiés dans le répertoire d'installation. Dans ce cas, tout ce qui se trouve dans le 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 avec une ligne comme celle-ci :

INSTALLS += documentation

qmake s'assurera que les fichiers spécifiés sont copiés dans le répertoire d'installation. Si vous souhaitez avoir plus de contrôle 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 particulières ne sont exécutées que sur des plates-formes Unix. Les commandes appropriées pour 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 les instructions des autres membres de l'objet.

Si vous ajoutez un jeu d'installation intégré à la variable INSTALLS et que vous ne spécifiez pas les membres files ou extra, qmake décidera de ce qui doit être copié pour vous. 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 le processus d'installation automatiquement.

Ajouter des cibles personnalisées

qmake essaie de faire tout ce que l'on attend d'un outil de compilation multiplateforme. C'est souvent loin d'être idéal lorsque vous avez vraiment besoin d'exécuter des commandes spéciales dépendant de la plate-forme. Ceci peut être réalisé avec des instructions spécifiques aux différents backends de qmake.

La personnalisation de la sortie du Makefile est réalisée par le biais d'une API de type objet, comme on en trouve dans d'autres endroits de 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 avec 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 fictive. Elle n'est définie que pour envoyer 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 que vous avez à faire pour construire des cibles personnalisées. Bien sûr, vous pouvez vouloir lier une de ces cibles à la cible de construction de qmake. Pour ce faire, vous devez simplement inclure votre cible Makefile dans la liste des PRE_TARGETDEPS.

Les spécifications des cibles personnalisées prennent en charge les membres suivants :

Ajout de compilateurs

Il est possible de personnaliser qmake pour supporter 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 s'il en existe un. La commande est exécutée sur tous les arguments donnés à la variable NEW_HEADERS (à partir 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 sources du projet. En outre, qmake exécute depend_command pour générer des informations sur les dépendances et les place également dans le projet.

Les spécifications des compilateurs personnalisés prennent en charge les membres suivants :

Le membre CONFIG prend en charge les options suivantes :

Dépendances de bibliothèques

Souvent, lors de l'édition de liens avec une bibliothèque, qmake s'appuie sur la plate-forme sous-jacente pour savoir quelles sont les autres bibliothèques avec lesquelles cette bibliothèque est liée, et laisse la plate-forme les intégrer. Dans de nombreux cas, cependant, cela n'est pas suffisant. Par exemple, lors de la liaison statique d'une bibliothèque, aucune autre bibliothèque n'est liée, et donc aucune dépendance vers ces bibliothèques n'est créée. Cependant, une application qui se lie plus tard à cette bibliothèque aura besoin de savoir où trouver les symboles dont la bibliothèque statique aura besoin. qmake tente de garder une trace des dépendances d'une bibliothèque, le cas échéant, si vous activez explicitement le suivi.

La première étape est d'activer le suivi des dépendances dans la bibliothèque elle-même. Pour ce faire, vous devez demander à qmake de sauvegarder les informations relatives à la bibliothèque :

CONFIG += create_prl

Ceci n'est pertinent que pour 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 des méta-informations sur la bibliothèque. Ce métafichier est comme un fichier de projet ordinaire, mais il 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 dans le chemin d'installation.

La deuxième étape de ce processus consiste à activer la lecture de ces méta-informations 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 à l'application et trouvera leurs méta-informations. qmake les utilisera pour déterminer les informations de liaison pertinentes, en particulier en ajoutant des valeurs à la liste des DEFINES et des LIBS du fichier de projet de l'application. Une fois que qmake a traité ce fichier, il recherche les bibliothèques nouvellement introduites dans la variable LIBS et trouve leurs fichiers .prl dépendants, en continuant 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 liées explicitement à l'application.

Les fichiers .prl ne doivent être créés que 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épendant de la plate-forme.