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 «vraie grâce» d’Autotools est que c’est ce que tous les projets GNU utilisent en grande partie.

Problèmes avec Autotools:

  • La véritable syntaxe de la macro ARCANE m4 associée à un script shell verbeux et tordu pour les tests de “compatibilité”, etc.
  • Si vous ne faites pas attention, vous allez gâcher la capacité de compilation croisée (il convient de noter que Nokia a mis au point Scratchbox / Scratchbox2 pour mettre au point des configurations Autotools hautement fracturées pour Maemo / Meego). raison, avoir des chemins fixes et statiques dans vos tests, vous allez briser la prise en charge de la compilation croisée car elle n’honorera pas votre spécification de sysroot et elle extraira les éléments de votre système hôte. Si vous cassez le support de compilation croisée, cela rend votre code inutilisable pour des choses comme OpenEmbedded et le rend “amusant” pour les dissortingbutions essayant de construire leurs versions sur un compilateur croisé plutôt que sur la cible.
  • Existe-t-il une énorme quantité de tests pour les problèmes avec les anciens compilateurs cassés que NOBODY utilise actuellement avec à peu près tout ce qui existe aujourd’hui. À moins de créer quelque chose comme glibc, libstdc ++ ou GCC sur une version ancienne de Solaris, AIX ou similaire, les tests sont une perte de temps et sont une source de nombreuses ruptures potentielles, comme mentionné ci-dessus.
  • Faire une configuration Autotools pour générer du code utilisable pour un système Windows est une expérience assez pénible. (Bien que je ne sois pas très utile pour Windows, cela pose un grave problème si vous développez du code soi-disant multiplateforme.)
  • Quand ça casse, tu vas passer des heures à courir après ta queue en essayant de régler les choses que quiconque a écrit le script a eu du mal à régler ta construction (en fait, c’est ce que j’essaie de faire (ou plutôt, Rayer les Autotools complètement – je doute qu’il y ait assez de temps dans le rest de ce mois pour sortinger le désordre …) pour le travail maintenant que je tape ceci: Apache Thrift a un de ces systèmes de construction BROKEN qui ne se croise pas -comstackr.)
  • 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 leur fournisseur de dissortingbution. Les utilisateurs “normaux” ne sont pas des développeurs et n’attrapent pas les archives dans de nombreux cas. C’est du snobisme de la part de tous pour présumer que ce sera le cas là-bas. Les utilisateurs typiques pour les archives de tar sont des développeurs qui font des choses, alors ils vont être critiqués avec la brèche si elle existe.

