Ben... Tu cites la raison dans ton message! :-)
Certes c'est de la merde. C'est complexe, c'est parfois même tordu. Mais ça reste le mieux au niveau système de build.
La seule autre alternative un peu sérieuse que je connaisse est CMake. Ils font des choses mieux, mais d'autres choses moins bien.
D'ailleurs par endroits, j'ai un peu cmake-ifié notre autobuild. Notamment j'ai fait en sorte que notre script de compilation finisse et liste l'ensemble des dépendances manquantes plutôt que s'arrêter à chaque fois (obligeant à relancer le ./configure 20 fois, en installant les dépendances une par une lors d'un nouveau build; quelle perte de temps). C'est un des trucs confortables de cmake (de manière générale, cmake produit des sorties de terminal plus agréable que les autotools).
Par contre, là où CMake est problématique est qu'ils ne cherchent pas vraiment à suivre un "standard" de compilation (autotools suivent les GNU Coding Standards):
Par exemple, pour cross-compiler, il faut un fichier toolchain séparé, alors que le concept même de toolchain est déjà plutôt standardisé. C'est d'autant plus idiot qu'au final, on utilise le même fichier toolchain pour quasiment tous les projets (puisque c'est standardisé, comme je disais). Mais ça veut dire aussi que certains projets qui ne comprennent pas les besoins de standardisation peuvent rajouter des options et rendre les choses compliquées inutilement (bon tu vas me dire, on peut aussi le faire avec les autotools, mais disons que la façon d'aborder est différente: autotools standardise par défaut, sans rien faire, et autorise à tout tweaker après coup; CMake ne fait rien par défaut, donne une liberté totale, en autorisant donc à suivre les standards si on veut, ce qui pousse les développeurs moins expérimentés à faire des choses inutiles).
Avec les autotools, tout build correctement créé autour d'un code lui aussi générique est automatiquement portable sur toute plateforme, sans rien faire ni changer une ligne.
De même, certaines cibles vraiment basiques ne sont même pas implémentées par défaut et c'est aux développeurs de les créer à la main (avec tous les problèmes et bugs que cela va créer). Par exemple, pas de cible "uninstall" par défaut dans un projet CMake! On doit le faire à la main alors que c'est totalement automatisable (on retire la même liste de fichiers que ce qu'on a installé). Un vrai problème pour moi. De même pas de make dist et encore moins de make distcheck, 2 commandes super importantes. Il faut donc les implémenter soi-même.
Et ainsi de suite.
Bon CMake reste très bon; je maintiens même des projets qui utilisent CMake, et ne prévois absolument pas de changer. Cependant au final autotools a beaucoup de points qui en font la "meilleure merde" qu'on ait.
Quant aux autres systèmes de build (génériques, je parle pas de systèmes pour langage particulier qui parfois sont OK), c'est en général mauvais. Mais je vais pas non plus prétendre connaître tous les systèmes de build.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: autotools
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Michael Natterer, mainteneur de GIMP. Évalué à 10.
Ben... Tu cites la raison dans ton message! :-)
Certes c'est de la merde. C'est complexe, c'est parfois même tordu. Mais ça reste le mieux au niveau système de build.
La seule autre alternative un peu sérieuse que je connaisse est CMake. Ils font des choses mieux, mais d'autres choses moins bien.
D'ailleurs par endroits, j'ai un peu cmake-ifié notre autobuild. Notamment j'ai fait en sorte que notre script de compilation finisse et liste l'ensemble des dépendances manquantes plutôt que s'arrêter à chaque fois (obligeant à relancer le
./configure20 fois, en installant les dépendances une par une lors d'un nouveau build; quelle perte de temps). C'est un des trucs confortables de cmake (de manière générale, cmake produit des sorties de terminal plus agréable que les autotools).Par contre, là où CMake est problématique est qu'ils ne cherchent pas vraiment à suivre un "standard" de compilation (autotools suivent les GNU Coding Standards):
uninstall" par défaut dans un projet CMake! On doit le faire à la main alors que c'est totalement automatisable (on retire la même liste de fichiers que ce qu'on a installé). Un vrai problème pour moi. De même pas demake distet encore moins demake distcheck, 2 commandes super importantes. Il faut donc les implémenter soi-même.Bon CMake reste très bon; je maintiens même des projets qui utilisent CMake, et ne prévois absolument pas de changer. Cependant au final autotools a beaucoup de points qui en font la "meilleure merde" qu'on ait.
Quant aux autres systèmes de build (génériques, je parle pas de systèmes pour langage particulier qui parfois sont OK), c'est en général mauvais. Mais je vais pas non plus prétendre connaître tous les systèmes de build.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]