Quelles sont les différences entre Autotools, Cmake et Scons?
Quelles sont les différences entre Autotools, Cmake et Scons?
En vérité, le seul véritable "avantage salvateur" d’Autotools est que c’est ce que tous les GNU projets utilisent largement.
Problèmes avec Autotools:
- Véritable syntaxe de macro ARCANE m4 combinée à un script Shell vif et torsadé pour les tests de "compatibilité", etc.
- Si vous ne faites pas attention, va gâcher la capacité de compilation croisée (il convient de noter que Nokia est venu avec Scratchbox/Scratchbox2 à côté fortement brisé les configurations de construction Autotools pour Maemo/Meego.) Si vous, pour tout raison, si vous avez des chemins fixes et statiques dans vos tests, vous allez interrompre la prise en charge de la compilation croisée, car elle ne respectera pas votre spécification de système et elle extraira des éléments de votre système hôte. Si vous interrompez la prise en charge de la compilation croisée, votre code devient inutilisable pour des tâches telles que OpenEmbedded et le rend "amusant" pour les distributions qui essaient de créer leurs versions sur un compilateur croisé plutôt que sur la cible.
- Est-ce qu'une quantité énorme de tests pour les problèmes avec les anciens compilateurs cassés que PERSONNE utilise actuellement avec à peu près n'importe quoi la production dans ce jour et l'âge. Sauf si vous construisez quelque chose comme glibc, libstdc ++ ou GCC sur une version vraiment ancienne de Solaris, AIX ou Par exemple, les tests sont une perte de temps et une source pour de très nombreuses ruptures potentielles de choses telles que mentionnées ci-dessus.
- Il est assez pénible d’obtenir une installation d’Autotools pour générer du code utilisable pour un système Windows. (Même si je ne me sers que de peu de choses sous Windows, le développement de code supposé multiplate-forme est une source de préoccupation majeure.)
- Quand ça casse, vous allez dépenser HEURES pourchasser votre queue en essayant de régler les choses que quiconque a écrit le script a mal agencé pour trier votre construction (en fait, c’est ce que j’essaie de faire (ou plutôt de détruire complètement Autotools; je doute qu’il reste assez de temps dans le reste de ce mois pour résoudre le désordre .. .) pour le travail en ce moment même que je tape ceci. Apache Thrift a un de ces CASSÉ construire des systèmes qui ne pas compiler.)
- Les utilisateurs "normaux" sont en fait PAS va juste 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 souvent pas les archives. C'est du snobisme de la part de tout le monde de présumer que ce sera le cas ici. Les utilisateurs typiques de tarballs sont les développeurs qui font des choses, alors ils vont être frappés par la cassure si c'est là.
Cela fonctionne ... la plupart du temps ... est tout ce que vous pouvez dire sur Autotools. C'est un système qui résout plusieurs problèmes qui ne concerne que le projet GNU ... pour leur code de base, chaîne d'outils. (Edit (24/05/2014)): Il convient de noter que ce type de problème est potentiellement MAUVAIS Ce qui doit nous inquiéter - Heartbleed est partiellement issu de cette pensée et avec des systèmes modernes et corrects, vous vraiment n'avez pas Toute entreprise qui gère une grande partie de ce que corrige Autotools. GNU doit probablement supprimer cruellement la base de code, à la lumière de ce qui s’est passé avec Heartbleed). Vous pouvez vous en servir pour réaliser votre projet. pour un projet de petite taille pour lequel vous ne vous attendez pas à travailler ailleurs que sous Linux ou pour lequel l'ensemble d'outils GNU fonctionne clairement. L’affirmation qu’il "s’intègre bien à Linux" est bien la déclaration en gras et assez incorrect . Il s'intègre raisonnablement bien à la suite d'outils GNU et résout les problèmes que le service 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 remplace plutôt Make/GMake/etc. et semble jolie Nice, toutes choses considérées Cependant ...
- C’est toujours vraiment un outil POSIX uniquement. MinGW pourrait probablement créer plus facilement des éléments Windows avec cela qu'avec Autotools, mais il reste plus adapté aux tâches POSIX et vous devez installer Python et SCons de l'utiliser.
- La compilation croisée pose des problèmes si vous n'utilisez pas quelque chose comme Scratchbox2.
- Certes plus lent et moins stable que CMake de leur propre comparaison. Ils arrivent avec des timides (le côté POSIX a besoin de faire/construire pour construire ...) des négatifs pour CMake par rapport à SCons. (En passant, si vous avez besoin de QUE beaucoup d'extensibilité par rapport à d'autres solutions, vous devriez vous demander si votre projet est trop compliqué ...)
Les exemples donnés pour CMake dans ce fil sont un peu fictifs.
Pourtant...
- Vous aurez besoin d'apprendre une nouvelle langue.
- Il y a des choses contre-intuitives si vous avez l'habitude de Make, SCons ou Autotools.
- Vous devrez installer CMake sur le système pour lequel vous construisez.
- Vous aurez besoin d'un compilateur C++ solide si vous ne disposez pas de fichiers binaires pré-construits.
En vérité, vos objectifs devraient dicter ce que vous choisissez ici.
- Avez-vous besoin de traiter avec un LOT de chaînes d'outils cassées pour produire un binaire valide? Dans l'affirmative, vous pouvez envisager d'utiliser Autotools, tout en étant conscient des inconvénients que j'ai mentionnés ci-dessus. CMake peut faire face à beaucoup de cela, mais il est moins inquiétant qu’Autotools. Les SCons peuvent être étendus pour s’inquiéter à ce sujet, mais ce n’est pas une réponse immédiate.
- Avez-vous besoin de vous soucier des cibles Windows? Si tel est le cas, Autotools devrait être littéralement hors d’usage. Si tel est le cas, SCons pourrait ne pas être un bon choix. Si oui, CMake est un choix solide.
- Avez-vous besoin de vous inquiéter de la compilation croisée (applications/bibliothèques universelles, comme Google Protobufs, Apache Thrift, etc.) DEVRAIT attention à ce sujet ...)? Si tel est le cas, Autotools pourrait travailler pour vous tant que vous n'avez pas à vous soucier de Windows, mais vous êtes passerez beaucoup de temps à maintenir votre système de configuration à mesure que les choses changeront pour vous. SCons est pratiquement impossible à utiliser pour le moment, à moins que vous n'utilisiez Scratchbox2. Il n'a vraiment aucune maîtrise de la compilation croisée et vous devrez utiliser cette extensibilité et la maintenir de la même manière que vous le feriez avec. vous allez avec Automake. Si tel est le cas, vous pouvez envisager CMake car il prend en charge la compilation croisée sans autant d’inquiétude de fuites hors du bac à sable et fonctionne avec/sans quelque chose comme Scratchbox2 et intègre bien avec des choses comme OpenEmbedded.
Il y a une raison pour laquelle de nombreux projets abandonnent qmake, Autotools, etc. et passent à CMake. Jusqu'ici, je peux m'attendre à ce qu'un projet basé sur CMake se retrouve dans une situation de compilation croisée ou dans une configuration de VisualStudio ou n'ait besoin que d'une petite quantité de nettoyage, car le projet ne tenait pas compte des éléments Windows uniquement ou OSX. à la base de code. Je ne peux pas vraiment espérer cela d'un projet basé sur SCons - et je m'attends vraiment à ce qu'un tiers ou plus des projets Autotools aient obtenu QUELQUE CHOSE faux qui empêche de construire correctement sur n'importe quel contexte sauf celui de l'hôte qui en construit ou celui de Scratchbox2.
Une distinction importante doit être faite entre les utilisateurs des outils. Cmake est un outil qui doit être utilisé par l'utilisateur lors de la construction du logiciel. Les outils automatiques sont utilisés pour générer une archive de distribution qui peut être utilisée pour créer le logiciel en utilisant uniquement les outils standard disponibles sur tout système compatible SuS. En d'autres termes, si vous installez un logiciel à partir d'une archive tar construite à l'aide des outils automatiques, vous n'utilisez pas les outils automatiques . D'autre part, si vous installez un logiciel qui utilise Cmake, alors vous utilisez et vous devez l'avoir installé pour construire le logiciel.
La grande majorité des utilisateurs n'ont pas besoin d'installer les outils automatiques sur leur boîte. Historiquement, beaucoup de confusion a été causée par le fait que de nombreux développeurs distribuent des archives mal formées qui forcent l’utilisateur à exécuter autoconf pour régénérer le script configure, ce qui est une erreur de mise en forme. Plus de confusion a été causée par le fait que la plupart des principales distributions Linux installent plusieurs versions des outils automatiques, alors qu'elles ne devraient en installer aucune par défaut. Les développeurs essaient encore plus de confusion en essayant d'utiliser un système de contrôle de version (par exemple, cvs, git, svn) pour distribuer leurs logiciels plutôt que de créer des archives.
Il ne s'agit pas de GNU normes de codage.
Les avantages actuels des outils automatiques, en particulier lorsqu'ils sont utilisés avec automake, sont qu'ils s'intègrent très bien à la construction de la distribution Linux.
Avec cmake par exemple, il faut toujours "était-ce -DCMAKE_CFLAGS ou -DCMAKE_C_FLAGS dont j'avais besoin?" Non, ce n'est ni l'un ni l'autre, c'est "-DCMAKE_C_FLAGS_RELEASE". Ou -DCMAKE_C_FLAGS_DEBUG. C'est déroutant - dans autoconf, c'est juste ./configure CFLAGS = "- O0 -ggdb3" et vous l'avez.
Dans l'intégration avec les infrastructures de construction, scons pose le problème suivant: vous ne pouvez pas utiliser make %{?_smp_mflags}, _smp_mflags, dans ce cas, il s'agit d'une macro RPM qui se développe grossièrement pour (le pouvoir peut le définir) l'alimentation du système. Les gens placent des choses comme -JNCPUS ici dans leur environnement. Avec des scons qui ne fonctionnent pas, les paquets utilisant scons peuvent uniquement recevoir des distributions intégrées en série.
Ce qu'il est important de savoir sur les outils automatiques, c'est qu'ils ne constituent pas un système de construction général. Ils implémentent les normes de codage GNU et rien d'autre. Si vous voulez créer un paquet qui respecte toutes les normes GNU, les outils automatiques sont donc un excellent outil pour le travail. Sinon, vous devriez utiliser Scons ou CMake. (Par exemple, voir cette question .) Cette incompréhension courante est à l'origine de la plupart des frustrations suscitées par Autotools.
Bien que du point de vue des développeurs, cmake soit actuellement le plus facile à utiliser, du point de vue de l'utilisateur, les outils automatiques ont un gros avantage.
autotools génère un script de configuration de fichier unique et tous les fichiers pour le générer sont livrés avec la distribution. il est facile à comprendre et à corriger avec l’aide de grep/sed/awk/vi. Comparez ceci à Cmake où de nombreux fichiers se trouvent dans/usr/share/cmak */Modules, qui ne peuvent pas être corrigés par l'utilisateur à moins d'avoir un accès administrateur.
Ainsi, si quelque chose ne fonctionne pas correctement, il est généralement facile de le "réparer" en utilisant les outils Unix standard (grep/sed/awk/vi, etc.) de manière efficace sans avoir à comprendre le système de construction.
Avez-vous déjà fouillé dans votre répertoire de compilation cmake pour savoir ce qui ne va pas? Comparé au simple script shell qui peut être lu de haut en bas, il est assez difficile de suivre les fichiers Cmake générés pour savoir ce qui se passe. De même, avec CMake, l’adaptation des fichiers FindFoo.cmake requiert non seulement une connaissance du langage CMake, mais peut également nécessiter des privilèges de superutilisateur.