Initiation à CMake

Qu'un logiciel soit libre ou propriétaire, son code source n'a que peu de chances de rester exclusivement entre les mains de son auteur d'origine. Un projet propriétaire développé en entreprise pourra être maintenu par une multitude de personnes tout au long de son existence. Un logiciel libre, quant à lui, peut compter plusieurs dizaines voire plusieurs centaines de développeurs éparpillés à travers le monde, sans compter les utilisateurs souhaitant compiler le code source eux-mêmes.

Pour compiler le code source, toutes ces personnes ont besoin d'un ensemble de fichiers contenant les paramètres de compilation. En effet, construire un programme à partir de son unique code source relève de la rétro-ingénierie. Or, au vu des conditions précitées, il est tout à fait impensable de fournir avec le code source un tel fichier dont le format serait lié à un EDI particulier, à un compilateur particulier ou encore à un système d'exploitation particulier. De plus, les paramètres de compilation listés dans ce fichier ne doivent évidemment pas dépendre d'une configuration spécifique de la machine effectuant la compilation (telle que le chemin d'installation d'une bibliothèque tierce).

En conséquence, il devient évident que le partage du fichier de projet de l'EDI ou encore du ou des fichiers makefile n'est pas une solution acceptable.

En réponse à ce besoin est née une nouvelle catégorie d'outils : les systèmes de construction logicielle (ou build systems, en anglais). Comme son nom l'indique, un tel système a pour but de permettre, directement ou indirectement, la compilation d'un code source.

Tous les systèmes de construction ont leurs spécificités, mais leur fonctionnement est globalement le même. Dans un premier temps, le développeur écrit dans un fichier la description du projet (incluant la liste des fichiers sources, les bibliothèques à lier au binaire final, etc.) de façon totalement indépendante de la configuration logicielle de la machine (qui inclut le compilateur utilisé, le chemin vers les fichiers des bibliothèques à lier, etc.). Ensuite, les personnes souhaitant compiler le projet appellent le système de construction en lui passant en paramètre le fichier écrit par le développeur. Le système analyse alors le fichier d'une part et tente de récupérer des informations sur la configuration logicielle de la machine l'exécutant d'autre part. Une fois ces opérations accomplies, il sera enfin en mesure de produire un script de compilation de bas niveau (tel qu'un fichier Makefile, comprenant des appels explicites au compilateur, dont les paramètres seront propres à la configuration logicielle) :

Certains systèmes effectueront plutôt des appels directs au compilateur afin de produire le binaire final, mais l'idée générale est la même.

