Quand étudier les moteur de production type CMake ?

Bonjour,

Je commence à suivre un tutoriel qui parle de la SDL. Tout bêtement, dans les fichiers obtenus après téléchargement, j’ai l’impression que beaucoup de fichiers sont complètement imbittables et j’ai l’impression que ce sont des scripts cmake. D’où ma question : me recommandez-vous d’apprendre CMake pour pouvoir comprendre ça ? Faut-il apprendre cmake tout court pour bien gérer un projet ? Maitriser cmake d’ailleurs ça sert à quoi ? Parce que au final, aujourd’hui pour compiler mes projets je fais gcc ./src/*.c -o exe et ça fonctionne très bien, je comprends pas trop ce qu’est censé améliorer cmake. Et enfin si c’est utile, Est-ce utile de l’apprendre avant d’avoir essayé d’utiliser une bibliothèque non standard, ou est-ce hors de ma portée aujourd’hui ? (j’ai fini le cours de C du site) Si CMake n’est pas le problème, comment m’habituer à comprendre ce qu’on peut trouver comme fichiers dans les bibliothèques qu’on peut télécharger sur le net ?

Il n’est pas forcément utile de comprendre comment sont compilés les logiciels qu’on se contente d’utiliser (il faut juste suivre ce que dit la doc comme le dit @Jacen). Par contre, il est très utile de connaitre au moins un outil de build adapté à ses propres développements. make et cmake sont assez génériques et très utilisés.

aujourd’hui pour compiler mes projets je fais gcc ./src/*.c -o exe et ça fonctionne très bien, je comprends pas trop ce qu’est censé améliorer cmake

Juste compiler en une seule commande, ça va pour un petit projet, mais ça peut être très long de tout recompiler quand on change juste un seul fichier source. Il vaut donc déjà mieux compiler chaque fichier source séparément, et ensuite, faire l’édition de liens pour construire l’exécutable.

C’est là que make devient intéressant, car il va juste reconstruire ce qu’il faut en regardant ce qui a été modifié.

Après, dans le Makefile, on peut vouloir ajouter d’autres cibles, comme par exemple fabriquer la doc, ou encore lancer les tests.

Pour les systèmes de build, il y a 2 choses à prendre en compte: l’utilisation de l’outil lui-même et le langage utilisé pour décrire comment compiler le projet.

Pour le langage, inutile de l’apprendre si on ne compte pas écrire soi-même quelque chose. Mais je rejoins les 2 autres sur un point: on ne peut pas y couper lorsqu’on veut distribuer le projet ou lorsqu’il devient trop gros ou qu’il y a trop d’étape.

Par contre, il faut un minimum savoir comment fonctionne le système de build qu’on utilise histoire de compiler des exécutables ou des bibliothèques de manière efficace et qui s’intègre à l’environnement.

À mon sens, le minimum est de savoir changer le compilateur, le mode de compilation (debug, release, etc) et lister les options d’un projet. Lire le manuel concernant l’outil en ligne de commande ou ce que donne --help est déjà une bonne étape. Le fonctionnement de certains systèmes de build comme CMake resteront quand même assez obscures. Par exemple, CMake ne compile pas avec les options d’optimisations par défaut, il faut le demander avec -DCMAKE_BUILD_TYPE=Release.

Ce point est important lorsqu’on écrit les instructions de compilation dans un README, mais aussi lorsqu’il faut corriger les instructions erronées d’autres projet: cmake undossier && make ne fonctionne pas partout (c’est mon cas) et n’est pas la manière recommander de faire. Il faut utiliser cmake --build dossier_de_build à la place de make.

Par contre, écrire directement un Makefile: Non ! Ceux qui le font ne gèrent absolument pas convenablement les environnements utilisés (plateforme, compilateur, linker, option spéciales ou mode de compilation) ni les dépendances (écrire à la main les dépendances sur des .h/.hpp n’est pas une gestion des dépendances ; ne pas les écrire non plus). À la fin, le résultat est soit bancal, soit le Makefile est imbitable.

Les systèmes de build tel que xmake, meson, cmake, etc gèrent plein de chose de manière automatique et permettent de s’affranchir de plein de problème.

Le plus connut est probablement cmake, mais le langage est vraiment horrible et le projet à un historique très lourd avec des recommandations qui ont changées au fils des ans. Il faut faire gaffe à ne pas suivre d’anciennes méthodes qui peuvent se révéler problématique par la suite. À mon sens, meson et xmake sont de bien meilleurs candidats. Je te conseille quand même de regarder cmake pour te faire ton propre avis.

Note au passage que gcc ./src/*.c -o exe est très insuffisant: il manque les warnings. Certains systèmes de build (tous sauf cmake…) ont des options pour activer au moins -Wall et -Wextra avec gcc et clang.

Moi, je pense que commencer par écrire des Makefile simples sur son propre projet (que l’on maitrise normalement bien) permet de bien comprendre comment ça marche, et comme c’est l’outil historique, j’imagine que la plupart des outils plus récents suivent plus ou moins les mêmes principes.

Après, quand on a compris, et que le projet grossit, on n’est pas obligé d’écrire les dépendances à la main non plus : on peut les faire générer par le compilateur !

Moi, je pense que commencer par écrire des Makefile simples sur son propre projet (que l’on maitrise normalement bien) permet de bien comprendre comment ça marche, et comme c’est l’outil historique, j’imagine que la plupart des outils plus récents suivent plus ou moins les mêmes principes.

Absolument pas. Dans un système de build, on décrit les dépendances au niveau des relations: on associe des cible à un type (exécutable, bibliothèque, etc) + d’autres composants (bibliothèque statique/dynamique/header only, etc) ou fichiers. Ces composant possèdent des comportements à propager automatiquement (options de compilation ou étapes intermédiaires).

Dans un Makefile, on écrit comment le faire, on doit se taper les commandes et les adapter à chaque compilateur et environnement. Il n’y a pas de séparation des concepts. Make ne sait faire qu’une chose: associer un fichier à d’autres fichiers et lancer des commandes quelconques pour y parvenir.

Savoir écrire un Makefile n’aide en rien à l’écriture de fichier dans un autre système de build. Les concepts sont bien plus haut niveau et utilisés de manière totalement différente.

De plus, la plupart des systèmes de build ne sont qu’un intermédiaire qui génère un fichier spécialisé pour tel IDE / éditeur de texte (VS, Kate, C::B, etc) ou dans la mise à jour de fichier quand d’autres changent (Makefile, Ninja, etc). Certains — comme meson — ne se limitent qu’à la génération de solution VS et ninja.build (ninja étant quand même plus rapide que make).

Après, quand on a compris, et que le projet grossit, on n’est pas obligé d’écrire les dépendances à la main non plus : on peut les faire générer par le compilateur !

Ce n’est pas à faire quand le projet grandit, c’est à faire tout de suite. Alors que la plupart des utilisateurs de make ne savent pas le faire, cela dépend en plus du compilateur !

Dans un système de build, on ne s’en occupe pas. C’est automatique.

Tu as le même discours qu’une personne qui vient dire qu’il faut apprendre l’assembleur parce que C ou C++ se reposent dessus.

Tu as le même discours qu’une personne qui vient dire qu’il faut apprendre l’assembleur parce que C ou C++ se reposent dessus.

Oui, je serais tout à fait capable de dire ça pour le C en effet (pas pour le C++, parce que beurk… mais bref )

Enfin, je ne dirais peut-être tout de même pas "apprendre", mais au moins en avoir des connaissances de base. A moi, ça me semble utile, mais je comprends qu’on ait un autre point de vue…

Je suis d’accord que c’est bien pour la portabilité, mais au final imposer le système de build (cmake ici) n’est-il pas du même acabit que d’imposer un compilateur précis ?

Les Makefile restent quelque chose de très utile pour représenter des dépendances entre des fichiers et des actions à réaliser, en plus ils sont largement compris et supportés.

Après il faut voir ce que tu appelles imbitable mais je trouve que non, on peut faire des Makefile génériques et élégants.

Je suis d’accord que c’est bien pour la portabilité, mais au final imposer le système de build (cmake ici) n’est-il pas du même acabit que d’imposer un compilateur précis ?

Pour enfoncer le clou un peu plus, si tu écris un Makefile, tu imposes en pratique un compilateur (ou alors tu écris un makefile par compilateur ), tu imposes d’utiliser make, et tu imposes le set d’architectures et OS pour lequel le makefile est valide. Tu imposes aussi dans une certaines mesure les flags de compilations et les diverses optimisations utilisées. Chacune de ces limitations est levée par CMake.

Les Makefile restent quelque chose de très utile pour représenter des dépendances entre des fichiers et des actions à réaliser, en plus ils sont largement compris et supportés.

Make ne gère pas du tout les dépendances entre les cibles, il gère la résolution des relations de dépendances que tu lui fournis. C’est bien beau, mais c’est vraiment pas pratique de devoir maintenir soi même un truc qui peut être automatisé.

Après il faut voir ce que tu appelles imbitable mais je trouve que non, on peut faire des Makefile génériques et élégants.

C’est juste un mensonge dès que tu essayes de supporter plus qu’un compilateur, plus qu’un OS, plus qu’un set de flags de compilations, que tu as un nombre de fichiers sources qui grossi, ou encore que tu as des dépendances externes. Autrement dit dès que tu fais à peu près n’importe quel projet qui n’est ni trivial ni purement dans ton coin (et de toute façon meme si ton projet est trivial, écrire la config CMake qui va bien sera plus lisible, plus court, et beaucoup plus flexible qu’un Makefile!).

On dirait que beaucoup d’arguments donnés dans ce topic sont parfaitement valables dans le contexte des projets en C (ce qui est très pertinent puisqu’il s’agit là d’un topic sur le C). Mais j’ai l’impression qu'@entwanne sous-entendait des cas plus généraux d’utilisation d’un Makefile, comprenant tout aussi bien des projets non C utilisant des langages pour lesquels l’implémentation prend déjà à sa charge une grosse partie concernant le support multi-plateforme. On peut ainsi concevoir par exemple un projet Python incluant un Makefile qui faciliterait l’ordonnancement de certaines actions selon les fichiers touchés ou non. C’est comme ça que j’ai compris son intervention.

Certes, mais c’est complètement hors-sujet.

J’aimerais apporter mon grain de sable sur l’usage de Makefile dans des projets de taille notable. Même en l’absence de question de grosse gestion du multi-plateformes, sur un projet réel, c’est l’enfer (vécu), et je le déconseille aussi pour de petits projets parce qu’on n’est jamais à l’abri que le petit projet devienne gros. Pour avoir dû faire des modifs de build dans un projet au final pas si gros (~1800 fichiers de sources pour le soft en lui-même, pas le tests, etc), devoir travailler dans 6 kLOC de Makefiles c’est tout sauf pratique.

GCC est portable aussi pourtant il est recommandé de ne pas l’imposer. Ma question cherche plutôt à comprendre pourquoi ce serait le mal absolu que la configuration du projet utilise un compilateur particulier alors que ça passe crème d’imposer le système de build.

Je ne comprends pas ton point, il gère les dépendances entre cibles telles qu’elles lui sont décrites. Ce qui peut se faire entre autres à l’aide de règles génériques voire implicites (%.o: %.c) ou générées (par exemple le compilateur qui peut générer des fichiers de dépendances entre les .o et les .h)

Non ce n’est pas vraiment ça : dans le cadre de ce sujet je me place dans l’utilisation d’un Makefile pour un projet C. Mais c’était quand même pour appuyer le fait qu’il est facile de réaliser diverses tâches "annexes" avec le Makefile (compiler la documentation, mettre en place l’environnement, construire et publier une version du projet, compiler des dépendances écrites dans d’autres langages) et qu’ils font souvent un bon point d’entrée pour regrouper les différentes actions possibles sur un projet.

Sachant que le Makefile peut très bien être divisé en d’autres plus petits fichiers pour les grouper par fonctionnalités, est-ce que c’est vraiment un problème ?

GCC est portable aussi pourtant il est recommandé de ne pas l’imposer. Ma question cherche plutôt à comprendre pourquoi ce serait le mal absolu que la configuration du projet utilise un compilateur particulier alors que ça passe crème d’imposer le système de build.

Bon déjà, comme je l’ai expliqué plus haut le système de build lève beaucoup d’autres limitations que celle du compilateur, donc cette question isolée est un peu un homme de paille. Mais même en l’admettant, le problème d’imposer un compilateur est que tu limites artificiellement ton projet à être compilable avec ce compilateur. C’est un problème dans les cas suivants :

• le compilateur imposé n’est pas installé ;
• le compilateur imposé produit du code machine de moins bonne qualité qu’un autre ;
• le compilateur imposé n’est pas celui supporté par le serveur sur lequel tu veux compiler ;
• le compilateur imposé produit du code machine avec un incompatibilité bizarre avec le reste du code (donc tu peux pas juste mélanger les compilateurs pour compiler divers composants du projet) ;
• le compilateur imposé a un bug qui le rend inutilisable sur un bout du projet ;
• tu veux comparer plusieurs compilateurs pour voir celui qui produit le meilleur code machine pour un projet donné.

Tout ça, ce sont des problèmes bien réels, et quand tu écris un projet tu sais jamais où il va finir. Imposer un compilateur pour un projet que tu fais dans ton coin, très bien, tout le monde s’en fout. Sur un projet destiné à être partagé, tu peux être sûr que ça va faire chier quelqu’un à un moment donné parce que le monde de la programmation système est loin d’être un long fleuve tranquille d’interopérabilité et que les gens font des trucs bizarres. Les gens se sont rendus compte il y a bien longtemps que Make est trop bas niveau pour décrire une build qui soit robuste, notamment parce que c’est vite l’enfer de gérer plusieurs compilateurs (ce qui est un peu la base en programmation système quand même ), et CMake étant le standard du marché, t’auras pas le problème qu’il n’est pas installé sur la machine quelconque que tu utilises (et si CMake n’est pas installé ou qu’il faut le mettre à jour, c’est moins d’efforts que d’installer un compilateur).

Je ne comprends pas ton point, il gère les dépendances entre cibles telles qu’elles lui sont décrites. Ce qui peut se faire entre autres à l’aide de règles génériques (%.o: %.c) ou générées (par exemple le compilateur qui peut générer des fichiers de dépendances entre les .c et les .h)

Le problème est bien qu’il faut les écrire (et donc les maintenir) plutôt que bêtement lister les fichiers une fois et laisser CMake et le système de build choisi automatiquement appeler les commandes qui vont bien pour résoudre les dépendances. Je ne comprends même pas comment ça peut être un point litigieux, ça c’est bénéfique pour tout le monde, tout le temps, même sur un projet avec seulement quelque fichiers.

Non ce n’est pas vraiment ça : dans le cadre de ce sujet je me place dans l’utilisation d’un Makefile pour un projet C. Mais c’était quand même pour appuyer le fait qu’il est facile de réaliser diverses tâches "annexes" avec le Makefile (compiler la documentation, mettre en place l’environnement, construire et publier une version du projet, compiler des dépendances écrites dans d’autres langages) et qu’ils font souvent un bon point d’entrée pour regrouper les différentes actions possibles sur un projet.

C’est un peu absurde comme propos, c’est tout aussi facile avec CMake de définir des commandes de ce genre mais tu n’imposes pas de passer par un Makefile. Si l’utilisateur de ton code veut se servir e.g. de Visual Studio, il pourra cliquer sur "compiler la documentation" sur le bouton qui va bien. Bon en plus avec CMake, tu as la compilation hors-source qui est disponible sans rien avoir à faire, donc tu peux par exemple créer les artefacts de distributions pour deux versions de la librairie donnée (e.g. Debug et Release) et passer de l’une à l’autre sans devoir tout recompiler tout le temps. Oh bien sûr quelqu’un va dire qu’on peut écrire une build hors-source en Makefile et quiconque a essayé sait que c’est casse-gueule et à comparer avec le fait que CMake offre ça for free.

Maintenir des milliers de lignes de Makefile est pénible qu’elles soient dans un seul ou dans plusieurs fichiers. Surtout quand on sait qu’il est possible d’exprimer la même build en beaucoup plus flexible et maintenable en 10 fois moins de lignes…

Le système de build qui remplace ces Makefile permet de faire, plus efficacement (meilleure gestion des dépendances, meilleur gestion de cache, meilleur temps d’exécution pour un build complet), tout ce que faisaient les Makefile du projet, en 6 fois moins de lignes de code. Et ces lignes sont infiniment plus simple que les horreurs qu’on était obligé d’écrire parfois pour filtrer tel et tel cas spécifiques. Notamment, pour la plupart d’entre eux, il suffit de prendre le fichier du voisin, changer deux noms dedans, vérifier la liste des dépendances externe et … that’s it, donc sur les 10/15 lignes du fichiers, il y en a en gros 4 pour lesquelles il faut réfléchir un peu, le reste est standard.

Je ne suis pas forcement d’accord avec la réponse de adri1. Supporter plusieurs plateformes, plusieurs compilateurs, etc. ça demande du boulot en plus. Si tu veux par exemple activer des warnings pour le compilateur, ça ne sera pas les mêmes paramètres pour GCC et MSVC.

Donc pour moi, imposer le compilateur ou le système de build, c’est le même probleme : plus tu mets de contraintes sur l’utilisation de ton projet, moins il sera facilement adopté. Mais lever ces contraintes, c’est du boulot en plus. C’est un compromis a faire, qui dépend de tes moyens et de tes objectifs.

J’ai même l’impression que c’est assez courant que les projets imposent le compilateur, voire une version spécifique du compilateur.

(Mon message n’est pas pour dire de ne pas utiliser de système de build, au contraire. Je n’ai pas utilisé de makefile depuis au moins 20 ans)

Je ne suis pas forcement d’accord avec la réponse de adri1. Supporter plusieurs plateformes, plusieurs compilateurs, etc. ça demande du boulot en plus. Si tu veux par exemple activer des warnings pour le compilateur, ça ne sera pas les mêmes paramètres pour GCC et MSVC.

Je ne vois vraiment pas en quoi c’est en désaccord avec mon propos. Ça me parait être une question plutôt orthogonale. Déjà d’une part je n’ai pas affirmé que CMake enlevait complètement les efforts à faire, simplement qu’il les réduit beaucoup par rapport à un Makefile. Ensuite, concernant les warnings en particulier, j’ai du mal à imaginer un scénario où les warnings sont un build requirement au sens strict du terme. Les warnings sont utiles au développement, mais si, en tant qu’utilisateur, tu reçois un projet qui peut se compiler avec CMake, peu importe si ton compilateur préféré n’a pas les flags de warnings. Ça t’empêchera pas de pouvoir compiler la librairie e.g. en debug ou en release. Évidemment, si le CMake est mal écrit et que la librairie force ses flags n’importe comment sans vérifier quel compilo est utilisé, c’est un autre problème…

En désaccord dans le sens ou je pense pas que ce soit un probleme d’imposer le compilateur. C’est un choix technique a faire.

Et pour les "warnings", je voulais dire les options de compilation au sens large.

En désaccord dans le sens ou je pense pas que ce soit un probleme d’imposer le compilateur. C’est un choix technique a faire.

Ça tombe bien, j’ai listé un ensemble de cas où imposer un compilateur est un problème. Si tu es en dehors de ces cas, tant mieux pour toi (mais c’est pas un luxe que tout le monde a, et surtout imposer un compilateur donné est rarement une nécessité pour que la build passe…).

Et pour les "warnings", je voulais dire les options de compilation au sens large.

On peut noter que pour tout ce qui est build requirements, tu as des abstractions via les compile features. Évidemment c’est pas parfait, mais ça couvre déjà pas mal de cas (standard C ou C++ notamment). T’as pas besoin de supporter tous les compilos pour ton environnement de dev avec toutes les options de compilations qui vont bien. À moins de réellement dépendre d’une feature obscure d’un compilateur, il y a zéro raison de forcer ce choix aux utilisateurs finaux qui ont juste besoin de pouvoir build (bien sûr, tu peux ne pas offrir de support actif pour ces cas d’usages, c’est encore une autre question).