Quelles sont les différences entre Autotools, Cmake et Scons ?

Question

Quelles sont les différences entre Autotools, Cmake et Scons ?

Answer 1

En vérité, la seule véritable "grâce" d'Autotools est que c'est ce que tous les projets GNU utilisent en grande partie.

Problèmes avec Autotools :

• Une syntaxe macro m4 vraiment ARCANE combinée à un script shell verbeux et tordu pour les tests de "compatibilité", etc.
• Si vous ne faites pas attention, vous sera perturber la capacité de compilation croisée (c'est (il faut noter que Nokia a créé Scratchbox/Scratchbox2 pour contourner le problème de la compilation croisée). hautement les configurations brisées d'Autotools pour Maemo/Meego). Si, pour une raison quelconque, vous avez des chemins fixes et statiques dans vos tests, vous allez casser le support de la compilation croisée parce qu'il ne respectera pas votre spécification sysroot et qu'il tirera des choses hors de votre système hôte. Si vous brisez le support de la compilation croisée, cela rend votre code inutilisable pour des choses comme OpenEmbedded et rend la chose "amusante" pour les distributions qui essaient de construire leurs versions sur un compilateur croisé plutôt que sur la cible.
• Effectue une quantité ÉNORME de tests pour détecter les problèmes avec des compilateurs anciens et défectueux. NOBODY qu'on utilise actuellement avec à peu près tout ce qui est production à notre époque. A moins que vous ne construisiez quelque chose comme glibc, libstdc++, ou GCC sur un système vraiment anciennement version de Solaris, AIX, ou autre, les tests sont une perte de temps et sont une source pour beaucoup, beaucoup de ruptures potentielles de choses comme celles mentionnées ci-dessus.
• C'est une expérience plutôt douloureuse que d'obtenir une configuration Autotools pour construire un code utilisable pour un système Windows. (Bien que je n'aie que peu d'utilité pour Windows, c'est un problème sérieux si vous développez du code prétendument multiplateforme).
• Quand il se casse, vous allez dépenser HEURES se creuser la tête pour essayer de régler les choses que celui qui a écrit le script s'est trompé pour régler votre build (En fait, c'est ce que j'essaie de faire (ou, plutôt, de supprimer complètement Autotools - je doute qu'il y ait assez de temps dans le reste du mois pour régler ce désordre...) pour le travail en ce moment même où je tape ceci. Apache Thrift a un de ces BROKEN systèmes de construction qui ne font pas de compilation croisée).
• Les utilisateurs "normaux" sont en fait PAS vont simplement faire "./configure ; make"- pour beaucoup de choses, ils vont tirer un paquet fourni par quelqu'un, comme un PPA, ou leur fournisseur de distribution. Les utilisateurs "normaux" ne sont pas des développeurs et ne récupèrent pas les paquets dans la plupart des cas. C'est du snobisme de la part de tout le monde de supposer que ce sera le cas ici. Les utilisateurs typiques de tarballs sont des développeurs qui font des choses, et c'est donc à eux qu'il faut s'en prendre s'ils sont cassés.

Il fonctionne... la plupart du temps... c'est tout ce qu'on peut dire d'Autotools. C'est un système qui résout plusieurs problèmes qui ne concernent vraiment que le projet GNU...pour leur base, le code de base de la chaîne d'outils. (Edit (24/05/2014) : Il faut noter que ce type de préoccupation est potentiellement... MAUVAIS Heartbleed découle en partie de cette façon de penser et, avec des systèmes modernes et corrects, vous pouvez vous vraiment n'ont pas à s'occuper d'une grande partie de ce que Autotools corrige. Vous pouvez l'utiliser pour votre projet et il pourrait bien fonctionner pour un projet de petite taille qui ne devrait pas fonctionner ailleurs que sous Linux ou pour lequel la chaîne d'outils GNU fonctionne clairement. L'affirmation selon laquelle il "s'intègre bien à Linux" est la suivante tout à fait la déclaration audacieuse et tout à fait incorrect . Il s'intègre raisonnablement bien à la suite d'outils GNU et résout les problèmes que l'informatique rencontre avec ses objectifs.

Cela ne veut pas dire qu'il n'y a pas de problèmes avec les autres options discutées dans le fil de discussion ici.

SCons est plus un remplacement de Make/GMake/etc. et a l'air plutôt bien, tout bien considéré Cependant....

• Il s'agit toujours d'un outil POSIX uniquement. Il est probablement plus facile de faire en sorte que MinGW construise des applications Windows avec cet outil qu'avec Autotools, mais il est toujours plus orienté vers les applications POSIX et vous devrez installer Python. y SCons pour l'utiliser.
• Il a des problèmes de compilation croisée, sauf si vous utilisez quelque chose comme Scratchbox2.
• Il est vrai qu'il est plus lent et moins stable que CMake selon leur propre comparaison. Ils viennent avec des négatifs peu convaincants (le côté POSIX a besoin de make/gmake pour construire...) pour CMake comparé à SCons. (En passant, si vous avez besoin de QUE beaucoup d'extensibilité par rapport à d'autres solutions, vous devriez vous demander si votre projet n'est pas trop compliqué...)

Les exemples donnés pour CMake dans ce fil sont un peu bidons.

Cependant...

• Vous devrez apprendre une nouvelle langue.
• Il y a des choses contre-intuitives si vous êtes habitué à Make, SCons, ou Autotools.
• Vous devez installer CMake sur le système pour lequel vous construisez.
• Vous aurez besoin d'un compilateur C++ solide si vous n'avez pas de binaires préconstruits pour cela.

En vérité, ce sont vos objectifs qui doivent dicter votre choix.

