Fonctionnalités avancées de CMake

Une fois que vous maîtrisez les bases de CMake, les fonctionnalités avancées peuvent vous aider à gérer avec plus de flexibilité la configuration de build de projets complexes.

Cet article couvre six grands sujets : modules personnalisés, builds multi-configuration, recherche avancée de packages, étapes de build personnalisées, compilation croisée multiplateforme et configuration des propriétés de cible.

Aperçu général du contenu :

Modules et scripts CMake personnalisés

Lorsque plusieurs fichiers CMakeLists.txt doivent répéter la même logique, encapsuler cette logique dans des modules personnalisés peut grandement réduire la redondance du code.

L'essence des modules et scripts personnalisés est d'extraire les fonctions, macros et configurations CMake couramment utilisées dans des fichiers séparés afin de les réutiliser dans plusieurs projets.

Modules CMake personnalisés

Un module personnalisé est un fichier d'extension.cmake, qui définit des fonctions et macros CMake pouvant être chargées via include().

Étapes de création :

Exemple de module personnalisé — MyModule.cmake :

Charger et utiliser le module dans CMakeLists.txt :

CMAKE_MODULE_PATHest la liste des chemins de recherche utilisée par CMake lors de la recherche de fichiers de module. CMake recherche d'abord le chemin de module intégré, puis, s'il ne le trouve pas, recherche les chemins spécifiés par CMAKE_MODULE_PATH.

Utilisation de scripts CMake personnalisés

Les scripts personnalisés sont similaires aux modules, mais sont généralement utilisés pour effectuer des opérations de configuration plutôt que pour définir des fonctions réutilisables.

Les scripts peuvent être chargés directement avec include(), et CMake exécute chaque commande qu'ils contiennent dans l'ordre.

Créer le fichier de script config.cmake :

Invoquez le script dans CMakeLists.txt :

# 使用绝对路径加载脚本
include(${CMAKE_SOURCE_DIR}/config.cmake)

Configurations de génération et cibles

CMake prend en charge la gestion de plusieurs configurations de génération (telles que Debug et Release) dans le même projet et la définition de plusieurs cibles de génération.

Générateurs multi-configuration

Différents générateurs CMake gèrent les configurations différemment.

Tels que Visual Studio et Xcode, les générateurs multi-configurationpermettent de basculer entre Debug/Release dans le même répertoire de génération, tandis que Unix Makefiles, etc.Les générateurs mono-configurationdoivent déterminer le type de génération au moment de la configuration.

Définir la configuration par défaut dans CMakeLists.txt :

# 仅对单配置生成器生效，多配置生成器会忽略此变量
set(CMAKE_BUILD_TYPE "Release" CACHE STRING "Build type")

CMAKE_BUILD_TYPE n'est effectif que pour les générateurs à configuration unique. Si vous utilisez Visual Studio, veuillez changer de configuration via cmake --build . --config Release ou dans l'IDE.

Cibles de compilation

Plusieurs cibles de compilation peuvent être définies dans un projet CMake, et chaque cible configure indépendamment les options de compilation et les dépendances de liaison.

Cela vous permet de produire plusieurs exécutables ou plusieurs bibliothèques en une seule compilation.

Recherche et configuration avancées

En plus de l'utilisation de base de find_package, CMake prend également en charge la spécification de composants, le contrôle précis des versions et la transmission d'informations de build via des modèles de fichiers de configuration.

Utilisation avancée de find_package

COMPONENTSLe mot-clé permet de rechercher uniquement des sous-modules spécifiques d'une bibliothèque plutôt que le paquet entier.

Ceci est très important pour les grandes bibliothèques comme Boost—l'importation à la demande évite de lier des composants inutiles.

