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.
La section mentionnant Heartbleed nuit à cette diatribe frustrée. Le problème était qu'OpenSSL n'utilisait PAS un package de type configurateur pour détecter les malloc cassés mais réimplémentait les bibliothèques système et battait les développeurs de plate-forme qui produisaient des bibliothèques qui auraient détecté des défauts beaucoup plus tôt. Une des raisons de porter des programmes est qu'ils deviennent de meilleure qualité car ils dépendent moins de ces petites hypothèses que vous ne réalisez pas que vous faites
Rob11311
9
Le fait est que cela ne lui enlève rien du tout. Avec Autotools, vous vous inquiétez de compenser POUR des choses comme ça - ces réimplémentations sont une EXPANSION de cette pensée même. Le porter au niveau supérieur pour ainsi dire. Vous devriez voir cela de cette toile de fond ... à quel point cela ne le gêne pas du tout. Vous n'avez pas identifié la cause profonde de votre raisonnement, juste ce qui s'est passé. Je touche la PENSÉE exacte qui l'a amené à cela avec Shellshock et quelques autres comme ça. S'il est cassé, vous devez le réparer. Si vous ne pouvez pas, vous devriez demander pourquoi continuer.
Svartalf
5
Je ne doute pas que les outils automatiques et les scons sont nuls, mais cette réponse fait un mauvais travail en notant les inconvénients de CMake (mon système de construction préféré, uniquement en raison de l'état très, très triste des systèmes de construction). Fondamentalement, CMake est une fractale d'incohérence avec un support intégré pour les cas de bord individuels plutôt qu'une abstraction de base qui gère la plupart des choses. C'est définitivement le ruban adhésif et le fil de sauvetage de la programmation. Je suis sûr que je fais quelque chose de mal, mais il ne prend pas en charge VisualStudio à moins que vous ne trouviez un projet VS par CMakeLists.txt acceptable (je ne suis pas un utilisateur VS, mais mes Winfriends me disent que c'est mauvais).
weberc2
5
Contrairement à d'autres outils de programmation détestés , il n'y a pas suffisamment de matériel pour faire un livre appelé "CMake, les bonnes parties" (peut-être une brochure ou un article de blog), et c'est plus une fractale de mauvaise conception que PHP .
weberc2
2
@JAB Les utilisateurs de VS me disent que ce n'est pas idiomatique. En fait, CMake a été remplacé comme système de construction pour notre projet car personne ne pouvait comprendre comment produire lesdits fichiers de projet VS "idiomatiques".
weberc2
73
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.
Certes, même si vous donnez l'impression qu'il est mauvais d'utiliser un VCS pour distribuer des logiciels. Si le contenu d'une extraction ou d'un clone est le même que le contenu d'une archive tar, pourquoi recommanderiez-vous des archives tar?
d -_- b
5
@Toor, je ne comprends pas votre question. Tous les projets sur lesquels je travaille produisent une archive tar distincte de la caisse VCS. Garder les deux distincts permet une distribution fiable.
William Pursell
13
Il est vrai que beaucoup de projets demandent aux gens d'utiliser le VCS pour obtenir la dernière version, mais cela ne convient qu'aux développeurs. Malheureusement, de nombreux utilisateurs ne parviennent pas à comprendre la distinction entre l'archive tar release et le VCS. Tenter de construire à partir du VCS impose plus de dépendances. L'utilisateur peut avoir besoin de asciidocou help2manou doxygenou, surtout, de la bonne combinaison d'outils automatiques. Cela a été un énorme problème de marketing pour les outils automatiques. Les utilisateurs pensent à tort qu'ils ont besoin d'autoconf installé car ils ne comprennent pas la différence entre l'archive tar et le VCS.
William Pursell
3
Pourquoi un projet ne peut-il pas distribuer la sortie de Cmake, les fichiers de projet et les Makefiles pour les plates-formes courantes, par exemple) Win, Linux et MacOSX? Cela semble être la même situation qu'avec les outils lex / yacc, vous incluez le code C généralisé pour qu'il puisse être construit sur des plateformes sans les outils
Rob11311
3
Bien que je pense que les points mentionnés dans cette discussion sont corrects, je crois que cette discussion manque le point. L'utilisateur doit installer un tas d'autres choses et si oui ou non il a besoin d'installer cmake supplémentaire ne devrait pas être un gros problème. Je m'inquiéterais davantage des bibliothèques, de la chaîne d'outils du compilateur et des autres outils nécessaires à la construction du logiciel.
lanoxx
24
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.
+1, et le monde serait un meilleur endroit si cela était vrai. Malheureusement, ./configure CFLAGS=-O0échoue souvent avec les packages qui remplacent CFLAGS dans le makefile et nécessitent à la place que l'utilisateur s'exécute ./configure --enable-debug. (par exemple tmux).
William Pursell
2
Ce n'est pas plus déroutant que les Autotools et comme William le fait remarquer à juste titre, il est tout enfoncé avec un CFLAGS = "<foo>" mal cadré dans le makefile. C'est tout simplement un autre de ces "vieux scies". Et les exemples CMake sont faux ... encore une fois ... Vous pouvez faire le premier si vous ne spécifiez pas RELEASE ou DEBUG. ÉCHOUER.
Svartalf
17
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.
Les normes GNU peuvent être désactivées dans Automake avec AUTOMAKE_OPTIONS = -foreigndans votre Makefile.am. (Ou -foreigndans votre autogen.sh. Je pense que presque tout le monde l'utilise.)
Dietrich Epp
9
Oui, mais cela contrôle uniquement si Automake applique des règles GNU superficielles comme si un fichier README est requis. Cela ne change pas la prémisse de base de la construction d'une archive tar de style GNU avec des règles comme installchecket distclean. Si vous essayez de changer ce type de comportement tout en utilisant Autotools, vous perdez simplement votre temps.
ptomato
1
Ils (en théorie) permettent à tous les progiciels d'être construits et installés exactement de la même manière.
ptomato
En théorie, ils vous permettent de traiter les compilateurs et les systèmes d'exploitation BROKEN de manière plus appropriée que les autres outils et d'appliquer des règles superficielles comme @ptomato qui y est mise en évidence. Si vous utilisez un outil moderne (disons GCC ou clang ... par exemple) sur un système d'exploitation moderne sans rien de vraiment loufoque, par exemple Linux ou actuel * BSD, vous n'avez PAS BESOIN des "règles". En fait, ils font beaucoup, beaucoup plus de travail pour vous et ne peuvent pas vous aider, honnêtement pour la compilation croisée. Près de la moitié de toutes les utilisations de nos jours sont pour Linux embarqué et * BSD. POURQUOI allez-vous avec des choses qui ne peuvent pas vous aider là-bas?
Svartalf
Vous ne savez pas pourquoi vous avez rejeté la réponse, car vous semblez le reconnaître dans votre commentaire ...?
ptomato
9
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.
Je ne pense pas que les problèmes avec Autotools soient "facilement corrigés" par rapport à CMake ...
sleske
7
Parce que les autotools sont un système complexe (tout comme CMake). Si vous pensez que les Autotools sont "facilement corrigés" (il peut y avoir des raisons de penser cela), il serait bon à mon humble avis d'expliquer dans la réponse de quelle manière les problèmes sont plus faciles à résoudre.
sleske
5
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. 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
arved
2
Oui, c'est logique, merci. J'ai pris la liberté de l'ajouter à votre réponse. N'hésitez pas à revenir :-).
sleske
1
Vous pouvez toujours utiliser votre propre version locale de cmake; il n'y a aucune raison d'utiliser ce qui est installé au niveau du système. Pour quiconque fait un travail multiplateforme, c'est tout à fait normal; c'est certainement la façon dont j'utilise cmake la plupart du temps.
Réponses:
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:
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 ...
Les exemples donnés pour CMake dans ce fil sont un peu faux.
Toutefois...
En vérité, vos objectifs doivent dicter ce que vous choisissez ici.
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.
la source
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.
la source
asciidocouhelp2manoudoxygenou, surtout, de la bonne combinaison d'outils automatiques. Cela a été un énorme problème de marketing pour les outils automatiques. Les utilisateurs pensent à tort qu'ils ont besoin d'autoconf installé car ils ne comprennent pas la différence entre l'archive tar et le VCS.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.la source
./configure CFLAGS=-O0échoue souvent avec les packages qui remplacent CFLAGS dans le makefile et nécessitent à la place que l'utilisateur s'exécute./configure --enable-debug. (par exempletmux).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.
la source
AUTOMAKE_OPTIONS = -foreigndans votreMakefile.am. (Ou-foreigndans votreautogen.sh. Je pense que presque tout le monde l'utilise.)installchecketdistclean. Si vous essayez de changer ce type de comportement tout en utilisant Autotools, vous perdez simplement votre temps.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.
la source