Un des points très forts de CMake, et il est un des seuls à arriver à ce niveau de fonctionnalité (suivi de près par qmake tout de même), c'est de générer des fichiers projets pour l'IDE de référence de la plate-forme cible.
Pour Windows, il génère des projets Visual Studio, et les compile avec Visual Studio. Pour OS X, ce sont des fichiers XCode. Pour Linux, c'est des Makefile, principalement parce que quand CMake a été conçu, c'était parmi ce qu'il y avait de mieux.
Pourquoi c'est important ? Parce que contrairement au monde Unix où la compilation est avant-tout un agencement élaboré d'outil en ligne de commande qui peuvent être chapeautés par divers "pilotes" (Make, ninja, jam, waf, ...), sur les deux plate-forme propriétaires de référence, la compilation est plutôt vue comme l'une des tâches d'un IDE. Même si cet IDE ne fait que lancer des outils en lignes de commandes, il y a beaucoup de subtilités sur l'utilisation de cette ligne de commande, et elle est beaucoup moins bien documenté vu que globalement, tout le monde utilise l'IDE.
Par exemple, sous Windows, si tu veux que ton programme ait une jolie icône de lancement, il faut embarquer l’icône sous forme de ressource dans le .exe . Ça se fait en environ une minute sous Visual Studio. Pour faire la même chose avec un Makefile, tu y passeras facile une demi-journée. Il semble d'après la lecture de l'article que MacOs X, IOS et Android aient aussi ce genre de chausse-trappe.
Du coup, générer des fichiers projets, c'est important quand on fait de la grande portabilité hétérogène comme l'auteur ici. Et CMake s'en sort bien.
Même si ça ne va pas sans son lot d'inconvénient : du fait de la diversité des capacités des IDE, le comportement et le niveau d'optimisation qu'on peut en attendre est limité. C'est le plus petit dénominateur commun qui s'applique. Je me rappelle avoir essayé de générer avec CMake un fichier Visual Studio qui tirerai partie des fonctionnalités post-build de Visual, c'était mission impossible. Pas portable d'une part, et même pas bidouillable si on accèpte de sacrifier la portabilité.
Du côté du monde Unix, la compilation étant un assemblage de lignes de commande bien documentées, il est possible de jouer pas mal avec la façon dont on pilote tout ça. D'où la pléthore d'outils cités, qui peuvent se focaliser plus des aspects particuliers de la gestion d'un build (notamment la performance), et peuvent écrabouiller CMake sur cet aspect. Sauf que ... ils peuvent se retrouver complètement inutilisables dans un environnement propriétaire dédié car demandant trop de temps au développeur pour maitriser la chaine de compile de la plate-forme cible.
Générer un fichier projet permet aussi d'interagir avec des développeurs de l'équipe qui utilisent ces IDE de référence. Par exemple, le debug de C++ sous Visual est extrêmement bien fait, mais passe par l'IDE. Ce serait dommage de s'en priver juste parce que ninja est hyper mieux que nmake (le make de Visual Studio) mais ne sait pas lancer un IDE en mode debug.
Bref, à mon avis, malgré ses faiblesses, CMake a encore de beaux jours devant lui.
# Le vrai débat : build natif de la plate-forme ou build générique
Posté par Philippe F (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 10.
On passe à côté du vrai débat.
Un des points très forts de CMake, et il est un des seuls à arriver à ce niveau de fonctionnalité (suivi de près par qmake tout de même), c'est de générer des fichiers projets pour l'IDE de référence de la plate-forme cible.
Pour Windows, il génère des projets Visual Studio, et les compile avec Visual Studio. Pour OS X, ce sont des fichiers XCode. Pour Linux, c'est des Makefile, principalement parce que quand CMake a été conçu, c'était parmi ce qu'il y avait de mieux.
Pourquoi c'est important ? Parce que contrairement au monde Unix où la compilation est avant-tout un agencement élaboré d'outil en ligne de commande qui peuvent être chapeautés par divers "pilotes" (Make, ninja, jam, waf, ...), sur les deux plate-forme propriétaires de référence, la compilation est plutôt vue comme l'une des tâches d'un IDE. Même si cet IDE ne fait que lancer des outils en lignes de commandes, il y a beaucoup de subtilités sur l'utilisation de cette ligne de commande, et elle est beaucoup moins bien documenté vu que globalement, tout le monde utilise l'IDE.
Par exemple, sous Windows, si tu veux que ton programme ait une jolie icône de lancement, il faut embarquer l’icône sous forme de ressource dans le .exe . Ça se fait en environ une minute sous Visual Studio. Pour faire la même chose avec un Makefile, tu y passeras facile une demi-journée. Il semble d'après la lecture de l'article que MacOs X, IOS et Android aient aussi ce genre de chausse-trappe.
Du coup, générer des fichiers projets, c'est important quand on fait de la grande portabilité hétérogène comme l'auteur ici. Et CMake s'en sort bien.
Même si ça ne va pas sans son lot d'inconvénient : du fait de la diversité des capacités des IDE, le comportement et le niveau d'optimisation qu'on peut en attendre est limité. C'est le plus petit dénominateur commun qui s'applique. Je me rappelle avoir essayé de générer avec CMake un fichier Visual Studio qui tirerai partie des fonctionnalités post-build de Visual, c'était mission impossible. Pas portable d'une part, et même pas bidouillable si on accèpte de sacrifier la portabilité.
Du côté du monde Unix, la compilation étant un assemblage de lignes de commande bien documentées, il est possible de jouer pas mal avec la façon dont on pilote tout ça. D'où la pléthore d'outils cités, qui peuvent se focaliser plus des aspects particuliers de la gestion d'un build (notamment la performance), et peuvent écrabouiller CMake sur cet aspect. Sauf que ... ils peuvent se retrouver complètement inutilisables dans un environnement propriétaire dédié car demandant trop de temps au développeur pour maitriser la chaine de compile de la plate-forme cible.
Générer un fichier projet permet aussi d'interagir avec des développeurs de l'équipe qui utilisent ces IDE de référence. Par exemple, le debug de C++ sous Visual est extrêmement bien fait, mais passe par l'IDE. Ce serait dommage de s'en priver juste parce que ninja est hyper mieux que nmake (le make de Visual Studio) mais ne sait pas lancer un IDE en mode debug.
Bref, à mon avis, malgré ses faiblesses, CMake a encore de beaux jours devant lui.