Le fichier décrivant le projet, accompagné du code source (et éventuellement de la documentation et d'autres ressources diverses), est donc tout ce qui constitue le paquetage partagé par les différents contributeurs du projet (et par les utilisateurs si le projet est libre). Étant donné que ce fichier est utilisable par tous quelle que soit leur configuration logicielle, les systèmes de construction constituent donc une réponse viable à la problématique exposée ci-dessus.

Il existe un grand nombre de systèmes de construction logicielle différents, tels que les fameux GNU Autotools, SCons, Jam ou encore qmake. Le système qui nous intéresse dans ce document est le non moins connu CMake.

CMake est un système de construction logicielle. C'est un logiciel libre (licence BSD), multilangage et multiplateforme.

À partir du fichier descriptif du projet (nommé CMakeLists.txt) et des informations sur la configuration logicielle de la machine effectuant la compilation (listées dans le fichier CMakeCache.txt, prérempli lors de la phase d'analyse de la configuration), CMake est capable de générer les types de fichiers suivants :

• un fichier Makefile ;
• un fichier de projet d'EDI ;
• ou une combinaison des deux (pour les EDI supportant les fichiers Makefile).

C'est le générateur qui permet de définir le type de fichier à générer. Il existe plusieurs générateurs pour les makefiles, ainsi qu'un générateur par EDI supporté :

Alors que d'autres systèmes de construction ne sont utilisables que sous un ensemble restreint de systèmes d'exploitation, CMake est disponible aussi bien sous GNU/Linux que sous Windows et MacOS, pour ne citer qu'eux.

À l'heure où cet article est publié, CMake gère déjà les langages de programmation les plus populaires, tels que C, C++ et Java.

De plus, comme vous pourrez vous-même en juger dans la suite de ce cours, CMake est très facile à utiliser (ce qui est loin d'être le cas de tous les outils de cette catégorie) et la syntaxe du fichier CMakeLists.txt est à la fois simple et efficace.

Le paquetage livré avec CMake contient une interface graphique pour assister son fonctionnement. Cependant, cette interface n'est à l'heure actuelle pas disponible sous tous les systèmes d'exploitation. De plus, son utilisation n'est pas indispensable, voire nuisible d'un point de vue pédagogique ; il est en effet toujours intéressant de savoir ce qui se passe derrière ce type d'interfaces. Par conséquent, l'utilisation des interfaces graphiques de CMake ne sera pas traitée dans ce cours.

Son indépendance vis-à-vis du système d'exploitation, du compilateur et des outils de développement, sa simplicité d'utilisation, ses performances et ses nombreuses fonctionnalités font de CMake le système de prédilection de plus en plus d'utilisateurs. Pour plus d'informations sur CMake, dirigez-vous vers le site officiel.

Une fois le code source écrit, occupons-nous de notre fichier CMakeLists.txt.

III-A-1. Syntaxe▲

nom_de_la_commande(argument1 argument2 argument3)
                               
nom_d_une_autre_commande(
        argument1
        argument2
)

commande(argument "argument avec des espaces")

# ceci est un commentaire
commande(argument1 argument2)

III-A-2. Mise en pratique▲

# Déclaration du projet
project(MyProject)

# Déclaration de l'exécutable
add_executable(
        my_executable
        src/bird.h
        src/duck.cpp
        src/duck.h
        src/main.cpp
        src/sparrow.cpp
        src/sparrow.h
)

Notre fichier CMakeLists.txt est maintenant complet ; lançons CMake sans plus attendre. Placez-vous dans le dossier racine de votre projet et entrez une commande cmake de cette forme :

cmake . -G"nom_du_générateur_de_mon_choix"

Le premier paramètre désigne le répertoire où se situe le fichier CMakeLists.txt du projet. Dans notre cas, il s'agit du dossier courant.

L'option -G permet de définir le générateur. Du générateur dépend le type de fichier(s) que CMake va générer (fichier Makefile, fichier de projet d'EDI, etc.), comme il a été évoqué dans la . Remplacez nom_du_générateur_de_mon_choix par l'un des générateurs de CMake. Pour obtenir la liste des générateurs disponibles sur votre plate-forme, affichez l'aide de la commande cmake :

cmake --help

Cela ne semble pas forcément évident au premier abord, mais il faut écrire en toutes lettres le nom du générateur dans la commande cmake. Par exemple, si vous voulez générer un fichier de projet pour Code : :Blocks et que votre compilateur est MinGW, entrez la commande suivante :

cmake . -G"CodeBlocks - MinGW Makefiles"

Si tout se passe bien, la commande devrait retourner quelque chose comme ceci :

-- The C compiler identification is nom_de_votre_compilateur_C
-- The CXX compiler identification is nom_de_votre_compilateur_C++
-- Check for working C compiler : chemin_vers_votre_compilateur_C
-- Check for working C compiler : chemin_vers_votre_compilateur_C -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler : chemin_vers_votre_compilateur_C++
-- Check for working CXX compiler : chemin_vers_votre_compilateur_C++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to : adresse_du_dossier_de_votre_projet

CMake devrait avoir généré les fichiers suivants :

• CMakeFiles : dossier contenant les fichiers intermédiaires de compilation, des fichiers temporaires et autres fichiers de configuration qui ne regardent que CMake ;
• CMakeCache.txt : fichier définissant un ensemble de variables de configuration et d'informations sur votre système (nous nous pencherons davantage sur ce fichier plus loin dans le cours) ;
• cmake_install.cmake : script CMake d'installation de votre programme (dont nous ne parlerons pas dans ce cours) ;
• MyProject.xxx : fichier de projet de votre EDI (selon le générateur choisi) ;
• Makefile (selon le générateur choisi).

Remarquez que votre dossier src reste inchangé. Aucun fichier d'aucune sorte n'y a été créé. C'est un des aspects qui explique pourquoi CMake est autant apprécié chez les maniaques du rangement tels que moi : il ne s'introduit pas là où on ne lui a pas dit d'entrer et se contente de son dossier personnel (CMakeFiles) pour l'écriture de fichiers temporaires et de configuration interne.

Vous avez maintenant tout ce qu'il faut pour lancer une compilation. Procédez comme vous le faîtes habituellement : ouvrez votre projet avec votre EDI préféré et cliquez sur le bouton Construire, ou bien lancez make depuis votre terminal. Si tout va bien, votre compilateur aura créé un exécutable dans le dossier racine de votre projet, aux côtés du fichier CMakeLists.txt. Lancez-le pour vérifier qu'il n'y a pas de problème.

III-D-1. Génération automatique de la liste des fichiers sources▲

cmake_minimum_required(VERSION 2.6)

# Déclaration du projet
project(MyProject)

# Génération de la liste des fichiers sources
file(
        GLOB_RECURSE
        source_files
        src/*
)

# Déclaration de l'exécutable
add_executable(
        my_exe
        ${source_files}
)

III-D-2. Modification du chemin de sortie de l'exécutable▲

set(EXECUTABLE_OUTPUT_PATH bin)

cmake_minimum_required(VERSION 2.6)

# Configuration du projet
project(MyProject)
set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})

# Génération de la liste des fichiers sources
file(
        GLOB_RECURSE
        source_files
        src/*
)

# Déclaration de l'exécutable
add_executable(
        my_exe
        ${source_files}
)

III-D-3. Édition du fichier CMakeCache.txt▲

CMAKE_BUILD_TYPE:STRING=

NOM_DE_LA_VARIABLE:TYPE=valeur

CMAKE_BUILD_TYPE:STRING=Release

cmake . -G"nom_du_générateur_de_mon_choix" -DCMAKE_BUILD_TYPE :STRING=Release

De la même façon que lors d'une compilation en ligne de commande ou via un EDI, nous devons :

1. ajouter le répertoire des fichiers d'en-tête de Boost à la liste des répertoires parcourus par le préprocesseur lors de la recherche d'un fichier d'en-tête externe ;
2. ajouter le répertoire des fichiers de bibliothèques partagées de Boost à la liste des répertoires parcourus par l'éditeur de liens lors de la recherche d'une bibliothèque ;
3. lier le fichier de bibliothèque partagée de Boost.Signals à notre exécutable.

Pour remplir la première condition, nous utiliserons la commande include_directories() :

include_directories(/chemin/vers/boost_x_xx_x)

La commande link_directories() nous permettra de répondre à la deuxième condition :

link_directories(/chemin/vers/boost_x_xx_x/stage/lib)

Enfin, la commande target_link_libraries(), qui sert à spécifier les différentes bibliothèques à lier à une cible (indiquée en premier argument), remplira la dernière :

target_link_libraries(
        my_exe
        boost_signals-mt
)

Sous Windows, les adresses absolues doivent être notées sous cette forme : C:/chemin/vers/boost_x_xx_x.

Remarquez qu'il n'est pas nécessaire (même si cela reste possible) de spécifier le nom exact du fichier de bibliothèque. Par exemple, dans le cas d'un fichier sous GNU/Linux portant le nom libboost_signals-mt.so, CMake saura qu'il faudra ajouter le préfixe lib et l'extension .so.

Voici le contenu du fichier CMakeLists.txt après ces modifications :

cmake_minimum_required(VERSION 2.6)

# Configuration du projet
project(MyProject)
set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})

# Inclusion de Boost
include_directories(/chemin/vers/boost_x_xx_x)
link_directories(/chemin/vers/boost_x_xx_x/stage/lib)

# Configuration de l'exécutable
file(
        GLOB_RECURSE
        source_files
        src/*
)
add_executable(
        my_exe
        ${source_files}
)

#Configuration de l'édition de liens
target_link_libraries(
        my_exe
        boost_signals-mt
)

Appelez la commande cmake, compilez et testez le programme. Tout fonctionne à merveille ? Alors, ajoutons la touche finale à notre fichier CMakeLists.txt.

Comme expliqué dans le chapitre précédent, le fichier CMakeLists.txt ne devrait pas comporter d'informations relatives à votre système. Utilisons donc des variables à la place des chemins et des noms de fichiers spécifiés :

cmake_minimum_required(VERSION 2.6)

# Configuration du projet
project(MyProject)
set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})

# Inclusion de Boost
include_directories(${boost_include_dir})
link_directories(${boost_lib_dir})

# Configuration de l'exécutable
file(
        GLOB_RECURSE
        source_files
        src/*
)
add_executable(
        my_exe
        ${source_files}
)

# Configuration de l'édition de liens
target_link_libraries(
        my_exe
        ${boost_signals_lib_name}
)

Encore une fois, définissez la valeur de ces variables dans le fichier CMakeCache.txt. Ajoutez-y les lignes suivantes :

//Chemin vers le dossier des fichiers d'en-tête de Boost
boost_include_dir:FILEPATH=/chemin/vers/boost_x_xx_x

//Chemin vers le dossier des fichiers bibliothèques de Boost
boost_lib_dir:FILEPATH=/chemin/vers/boost_x_xx_x/stage/lib

//Nom du fichier de la bibliothèque Boost.Signals
boost_signals_lib_name:STRING=boost_signals-mt

Effectuez un ultime test. Si celui-ci est toujours concluant, alors votre fichier CMakeLists.txt est prêt à être distribué aux autres contributeurs du projet.

CMake est livré avec un ensemble de modules dont certains sont destinés à vous assister pour l'inclusion de bibliothèques dans votre projet. Les bibliothèques Boost font partie des quelques paquetages à bénéficier d'un tel module.

Tout d'abord, incluez le module correspondant (nommé FindBoost, dans notre cas) dans CMakeLists.txt :

include(FindBoost)

Utilisez ensuite la commande find_package(), désormais utilisable de cette manière pour Boost, grâce à l'inclusion du module FindBoost :

find_package(
        Boost 
        1.36.0
        REQUIRED signals
)

• Boost, le premier argument, est le nom du paquetage à trouver.
• 1.36.0, le deuxième argument définit la version du paquetage à trouver.
• REQUIRED, le troisième argument, indique que le ou les éléments de la bibliothèque qui vont suivre sont requis.
• signals, le quatrième et dernier argument est l'un de ces éléments.

Enfin, il est possible de spécifier des critères de recherche plus précis, tels que l'utilisation des versions statiques ou dynamique des bibliothèques ou encore de leurs versions optimisées multithread ou non. Ces variables sont à définir avant l'appel de la commande find_package() :

set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREAD OFF)

Si la commande find_package() parvient à trouver les paquetages spécifiés, elle définit un ensemble de variables comprenant, entre autres :

• Boost_LIBRARY_DIRS, répertoire contenant les fichiers d'en-tête de Boost ;
• Boost_INCLUDE_DIRS, répertoire contenant les fichiers de bibliothèques de Boost ;
• Boost_LIBRARIES, chemin des fichiers des bibliothèques recherchées (ici, Boost.Signals uniquement).

Ces variables sont à utiliser comme arguments des commandes respectives include_directories(), link_directories() et target_link_libraries(). Leurs définitions se situent dans la partie consacrée à l'inclusion manuelle d'une bibliothèque.

message(
        STATUS
        ${Boost_LIBRARIES}
)

Le fichier CMakeLists.txt complet est le suivant :

cmake_minimum_required(VERSION 2.6)

# Configuration du projet
project(MyProject)
set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})

# Inclusion de Boost
include(FindBoost)
find_package(
        Boost
        1.36.0
        REQUIRED signals
)
link_directories(${Boost_LIBRARY_DIRS})
include_directories(${Boost_INCLUDE_DIRS})

# Configuration de l'exécutable
file(
        GLOB_RECURSE
        source_files
        src/*
)
add_executable(
        my_exe
        ${source_files}
)

# Configuration de l'édition de liens
target_link_libraries(
        my_exe
        ${Boost_LIBRARIES}
)

Dans un environnement de type Unix où l'organisation des fichiers est standard, la recherche devrait être concluante sans avoir à fournir plus d'informations à CMake. Toutefois, dans le cas d'une installation exotique ou de l'utilisation d'un autre système d'exploitation, il peut s'avérer nécessaire de spécifier dans quel dossier chercher.

Dans un tel cas de figure, vous devez ajouter dans la section EXTERNAL cache entries du fichier CMakeCache.txt un ensemble de définitions de variables. Pour Boost, les variables à définir sont BOOST_ROOT, BOOST_INCLUDEDIR et BOOST_LIBRARYDIR, définissant respectivement le dossier racine de votre installation de Boost, le dossier contenant les fichiers d'en-tête et le dossier contenant les fichiers de bibliothèques :

//Chemin vers le dossier racine de Boost
BOOST_ROOT:FILEPATH=/chemin/vers/boost_x_xx_x

//Chemin vers le dossier des fichiers d'en-tête de Boost
BOOST_INCLUDEDIR:FILEPATH=/chemin/vers/boost_x_xx_x

//Chemin vers le dossier des fichiers bibliothèques de Boost
BOOST_LIBRARYDIR:FILEPATH=/chemin/vers/boost_x_xx_x/stage/lib
Lancez la commande cmake. Celle-ci devrait renvoyer la sortie suivante : 
-- Boost version: x.xx.x
-- Found the following Boost libraries:
--   signals
-- Configuring done
-- Generating done
-- Build files have been written to : [adresse_du_dossier_de_votre_projet]

Compilez votre programme et vérifiez qu'il affiche bien Hello, World!.

Pour une description détaillée de l'ensemble des modules livrés avec CMake, rendez-vous sur la documentation officielle.

Restons dans la simplicité et imaginons une bibliothèque permettant de dire bonjour dans la langue de notre choix.

L'organisation d'un projet de bibliothèque est quelque peu différente de celle d'un exécutable :

Le dossier include contient les en-têtes publics dans un sous-dossier portant le nom de la bibliothèque. Ainsi, les programmes utilisant ladite bibliothèque incluront les en-têtes nécessaires de cette façon :

#include <iostream>
#include <libhello/french.h>
                        
int main(int argc, char** argv)
{
        std::cout << "In France, people say hello that way : ";
        std::cout << libhello : :say_hello_in_french();
        std::cout << std::endl;
        
        return 0;
}

Le dossier src, quant à lui, contient le reste des fichiers sources. Si l'un de ces fichiers doit inclure l'un des en-têtes publics, la directive d'inclusion sera similaire à celle de l'exemple ci-dessus. Par exemple, le contenu du fichier src/french.cpp est le suivant :

#include <iostream>
#include <libhello/french.h>
                        
namespace libhello
{
                        
const std::string say_hello_in_french()
{
        return "Bonjour, tout le monde !";
}

} //namespace libhello

L'en-tête correspondant, include/libhello/french.h, est la suivante :

#ifndef LIBHELLO_FRENCH_H
#define LIBHELLO_FRENCH_H
                        
namespace libhello
{

const std::string say_hello_in_french();

} //namespace libhello

#endif

Les fonctions correspondant aux autres langues sont déclarées et définies de la même façon.

Comme d'habitude, on commence par déclarer le projet :

project(Hello)

On définit ensuite le dossier dans lequel le fichier de bibliothèque sera généré. Puisqu'il s'agit d'une bibliothèque, optons pour lib :

set(LIBRARY_OUTPUT_PATH lib/${CMAKE_BUILD_TYPE})

Les fichiers sources de la bibliothèque incluent les en-têtes publics avec une directive d'inclusion du type #include<>. Le dossier include doit donc être ajouté à la liste des dossiers parcourus par le préprocesseur lors de l'inclusion d'un en-tête externe. On retrouve la commande que l'on a utilisée pour l'inclusion d'une bibliothèque :

include_directories(include)

Comme toujours suit la génération de la liste des fichiers sources. On liste les fichiers du dossier src ainsi que ceux de include :

file(
        GLOB_RECURSE
        source_files
        src/*
        include/*
)

Enfin, nous déclarons la bibliothèque elle-même, avec la commande add_library() :

add_library(
        hello
        SHARED
        ${source_files}
)

Tout comme pour la commande add_executable(), le premier paramètre est le nom de la bibliothèque et le dernier la liste des fichiers sources. Le second paramètre, optionnel, indique le type de bibliothèque à générer :

• STATIC, pour générer une bibliothèque à lier statiquement ;
• SHARED, pour générer une bibliothèque à lier dynamiquement.

Par défaut, ce paramètre est défini à STATIC.

Voici le contenu du fichier CMakeLists.txt au complet :

cmake_minimum_required(VERSION 2.6)

# Configuration du projet
project(Hello)
set(LIBRARY_OUTPUT_PATH lib/${CMAKE_BUILD_TYPE})

# Inclusion des en-têtes publics
include_directories(include)

# Configuration de la bibliothèque
file(
        GLOB_RECURSE
        source_files
        src/*
        include/*
)
add_library(
        hello
        SHARED
        ${source_files}
)

Générez le script de compilation et compilez. Votre compilateur devrait avoir généré un fichier de bibliothèque partagée dans le dossier lib (ou dans l'un de ses sous-dossiers).

Il est maintenant temps de tester notre bibliothèque. Pour ce faire, nous allons coder un exécutable effectuant l'ensemble des tests nécessaires. Commençons par mettre en place le projet CMake correspondant à cet exécutable dans un nouveau dossier (que nous nommerons test) de notre hiérarchie :

Le fichier main.cpp se contente de vérifier que les fonctions de la bibliothèque renvoient bien les chaînes de caractères attendues :

#include <cassert>
#include <iostream>
#include <libhello/english.h>
#include <libhello/french.h>
                        
int main(int argc, char** argv)
{
        assert(libhello::say_hello_in_english() == "Hello everyone!");
        assert(libhello : :say_hello_in_french() == "Bonjour, tout le monde !");
        
        std::cout << "Test OK." << std::endl;
        
        return 0;
}

Le fichier CMakeLists.txt ne comporte aucune nouvelle notion. En fait, il s'agit du même fichier que celui de la , à l'exception que les variables boost_include_dir, boost_lib_dir et boost_signals_lib_name sont directement remplacées par les paramètres correspondant à notre bibliothèque :

cmake_minimum_required(VERSION 2.6)

# Configuration du projet
project(TestHello)
set(EXECUTABLE_OUTPUT_PATH bin/${CMAKE_BUILD_TYPE})

# Inclusion de la bibliothèque Hello
include_directories(../include)
link_directories(../lib/${CMAKE_BUILD_TYPE})

# Configuration de l'exécutable
file(
        GLOB_RECURSE
        source_files
        src/*
)
add_executable(
        test_hello
        ${source_files}
)

# Configuration de l'édition de liens
target_link_libraries(
        test_hello
        hello
)

Prêtez attention à la commande link_directories(). Si vous spécifiez le type de compilation (CMAKE_BUILD_TYPE) à Debug (par exemple) pour cet exécutable de test, le fichier de la bibliothèque Hello sera recherché dans ../lib/Debug. Veillez donc à ce que la bibliothèque ait été préalablement compilée en Debug avant de tenter une compilation de l'exécutable de test de ce type. Bien évidemment, cette remarque importe quel que soit le type de compilation.

Lancez CMake, compilez et vérifiez que le test se déroule sans échec d'assertion.