Spécifier les chemins de recherche (pour les emplacements d'installation non standard) :

# 方式一：通过变量指定根目录
cmake .. -DBOOST_ROOT=/path/to/custom/boost

# 方式二：在 CMakeLists.txt 中预先设置
set(BOOST_ROOT "/path/to/custom/boost")
find_package(Boost REQUIRED COMPONENTS filesystem)

Fichiers de configuration et options de construction

configure_file()La directive peut injecter les valeurs des variables CMake dans les fichiers de code, ce qui permet de transmettre des informations de configuration au moment de la compilation.

Ceci est très utile lorsque vous devez intégrer dans le programme des informations telles que les numéros de version, l'heure de compilation, etc.

Créez le fichier modèle de configuration config.h.in :

Configurez et générez le fichier d'en-tête dans CMakeLists.txt :

Utilisez la configuration générée dans les fichiers source :

// 在 main.cpp 中包含生成的配置文件
#include "config.h"

std::cout << "EXAMPLE Version: " << EXAMPLE_VERSION << std::endl;
std::cout << "Build Type: " << EXAMPLE_BUILD_TYPE << std::endl;

Génération d'étapes de build personnalisées

Outre la compilation et l'édition de liens standard, CMake vous permet d'insérer des opérations personnalisées dans le processus de build, telles que la génération de code, la copie de ressources et les notifications après build.

Commandes personnalisées

add_custom_command()Utilisé pour définir une commande personnalisée qui est exécutée lorsqu'un fichier doit être mis à jour.

Le concept central de cette commande estpiloté par les dépendances— la commande ne s'exécute que lorsque le fichier OUTPUT n'existe pas ou que le fichier DEPENDS a été mis à jour.

Commande de déclenchement de l'étape de build — s'exécute après la fin de l'édition de liens :

Cibles personnalisées

add_custom_target()Définit une cible de construction qui ne produit pas de fichier de sortie, généralement utilisée pour regrouper plusieurs commandes personnalisées.

Sauf si le mot-clé ALL est utilisé, les cibles personnalisées ne s'exécuteront pas dans la build par défaut ; vous devez spécifier explicitement le nom de la cible.

add_custom_command et add_custom_target diffèrent : le premier définit une règle pour « comment générer des fichiers » et est déclenché par les dépendances ; le second définit une cible d'action pour « quoi faire » et doit être invoqué explicitement ou s'exécute automatiquement lorsque ALL est utilisé.

Multiplateforme et compilation croisée

L'un des principaux avantages de CMake est la prise en charge multiplateforme — le même CMakeLists.txt peut générer les fichiers de build correspondants sur différents systèmes d'exploitation et architectures.

Compilations multiplateformes

CMake détecte automatiquement le compilateur et l'environnement système de la plateforme actuelle et génère les fichiers de build correspondants.

Vous pouvez également spécifier explicitement les informations sur la plateforme cible via des variables.

Compilation croisée

La compilation croisée consiste à compiler des programmes qui s'exécutent sur une autre architecture (telle qu'ARM) sur la plateforme actuelle (telle que x86_64 Linux).

CMake utiliseun fichier de chaîne d'outils (Toolchain File)pour spécifier le compilateur, les informations système et la configuration de l'éditeur de liens requis pour la compilation croisée.

Créez un fichier de chaîne d'outils toolchain.cmake :

Compiler en cross-compilation à l'aide du fichier de chaîne d'outils :

# 配置时通过 -DCMAKE_TOOLCHAIN_FILE 指定工具链文件
mkdir build_arm && cd build_arm
cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..

# 使用生成的 Makefile 编译（将调用 ARM 交叉编译器）
make

Le fichier de chaîne d'outils doit être spécifié lors de la première exécution de cmake. Si CMakeCache.txt existe déjà, vous devez supprimer le répertoire de build et reconfigurer pour changer de chaîne d'outils.

Propriétés et configuration des cibles

CMake permet un contrôle précis des options de compilation, des options de liaison et de diverses propriétés cible par cible, ce qui est la pratique recommandée dans CMake moderne.

Propriétés des cibles

set_target_properties()Utilisé pour définir des propriétés au niveau de la cible, qui affectent le comportement du compilateur et de l'éditeur de liens.

Dans le CMake moderne, il est recommandé d'utiliser target_compile_options(), target_compile_definitions() et target_link_options() au lieu de set_target_properties(), car elles prennent en charge le contrôle de visibilité PUBLIC/PRIVATE/INTERFACE et rendent les dépendances plus claires.

Options personnalisées de compilation et d'édition de liens

L'utilisation de la série de commandes target permet un contrôle plus précis de la portée de propagation des options.

Notes

CMAKE_BUILD_TYPE n'est valide que pour les générateurs à configuration unique.Si le projet doit prendre en charge à la fois Makefile et Visual Studio, ne vous fiez pas à la valeur de CMAKE_BUILD_TYPE. Utilisez des expressions de générateur$<$<CONFIG:Debug>:DEBUG_VALUE>pour basculer dynamiquement en fonction de la configuration réelle.

Préférez la série de commandes target_xxx.Bien que set_target_properties soit puissant, il manque de contrôle de visibilité. Dans les scénarios nécessitant la sémantique PUBLIC/PRIVATE/INTERFACE, il est préférable d'utiliser des commandes dédiées telles que target_compile_options.

Le fichier de chaîne d'outils doit être spécifié lors de la première invocation de cmake.Lors d'une compilation croisée, spécifier à nouveau la chaîne d'outils dans un répertoire contenant un CMakeCache.txt existant peut produire une configuration incomplète. Configurez toujours la compilation croisée dans un répertoire de compilation propre.

Il est recommandé d'ajouter un préfixe aux noms de fonctions dans les modules personnalisés.Évitez les conflits de noms avec les commandes intégrées de CMake ou d'autres modules. Par exemple, utilisez le nom du projet comme préfixe : myproject_set_warnings().