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

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

En vérité, la seule véritable «grâce salvatrice» d'Autotools est que c'est ce que tous les projets GNU utilisent largement.

Problèmes avec les outils automatiques:

• Véritable syntaxe de macros ARCANE m4 combinée à un script shell détaillé et tordu pour des tests de "compatibilité", etc.
• Si vous ne faites pas attention, vous allez gâcher la capacité de compilation croisée (Il faut bien noter que Nokia est venu avec Scratchbox / Scratchbox2 à côté étape très configurations de construction Autotools cassé pour Maemo / Meego.) Si vous, pour tout raison, avez des chemins fixes et statiques dans vos tests, vous allez interrompre la prise en charge de la compilation croisée car elle n'honorera pas vos spécifications sysroot et tirera des éléments de votre système hôte. Si vous interrompez la prise en charge de la compilation croisée, cela rend votre code inutilisable pour des choses comme OpenEmbedded et le rend "amusant" pour les distributions essayant de construire leurs versions sur un compilateur croisé plutôt que sur la cible.
• Effectue une énorme quantité de tests pour les problèmes avec les anciens compilateurs cassés que NOBODY utilise actuellement avec à peu près n'importe quoi dans la production de nos jours. À moins que vous ne construisiez quelque chose comme glibc, libstdc ++ ou GCC sur une version vraiment ancienne de Solaris, AIX ou similaire, les tests sont une perte de temps et sont une source pour de très nombreuses ruptures potentielles de choses comme mentionné ci-dessus.
• C'est à peu près une expérience pénible d'obtenir une configuration Autotools pour créer du code utilisable pour un système Windows. (Bien que je sois peu utilisé pour Windows, c'est une préoccupation sérieuse si vous développez du code prétendument multiplateforme.)
• Quand il se casse, vous allez passer des HEURES à courir après votre queue en essayant de trier les choses que celui qui a écrit le script s'est trompé pour trier votre build (En fait, c'est ce que j'essaie de faire (ou, plutôt, arracher Autotools complètement - je doute qu'il y ait assez de temps dans le reste de ce mois pour trier le désordre ...) pour travailler dès maintenant que je tape ceci.Apache Thrift a l'un de ces systèmes de construction BROKEN qui ne traversera pas -compiler.)
• Les utilisateurs "normaux" ne vont PAS simplement faire "./configure; make" - pour beaucoup de choses, ils vont tirer un paquet fourni par quelqu'un, comme un PPA, ou son fournisseur de distribution. Les utilisateurs "normaux" ne sont pas des développeurs et ne saisissent pas les tarballs dans de nombreux cas. C'est du snobisme de la part de tout le monde de présumer que ce sera le cas là-bas. Les utilisateurs typiques des tarballs sont des développeurs qui font des choses, donc ils vont être critiqués avec le bris si c'est le cas.

Cela fonctionne ... la plupart du temps ... c'est tout ce que vous pouvez dire sur Autotools. C'est un système qui résout plusieurs problèmes qui ne concernent vraiment que le projet GNU ... pour leur code de base, la chaîne d'outils de base. (Edit (24/05/2014): Il convient de noter que ce type de préoccupation est potentiellement une MAUVAISE inquiétude - Heartbleed provient en partie de cette réflexion et avec des systèmes corrects et modernes, vous avez vraimentn'ont aucune entreprise qui s'occupe de la plupart des corrections apportées par Autotools. GNU doit probablement faire une suppression brutale de la base de code, à la lumière de ce qui s'est passé avec Heartbleed) Vous pouvez l'utiliser pour faire votre projet et cela pourrait bien fonctionner pour un petit projet que vous ne vous attendez pas à travailler ailleurs que Linux ou où la chaîne d'outils GNU fonctionne clairement correctement. L'affirmation selon laquelle il "s'intègre bien avec Linux" est assez audacieuse et tout à fait incorrecte . Il s'intègre raisonnablement bien à la suite d'outils GNU et résout les problèmes que l'informatique a avec ses objectifs.

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

SCons est plus un remplacement pour Make / GMake / etc. et semble assez agréable, tout bien considéré Cependant ...