• Avez-vous besoin de traiter avec un LOT de chaînes d'outils cassées pour produire un binaire fonctionnel valide ? Si oui, vous pouvez envisager Autotools, en étant conscient des inconvénients que j'ai mentionnés ci-dessus. CMake peut faire face à beaucoup de ces problèmes, mais il s'en préoccupe moins qu'Autotools. SCons peut être étendu pour s'en préoccuper, mais ce n'est pas une réponse toute faite.
• Avez-vous besoin de vous inquiéter des cibles de Windows ? Si c'est le cas, Autotools devrait être littéralement hors course. Si oui, SCons peut/ne peut pas être un bon choix. Si oui, CMake est un choix solide.
• Avez-vous besoin de vous soucier de la compilation croisée (applications/librairies universelles, comme Google Protobufs, Apache Thrift, etc. DEVRAIT se soucier de cela...) ? Si oui, Autotools pourrait fonctionne pour vous tant que vous n'avez pas à vous soucier de Windows, mais vous allez passer beaucoup de temps à maintenir votre système de configuration au fur et à mesure que les choses changent sur vous. SCons est presque un non sens pour le moment à moins que vous n'utilisiez Scratchbox2- il n'a vraiment pas de gestion de la compilation croisée et vous allez devoir utiliser cette extensibilité et la maintenir de la même manière que vous le ferez avec Automake. Si c'est le cas, vous voudrez peut-être considérer CMake puisqu'il supporte la compilation croisée sans autant de soucis de fuite hors du bac à sable et fonctionnera avec/sans quelque chose comme Scratchbox2 et intègre joliment avec des choses comme OpenEmbedded.

Il y a une raison pour laquelle beaucoup, beaucoup de projets abandonnent qmake, Autotools, etc. et passent à CMake. Jusqu'à présent, je peux m'attendre à ce qu'un projet basé sur CMake se retrouve dans une situation de compilation croisée ou dans une configuration VisualStudio ou qu'il ait seulement besoin d'une petite quantité de nettoyage parce que le projet n'a pas pris en compte les parties du code qui ne sont que pour Windows ou OSX. Je ne peux pas vraiment attendre cela d'un projet basé sur SCons - et je m'attends à ce qu'un tiers ou plus des projets Autotools aient obtenu des résultats positifs. SOMETHING erronée qui l'empêche de se construire correctement sur n'importe quel contexte, sauf celui de la construction de l'hôte ou celui de Scratchbox2.

Answer 2

Une distinction importante doit être faite entre les personnes qui utilisent les outils. Cmake est un outil qui doit être utilisé par l'utilisateur lors de la construction du logiciel. Les autotools sont utilisés pour générer une distribution tarball qui peut être utilisée pour construire le logiciel en utilisant seulement les outils standards disponibles sur n'importe quel système conforme à SuS. En d'autres termes, si vous installez un logiciel à partir d'une archive construite à l'aide des autotools, vous devez n'utilisent pas les autotools . D'un autre côté, si vous installez un logiciel qui utilise Cmake, alors vous sont utilise Cmake et doit être installé pour construire le logiciel.

La grande majorité des utilisateurs n'ont pas besoin d'avoir les autotools installés sur leur boîte. Historiquement, une grande confusion a été causée par le fait que de nombreux développeurs distribuent des tarballs malformés qui obligent l'utilisateur à exécuter autoconf pour régénérer le script configure script, et ceci est une erreur de packaging. Une plus grande confusion a été causée par le fait que la plupart des distributions linux majeures installent plusieurs versions des autotools, alors qu'elles ne devraient en installer aucune par défaut. Une confusion encore plus grande est causée par les développeurs qui tentent d'utiliser un système de contrôle de version (par exemple cvs, git, svn) pour distribuer leur logiciel plutôt que de construire des tarballs.

Answer 3

Ce sujet est déjà abordé dans Scons wiki . Je vous suggère de visiter les liens suivants :

1. http://www.scons.org/wiki/SconsVsOtherBuildTools

Avez-vous consulté un fil de discussion très similaire dans Forum Ubuntu ?

Answer 4

Il ne s'agit pas des normes de codage GNU.

Les avantages actuels des autotools - en particulier lorsqu'ils sont utilisés avec automake - sont qu'ils s'intègrent très bien à la construction d'une distribution Linux.

Avec cmake par exemple, c'est toujours "était-ce -DCMAKE_CFLAGS ou -DCMAKE_C_FLAGS dont j'ai besoin ?". Non, ce n'est ni l'un ni l'autre, c'est "-DCMAKE_C_FLAGS_RELEASE". Ou -DCMAKE_C_FLAGS_DEBUG. C'est confus - dans autoconf, il suffit de ./configure CFLAGS="-O0 -ggdb3" et vous l'avez.

Dans l'intégration avec les infrastructures de construction, scons a le problème que vous ne pouvez pas utiliser make %{?_smp_mflags} , _smp_mflags dans ce cas, il s'agit d'une macro RPM qui correspond approximativement à (l'administrateur peut la définir) la puissance du système. Les gens mettent des choses comme -jNCPUS ici à travers leur environnement. Avec scons, cela ne fonctionne pas, donc les paquets utilisant scons ne peuvent être construits en série que dans les distros.

Answer 5

Ce qu'il est important de savoir sur les Autotools, c'est qu'ils ne sont pas un système de construction général - ils mettent en œuvre les normes de codage GNU et rien d'autre. Si vous voulez faire un paquet qui suit tous les standards GNU, alors les Autotools sont un excellent outil pour ce travail. Si ce n'est pas le cas, alors vous devriez utiliser Scons ou CMake. (Par exemple, voir cette question .) Ce malentendu courant est à l'origine de la plupart des frustrations liées à Autotools.