CMake ignore toujours sa propre mission.
(dorinlazar.ro)CMake donne de plus en plus l’impression d’être une mauvaise solution pour le C++. Non seulement il ne répond pas aux besoins des développeurs C++, mais il nous maintient aussi dans un âge sombre où l’on construit des makefiles de manière très floue et peu structurée, avec un langage incohérent.
Le problème
Dans le monde de la compilation C++, il existe deux types de problèmes.
- Les problèmes que les projets existants se créent eux-mêmes (note du traducteur : les difficultés liées à la compilation de grands projets déjà existants)
- Les problèmes rencontrés lorsqu’on choisit un nouveau projet en C++
CMake essaie de résoudre le premier problème, et ne résout absolument pas le second. Mais comme il n’essaie même pas de résoudre ces problèmes, cela en fait un outil moins utile.
CMake veut être un traducteur qui convertit la définition d’un projet en système de build, et il a lourdement échoué sur ce point. C’est un mauvais langage de définition de projet, incohérent et peu intuitif.
Toute la communauté C++ parle désormais des outils de Rust. Cargo fait réellement ce que la plupart des développeurs estiment nécessaire. Cargo télécharge des dépendances depuis Internet pour créer une boîte à outils isolée (mauvaise idée), et fournit des bibliothèques liées statiquement (encore une mauvaise idée). Les gens n’ont pas besoin d’un outil qui ajoute des failles de sécurité à un rythme effréné (note du traducteur : l’auteur soutient que la manière dont Cargo récupère automatiquement du code sur Internet pour le lier crée, du point de vue de la sécurité, des vulnérabilités comme les attaques de la chaîne d’approvisionnement. Voir I Hate Rust). Ce dont on a réellement besoin dans Cargo, c’est de :
- une structure de projet très stricte
- un système de configuration très simple qui s’appuie sur un serveur externe pour résoudre le problème de l’emplacement des bibliothèques
- un seul ensemble d’outils.
Les gens ont en réalité besoin de moins de liberté pour pouvoir se concentrer sur leur travail, et ne sont pas doués pour invoquer le compilateur de la manière la plus parfaite possible.
La solution
Il n’y a pas encore de solution. J’écris klb sur mon temps libre, mais ce n’est pas encore une solution. (Il faut du temps et de l’argent.)
Mais ce dont les gens ont besoin est clair : non pas plus d’options, mais moins d’options. Moins d’options signifie moins de façons de rater la compilation d’un projet.
CMake reste aujourd’hui la meilleure option dans l’univers du C++, mais c’est aussi ce qui est arrivé de pire au C++ au cours des 20 dernières années. Tout le reste s’améliore, mais les systèmes de build, eux, ne font qu’empirer.
10 commentaires
La syntaxe est un peu sale, mais je n’ai encore rien trouvé d’aussi bon que CMake.
Faire tourner quelque chose comme M4 dans un environnement non POSIX, c’est un vrai casse-tête.
Comme à la base je n’aime pas trop les environnements de build auxquels on accroche tout un tas de choses, je ne me tourne pas vraiment vers meson ou scone, et premake me donne aussi l’impression qu’il lui manque un petit quelque chose, donc au final j’utilise simplement CMake en me limitant autant que possible à définir le code de la manière la plus simple.
J’utilise CMake depuis longtemps en le maudissant, mais au final il n’y a pas vraiment mieux que CMake. Bazel, c’est vraiment l’enfer… Si je devais démarrer un nouveau projet, je pense que j’envisagerais meson.
Qu’en est-il de Meson ou de Bazel ?
Je n’ai utilisé ni l’un ni l’autre, donc je ne sais pas trop... Personnellement, pour les petits projets, j’aime bien
gprbuild, donc je l’utilise.Les autres méthodes que CMake sont tout aussi compliquées
Au moins, c'est à peu près ça en cross-platform.....
C’est sans doute pour cela que Visual Studio est populaire. On peut commencer à coder immédiatement.
Cela dit, si on entre dans les détails, il n’y a pas de fin non plus.
Rien qu’à voir CMake, ça me donne la nausée…
Je pense qu’il faut considérer que CMake n’est pas un remplaçant de
make, mais plutôt un remplaçant d’autotools (automake).Cela dit, j’ai quand même l’impression que c’est mieux qu’un simple Makefile.
Le mois dernier, j’ai dû analyser un environnement de build composé de plusieurs Makefiles enchevêtrés avec des scripts shell, du Perl, des variables d’environnement de l’OS et toutes sortes d’autres choses, et c’était vraiment à devenir fou.
Dès qu’on essaie de faire les choses dans le détail, on tombe dans un terrier de lapin...