• Il s'agit toujours vraiment d'un outil POSIX uniquement. Vous pourriez probablement obtenir plus facilement MinGW pour construire des trucs Windows avec cela qu'avec Autotools, mais il est toujours vraiment plus adapté à faire des trucs POSIX et vous auriez besoin d'installer Python et SCons pour l'utiliser.
• Il y a des problèmes lors de la compilation croisée, sauf si vous utilisez quelque chose comme Scratchbox2.
• Certes, plus lent et moins stable que CMake de leur propre comparaison. Ils proposent des points négatifs (le côté POSIX a besoin de make / gmake pour construire ...) des négatifs pour CMake par rapport aux SCons. (En passant, si vous avez besoin de TELLEMENT 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 faux.

Toutefois...

• Vous devrez apprendre une nouvelle langue.
• Il y a des choses contre-intuitives si vous êtes habitué à 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 n'avez pas de binaires pré-construits pour cela.

En vérité, vos objectifs doivent dicter ce que vous choisissez ici.

• Avez-vous besoin de faire face à BEAUCOUP de chaînes d'outils cassées pour produire un binaire de travail valide? Si oui, vous voudrez peut-être envisager Autotools, é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 inquiète moins que les Autotools. Les SCons peuvent être étendus pour s'en inquiéter, mais ce n'est pas une réponse prête à l'emploi.
• Avez-vous besoin de vous soucier des cibles Windows? Si c'est le cas, Autotools devrait être littéralement hors de course. Si c'est le cas, les SCons peuvent / peuvent ne pas être un bon choix. Si c'est le cas, CMake est un choix solide.
• Avez-vous besoin de vous soucier de la compilation croisée (applications / bibliothèques universelles, des choses comme Google Protobufs, Apache Thrift, etc. DEVRAIT vous en soucier ...)? Si c'est le cas, Autotools pourraittravailler 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 à mesure que les choses évoluent. SCons est presque un non-droit pour le moment, sauf si vous utilisez Scratchbox2 - il n'a vraiment pas de poignée sur la compilation croisée et vous devrez 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 car il prend en charge la compilation croisée sans autant de soucis de fuite hors du bac à sable et fonctionnera avec / sans quelque chose comme Scratchbox2 et s'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'à présent, je peux m'attendre à ce qu'un projet basé sur CMake tombe dans une situation de compilation croisée ou sur une configuration VisualStudio ou n'ait besoin que d'une petite quantité de nettoyage car le projet ne tenait pas compte des parties Windows ou OSX uniquement à la base de code. Je ne peux pas vraiment m'attendre à ce que sur un projet basé sur SCons - et je m'attends à ce qu'un tiers ou plus de projets Autotools se soient trompés QUELQUE CHOSE ce qui l'empêche de se construire correctement dans n'importe quel contexte, à l'exception de celui de l'hôte ou 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 tar 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 qui a été créée à l'aide des outils automatiques, vous n'utilisez pas les outils automatiques . D'autre part, si vous installez un logiciel qui utilise Cmake, vous êtes utilisez Cmake et doit avoir installé le logiciel pour construire.

La grande majorité des utilisateurs n'ont pas besoin d'avoir les outils automatiques installés sur leur box. Historiquement, une grande confusion a été causée parce que de nombreux développeurs distribuent des tarballs malformés qui forcent l'utilisateur à exécuter autoconf pour régénérer le script de configuration, et il s'agit d'une erreur de package. 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. Encore plus de confusion 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 leurs logiciels plutôt que de construire des tarballs.

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

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, 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 déroutant - dans autoconf, c'est juste ./configure CFLAGS = "- O0 -ggdb3" et vous l'avez.

En intégration avec des infrastructures de build, scons a le problème que vous ne pouvez pas utiliser make %{?_smp_mflags}, _smp_mflagsdans ce cas, c'est une macro RPM qui se développe approximativement pour (l'administrateur peut le définir) la puissance du système. Les gens mettent des choses comme -jNCPUS ici à travers leur environnement. Avec scons qui ne fonctionne pas, les packages utilisant scons ne peuvent donc obtenir que des distributions intégrées en série.

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 implémentent les normes de codage GNU et rien d'autre. Si vous voulez créer un package qui respecte toutes les normes GNU, alors les Autotools sont un excellent outil pour le travail. Si vous ne le faites pas, vous devez utiliser Scons ou CMake. (Par exemple, voir cette question .) Ce malentendu courant est à l'origine de la plupart des frustrations liées aux outils automatiques.

Alors que du point de vue des développeurs, cmake est actuellement le plus facile à utiliser, du point de vue utilisateur, les outils automatiques ont un gros avantage

les autotools génèrent 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 à l'aide de grep / sed / awk / vi. Comparez cela à Cmake où de nombreux fichiers se trouvent dans / usr / share / cmak * / Modules, qui ne peuvent pas être corrigés par l'utilisateur à moins qu'il n'ait un accès administrateur.

Donc, si quelque chose ne fonctionne pas tout à fait, il peut généralement être facilement «corrigé» en utilisant des 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 construction cmake pour découvrir ce qui ne va pas? Comparé au simple shellscript qui peut être lu de haut en bas, suivre les fichiers Cmake générés pour découvrir ce qui se passe est assez difficile. De plus, avec CMake, l'adaptation des fichiers FindFoo.cmake nécessite non seulement une connaissance du langage CMake, mais également des privilèges de superutilisateur.