Je ne suis pas d'accord. Autotools sous Windows, ça lance tellement de process que ça rajoute un overhead énorme par rapport à ce que cela fait. Dans le lien donné plus haut sur la migration de GStreamer à Meson, le développeur explique qu'ils ont gagné énormément de temps sur le build Windows (×ばつ 10) par rapport à autotools, sans doute pour cette raison là. Bien sûr, sur des gros projets le temps de build sera largement dominé par le compilateur, mais sur des projets plus petits, la lenteur du build system peut avoir un impact non négligeable.
Ensuite autotools c'est aussi différentes versions de autobidule et autotruc à installer en parallèle parce que non compatibles. Alors oui tu peux faire de la cross-compilation de Linux vers Windows, mais dans ce cas il ne faut s'offusquer qu'on dise que c'est trop "Linux only" (par opposition à Windows, pas par rapport aux autres UNIX).
Ensuite, tu ne pourras à ma connaissance pas builder avec le compilateur de Visual Studio si tu es sous Windows. Si on te donne des bibliothèques proprios pour lesquelles on ne te donne que les binaires et que tu dois t'intégrer avec, tu fais quoi ? Idem pour les symboles de debug différents entre gcc et Visual Studio qui font que tu peux avoir envie d'utiliser un compilateur unique pour être capable de déboguer le bouzin.
Enfin, autotools ne fonctionne qu'avec Make, avec tous les reproches qu'on peut faire sur Make, là où CMake et Meson sont compatibles ninja. Ninja a pour objectif de fournir un format très simple et hautement parallélisable, parce que ce sont les besoins de notre l'époque. De son côté, GNU Make va par défaut chercher des fichiers de logiciels de version obsolètes RCS et SCCS parce qu'il a été développé à une autre époque et qu'il a forcément du "bagage". "bagage" qui n'a pas été jeté parce que la compatibilité à tout prix empêche aussi l'évolution. GNU Make est un très bon logiciel, et tout à fait honorable, mais plus forcément une solution optimale au problème.
CMake et Meson (et bien d'autres sans doute), ça produit des projets pour Visual Studio et Xcode, et ça marche aussi sous Linux. Autotools n'a à ma connaissance pas apporté de solutions à ces problèmes (mais je serais ravi qu'on me pointe des solutions qui seraient passées sous mon radar).
Pour finir, voilà deux liens de l'auteur de Meson sur les reproches qu'il a fait à autotools et CMake, ainsi que des anti patterns Meson (parce qu'aucun outil n'est parfais, les soucis sont juste différents):
[^] # Re: Une défense des autotools
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2. Dernière modification le 15 juin 2018 à 18:17.
Je ne suis pas d'accord. Autotools sous Windows, ça lance tellement de process que ça rajoute un overhead énorme par rapport à ce que cela fait. Dans le lien donné plus haut sur la migration de GStreamer à Meson, le développeur explique qu'ils ont gagné énormément de temps sur le build Windows (×ばつ 10) par rapport à autotools, sans doute pour cette raison là. Bien sûr, sur des gros projets le temps de build sera largement dominé par le compilateur, mais sur des projets plus petits, la lenteur du build system peut avoir un impact non négligeable.
Ensuite autotools c'est aussi différentes versions de autobidule et autotruc à installer en parallèle parce que non compatibles. Alors oui tu peux faire de la cross-compilation de Linux vers Windows, mais dans ce cas il ne faut s'offusquer qu'on dise que c'est trop "Linux only" (par opposition à Windows, pas par rapport aux autres UNIX).
Ensuite, tu ne pourras à ma connaissance pas builder avec le compilateur de Visual Studio si tu es sous Windows. Si on te donne des bibliothèques proprios pour lesquelles on ne te donne que les binaires et que tu dois t'intégrer avec, tu fais quoi ? Idem pour les symboles de debug différents entre gcc et Visual Studio qui font que tu peux avoir envie d'utiliser un compilateur unique pour être capable de déboguer le bouzin.
Enfin, autotools ne fonctionne qu'avec Make, avec tous les reproches qu'on peut faire sur Make, là où CMake et Meson sont compatibles ninja. Ninja a pour objectif de fournir un format très simple et hautement parallélisable, parce que ce sont les besoins de notre l'époque. De son côté, GNU Make va par défaut chercher des fichiers de logiciels de version obsolètes RCS et SCCS parce qu'il a été développé à une autre époque et qu'il a forcément du "bagage". "bagage" qui n'a pas été jeté parce que la compatibilité à tout prix empêche aussi l'évolution. GNU Make est un très bon logiciel, et tout à fait honorable, mais plus forcément une solution optimale au problème.
CMake et Meson (et bien d'autres sans doute), ça produit des projets pour Visual Studio et Xcode, et ça marche aussi sous Linux. Autotools n'a à ma connaissance pas apporté de solutions à ces problèmes (mais je serais ravi qu'on me pointe des solutions qui seraient passées sous mon radar).
Pour finir, voilà deux liens de l'auteur de Meson sur les reproches qu'il a fait à autotools et CMake, ainsi que des anti patterns Meson (parce qu'aucun outil n'est parfais, les soucis sont juste différents):