Ca marche … la plupart du temps … c’est tout ce qu’on peut dire sur Autotools. C’est un système qui résout plusieurs problèmes qui ne concernent que le projet GNU … pour leur code de base, la chaîne d’outils. (Edit (24/05/2014): il convient de noter que ce type de préoccupation est potentiellement une mauvaise chose à se soucier de – Heartbleed partiellement découlant de cette pensée et avec des systèmes corrects et modernes, vous n’avez vraiment pas de travail Gérer une grande partie de ce que Autotools corrige. GNU a probablement besoin de supprimer le 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 n’avez pas. Ne vous attendez pas à travailler n’importe où, sauf Linux ou là où la chaîne d’outils GNU fonctionne correctement. L’affirmation selon laquelle elle “s’intègre bien avec Linux” est une déclaration assez audacieuse et tout à fait incorrecte . Il s’intègre assez bien à la suite d’outils GNU et résout les problèmes liés à ses objectives.

Cela ne veut pas dire qu’il n’y a pas de problèmes avec les autres options abordées dans le sujet ici.

SCons est plus un remplacement pour Make / GMake / etc. et a l’air bien sympa, tout compte fait Cependant …

  • Il s’agit toujours d’un outil uniquement POSIX. Vous pourriez probablement obtenir plus facilement MinGW pour créer des trucs Windows avec Autotools, mais il est toujours plus adapté à la réalisation de POSIX et vous devrez installer Python et SCons pour l’utiliser.
  • Il y a des problèmes de compilation croisée, sauf si vous utilisez quelque chose comme Scratchbox2.
  • Certes plus lent et moins stable que CMake de leur propre comparaison. Ils arrivent avec des points négatifs (le côté POSIX a besoin de make / gmake à construire …) pour CMake par rapport aux SCons. (En passant, si vous avez besoin de tant d’extensibilité que 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 avez l’habitude de créer, utiliser SCONS ou Autotools.
  • Vous devrez installer CMake sur le système que vous créez pour.
  • Vous aurez besoin d’un compilateur C ++ solide si vous ne disposez pas de fichiers binarys pré-construits.

En vérité, vos objectives devraient dicter ce que vous choisissez ici.

  • Avez-vous besoin de traiter un grand nombre de chaînes d’outils cassées pour produire un fichier binary fonctionnel? Si oui, vous voudrez peut-être considérer Autotools, étant conscient des inconvénients mentionnés ci-dessus. CMake peut faire face à beaucoup de problèmes, mais cela le préoccupe moins qu’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 tel est le cas, Autotools devrait être littéralement hors de fonctionnement. Si oui, SCons peut / peut 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, choses comme Google Protobufs, Apache Thrift, etc. DEVRAIENT s’en soucier …)? Si tel est le cas, Autotools peut fonctionner 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. Les SCons sont quasiment inexistants pour le moment, à moins que vous n’utilisiez Scratchbox2 – il n’y a pas vraiment de contrôle sur la compilation croisée et vous devrez utiliser cette extensibilité et la maintenir de la même manière que vous allez avec Automake. Si c’est le cas, vous voudrez peut-être envisager CMake car il prend en charge la compilation croisée sans autant de soucis de fuite du bac à sable et fonctionnera avec / sans quelque chose comme Scratchbox2 et s’intègrera bien avec des choses comme OpenEmbedded.

Il y a une raison pour laquelle beaucoup de projets abandonnent qmake, Autotools, etc. et passent à CMake. Jusqu’à présent, je peux m’attendre à ce qu’un projet basé sur CMake soit placé dans une situation de compilation croisée ou sur une configuration VisualStudio ou ne nécessite qu’un petit nettoyage car le projet ne prend pas en compte les composants Windows uniquement ou OSX uniquement. à la base de code. Je ne peux pas vraiment m’attendre à ce qu’un projet basé sur SCons – et je m’attends vraiment à ce qu’un tiers ou plus des projets Autotools aient quelque chose de faux qui les empêche de construire sur n’importe quel contexte sauf celui qui en crée un ou celui de Scratchbox2.

Une distinction importante doit être faite entre qui utilise 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 archive de dissortingbution 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 créée à l’aide des outils automatiques, vous n’utilisez pas les outils automatiques . En revanche, si vous installez un logiciel utilisant Cmake, vous utilisez Cmake et vous devez l’avoir installé pour créer le logiciel.

La grande majorité des utilisateurs n’ont pas besoin d’avoir les autotools installés sur leur boîte. Historiquement, beaucoup de confusion a été causée par le fait que de nombreux développeurs dissortingbuent des archives tar malformées qui obligent l’utilisateur à exécuter autoconf pour régénérer le script configure, ce qui constitue une erreur de packaging. Plus de confusion a été causée par le fait que la plupart des principales dissortingbutions linux installent plusieurs versions des autotools, alors qu’elles ne devraient en installer aucune par défaut. Les développeurs qui tentent d’utiliser un système de contrôle de version (par exemple, cvs, git, svn) sont encore plus confus pour dissortingbuer leurs logiciels plutôt que de créer des archives tar.

Il ne s’agit pas de 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 avec la construction d’une dissortingbution Linux.

Avec cmake par exemple, c’est toujours “c’etait -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, c’est juste ./configure CFLAGS = “- O0 -ggdb3” et vous l’avez.

En 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 une macro RPM qui grossit grossièrement (admin peut le définir) la puissance du système. Les gens mettent des choses comme -JNCPUS dans leur environnement. Avec les scons qui ne fonctionnent pas, les paquets utilisant des scons ne peuvent être que des dissortingbutions intégrées sériées.

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 paquet qui respecte toutes les normes GNU, Autotools est un excellent outil pour le travail. Si vous ne le faites pas, alors vous devriez utiliser Scons ou CMake. (Par exemple, voir cette question .) Ce malentendu commun est la principale source de frustration avec Autotools.

Alors que du sharepoint vue des développeurs, cmake est actuellement le plus facile à utiliser, du sharepoint vue de l’utilisateur, les autotools ont un gros avantage

Les autotools génèrent un seul script de configuration de fichier et tous les fichiers pour le générer sont livrés avec la dissortingbution. Il est facile à comprendre et à corriger avec l’aide de grep / sed / awk / vi. Comparez cela à Cmake où beaucoup de fichiers se trouvent dans / usr / share / cmak * / Modules, ce qui ne peut être corrigé par l’utilisateur à moins qu’il n’ait access à l’administrateur.

Donc, si quelque chose ne fonctionne pas tout à fait, il peut généralement être “corrigé” en utilisant des outils Unix standard (grep / sed / awk / vi etc.) de manière simplifiée sans avoir à comprendre le système de compilation.

Avez-vous déjà parcouru votre répertoire de compilation cmake pour découvrir ce qui ne va pas? Comparé au script de shell simple qui peut être lu de haut en bas, il est très 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 nécessite non seulement la connaissance du langage CMake, mais également des privilèges de superutilisateur.