Pourquoi utiliser des outils comme construire Autotools quand nous pouvons simplement écrire nos propres makefiles?

Question

Récemment, je suis passé mon environnement de développement de Windows à Linux. Jusqu'à présent, je ne l'ai utilisé Visual Studio pour le développement de C, tant de concepts, comme faire et Autotools , sont nouveaux pour moi. J'ai lu la documentation makefile GNU et a obtenu presque une idée à ce sujet. Mais je suis un peu confus au sujet Autotools.

Pour autant que je sache, makefiles sont utilisés pour rendre le processus de construction plus facile.

1. Pourquoi avons-nous besoin d'outils comme Autotools juste pour créer les makefiles? Comme tous sait comment créer un makefile, je ne reçois pas l'utilisation réelle de Autotools.
2. Quelle est la norme? Avons-nous besoin d'utiliser des outils comme celui-ci ou serait makefiles simplement écrits à la main faire?

Answer 1

Vous parlez de deux choses distinctes mais entremêlées ici:

• Autotools
• normes de codage GNU

Dans Autotools, vous avez plusieurs projets:

• Autoconf
• Automake
• Libtool

Regardons chacun individuellement.

Autoconf

Autoconf scanne facilement un arbre existant pour trouver ses dépendances et créer un script de configuration qui fonctionnera sous presque toute sorte de coquille. Le script de configuration permet à l'utilisateur de contrôler le comportement de construction (à savoir --with-foo, --without-foo, --prefix, --sysconfdir, etc ..) ainsi que de faire des vérifications pour veiller à ce que le système peut compiler le programme.

Configurer génère un fichier config.h (à partir d'un modèle) qui peuvent inclure des programmes pour contourner les problèmes de portabilité. Par exemple, si HAVE_LIBPTHREAD n'est pas défini, utilisez les fourches à la place.

J'utilise personnellement Autoconf sur de nombreux projets. Il faut généralement des gens un peu de temps pour s'y habituer m4 . Cependant, il économise du temps.

Vous pouvez avoir makefiles héritent certaines des valeurs qui configurent trouve sans utiliser automake.

Automake

En fournissant un court modèle qui décrit les programmes seront construits et quels objets doivent être liés à les construire, Makefile qui adhèrent aux normes de codage GNU peut être automatiquement créé. Cela inclut la gestion des dépendances et toutes les cibles GNU nécessaires.

Certaines personnes trouvent cela plus facile. Je préfère écrire mes propres makefile.

Libtool

Libtool est un outil très cool pour simplifier la construction et l'installation des bibliothèques partagées sur tous les systèmes Unix. Parfois, je l'utilise; d'autres fois (surtout quand la simple construction d'objets de lien statique) je le fais à la main.

Il y a d'autres options, voir la question StackOverflow Alternatives à Autoconf et Autotools? .

Construire des normes d'automatisation et de codage GNU

En bref, vous devriez vraiment utiliser certains type de système de configuration de construction portable si vous fermiez votre code pour les masses. Qu'est-ce que vous utilisez est à vous. logiciel GNU est connu pour construire et exécuter sur presque tout. Cependant, vous ne pourriez pas besoin d'adhérer à des normes telles (et parfois très pédant).

Si quoi que ce soit, je vous recommande de donner Autoconf essayer si vous êtes un logiciel d'écriture pour les systèmes POSIX. Tout simplement parce que Autotools produire une partie d'un environnement de construction qui est compatible avec les normes GNU ne signifie pas que vous devez suivre ces normes (beaucoup ne le font pas!) :) Il y a beaucoup d'autres options aussi.

Modifier

Ne craignez pas m4 :) Il y a toujours Autoconf archives macro . Beaucoup d'exemples, ou baisse des chèques. Écrivez votre propre ou utiliser ce qui est testé. Autoconf est beaucoup trop souvent confondu avec Automake . Ce sont deux choses distinctes.

Answer 2

Tout d'abord, les Autotools ne sont pas un système de construction opaque mais un outil chaîne à couplage lâche, comme tinkertim déjà souligné. Permettez-moi d'ajouter quelques réflexions sur Autoconf et Automake:

Autoconf est le système de configuration qui crée le script de configuration en fonction des contrôles de fonctionnalités qui sont censés travailler sur toutes sortes de plates-formes. Beaucoup de connaissances du système est entré dans son m4 base de données macro au cours des 15 années de son existence. D'une part, je pense que ce dernier est la principale raison Autotools n'ont pas été remplacé par quelque chose d'autre encore. D'autre part, Autoconf utilisé pour être beaucoup plus important lorsque les plates-formes cibles étaient plus hétérogènes et Linux, AIX , HP-UX , SunOS , ..., et une grande variété de l'architecture du processeur devait être pris en charge. Je ne vois pas vraiment son point si vous voulez seulement pour soutenir les distributions Linux récentes et les processeurs compatibles Intel.

Automake est une couche d'abstraction pour GNU Make et agit comme un générateur Makefile à partir de modèles plus simples. Un certain nombre de projets a fini par se débarrasser de l'abstraction Automake et revient à l'écriture Makefile manuellement parce que vous perdez le contrôle de vos Makefile et vous ne pouvez pas besoin de tous les objectifs de construction en conserve qui Occultation votre Makefile.

à alternatives (et je suggère fortement une alternative à Autotools en fonction de vos besoins):

CMake réalisation la plus notable de remplace autotools dans KDE . Il est probablement le plus proche, vous pouvez obtenir si vous voulez avoir des fonctionnalités Autoconf comme sans m4 idiosyncrasies. Il apporte le support de Windows à la table et a prouvé être applicable dans de grands projets. Mon boeuf avec CMake est qu'il est encore un générateur de Makefile (au moins sur Linux) avec tous ses problèmes immanents (par exemple Makefile le débogage, les signatures d'horodatage, de l'ordre de dépendance implicite).

SCons est un remplacement de Make écrit en Python. Il utilise des scripts Python sous forme de fichiers de contrôle de construction permettant des techniques très sophistiquées. Malheureusement, son système de configuration est à égalité avec Autoconf. SCons est souvent utilisé pour le développement en interne lorsque l'adaptation aux besoins spécifiques est plus important que les conventions suivantes.

Si vous voulez vraiment rester avec Autotools, je vous suggère fortement de lire récursive Faire Considered Harmful et écrivez votre propre Makefile GNU configuré via Autoconf.

Answer 3

Les réponses déjà fournies ici sont bons, mais je recommande vivement de ne pas prendre les conseils d'écrire votre propre makefile si vous avez quelque chose qui ressemble à une norme C / C ++ projet. Nous avons besoin des autotools au lieu de makefiles écrits à la main, car un makefile standard conforme généré par automake offre beaucoup de cibles utiles sous des noms bien connus, et en fournissant tous ces objectifs à la main est fastidieuse et sujette à erreur.

Tout d'abord, l'écriture d'un Makefile à la main semble une bonne idée au début, mais la plupart des gens ne dérangera pas d'écrire plus que les règles pour tous, installer et peut-être propre. automake génère dist, distcheck, propre, distclean, désinstallez et toutes ces petites aides. Ces objectifs supplémentaires sont une grande aubaine pour le sysadmin qui finira par installer le logiciel.

En second lieu, fournir tous ces objectifs de manière portable et flexible est tout à fait sujette aux erreurs. Je l'ai fait beaucoup de compilation croisée à des cibles de Windows récemment, et les autotools effectué tout simplement génial. Contrairement à la plupart des fichiers écrits à la main, qui étaient la plupart du temps une douleur dans le cul à compiler. Rappelez-vous, il est possible de créer une bonne Makefile à la main. Mais ne vous surestimez pas, il faut beaucoup d'expérience et de connaissances sur un tas de systèmes différents, et automake crée de grandes Makefile pour vous dès la sortie de la boîte.

Edit: Et ne soyez pas tentés d'utiliser les "alternatives" . CMake et les amis sont une horreur à l'deployer parce qu'ils ne sont pas compatibles avec interface pour configurer et amis. Chaque sysadmin compétent à mi-chemin ou un développeur peut faire de grandes choses comme la compilation croix ou des choses simples comme la fixation d'un préfixe de sa tête ou avec un simple --help avec un script de configuration. Mais vous êtes damné de passer une heure ou trois quand vous devez faire ces choses avec bjam. Ne vous méprenez pas, bjam est probablement un grand système sous le capot, mais il est une douleur dans le cul à utiliser, car il n'y a presque pas de projets à l'utiliser et la documentation très peu et incomplètes. autoconf et automake ont une avance énorme ici en termes de connaissances établies.

Alors, même si je suis un peu en retard avec ce conseil pour cette question: Faites-vous une faveur et utiliser les autotools et automake. La syntaxe est peut-être un peu étrange, mais ils font un bien meilleur travail que 99% des développeurs font de leur propre chef.

Answer 4

Pour les petits projets ou même pour les grands projets qui ne fonctionnent que sur une plate-forme, makefiles sont écrits à la main la voie à suivre.

Où autotools vraiment briller est quand vous compilez pour différentes plates-formes qui nécessitent différentes options. Autotools est souvent le cerveau derrière typique

./ configure

make

make install

compilation et étapes d'installation pour les bibliothèques Linux et des applications.

Cela dit, je trouve autotools être une douleur et que je cherchais un meilleur système. Dernièrement, je me sers bjam, mais qui a aussi ses inconvénients. Bonne chance pour trouver ce qui fonctionne pour vous.

Answer 5

Autotools sont nécessaires parce que Makefile ne sont pas garantis de travailler même sur différentes plateformes. Si vous handwrite un Makefile, et il fonctionne sur votre machine, il y a une bonne chance que ce ne sera pas sur le mien.

Answer 6

Savez-vous ce que unix vos utilisateurs utiliseront-ils? Ou encore quelle distribution de Linux? Savez-vous où ils veulent un logiciel installé? Savez-vous quels outils ils ont, ce que l'architecture qu'ils veulent compiler sur, le nombre de processeurs qu'ils ont, la quantité de RAM et le disque pourrait être disponible pour eux?

Le monde * nix est un paysage multi-plateforme, et votre construire et installer les outils doivent composer avec cela.

---

Rappelez-vous, l'auto * outils La date d'une époque antérieure, et sont nombreuses plaintes valides à leur sujet là, mais plusieurs projets pour les remplacer par des alternatives plus modernes éprouvent des difficultés à développer beaucoup d'élan.

Beaucoup de choses sont comme ça dans le monde * nix.

Answer 7

Autotools est une catastrophe.

Les contrôles de script pour ./configure générés fonctionnalités qui n'ont pas été présents sur tous les systèmes Unix pour durer 20 ans ou plus. Pour ce faire, il passe une énorme quantité de temps.

L'exécution ./configure prend pour les âges. Bien que les processeurs de serveurs modernes peuvent avoir même des dizaines de cœurs, et il peut y avoir plusieurs processeurs par serveur, le ./configure est mono-thread. Nous avons encore assez d'années de la loi de Moore à gauche que le nombre de cœurs de CPU passe ainsi comme fonction du temps. Ainsi, le temps prend ./configure reste à peu près constante alors que les temps de construction parallèles réduisent d'un facteur 2 tous les 2 ans en raison de la loi de Moore. Ou en fait, je dirais que le temps ./configure prend pourrait même augmenter en raison de la complexité croissante des logiciels tirant parti du matériel amélioré.

Le simple fait d'ajouter un seul fichier à votre projet, vous devez lancer automake, autoconf et ./configure qui prendra les âges, et vous constaterez probablement que depuis quelques fichiers importants ont changé, tout sera recompilée. ajouter Alors qu'un seul fichier, et make -j${CPUCOUNT} recompile tout.

Et à propos make -j${CPUCOUNT}. Le système de construction est généré un récursif. make récursif a pendant une longue période de temps été considéré comme dangereux .

Ensuite, lorsque vous installez le logiciel qui a été compilé, vous constaterez que cela ne fonctionne pas. (Vous voulez des preuves? Clone protobuf dépôt de Github, consultez commit 9f80df026933901883da1d556b38292e14836612, l'installer sur une Debian ou Ubuntu système, et voilà. protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory - car il est en /usr/local/lib et non /usr/lib, solution de contournement est de faire export LD_RUN_PATH=/usr/local/lib avant de taper make)

La théorie est qu'en utilisant les autotools, vous pouvez créer un logiciel qui peut être compilé sous Linux, FreeBSD, NetBSD, OpenBSD, DragonflyBSD et d'autres systèmes d'exploitation. Le fait? Chaque système non-Linux pour construire des paquets à partir des sources a de nombreux fichiers de patch dans leur référentiel pour travailler autotools autour de bugs. Il suffit de jeter un oeil à par exemple FreeBSD /usr/ports: il est plein de patches. Ainsi, il aurait été aussi facile de créer un petit patch pour un système de construction non-autotools sur une base par projet plutôt que de créer un petit patch pour un système de construction de autotools sur une base par projet. Ou peut-être encore plus facile, comme beaucoup make norme est plus facile à utiliser que autotools.

Le fait est, si vous créez votre propre système de construction basé sur make standard (et le rendre inclusif et non récursive, suivant les recommandations du « make récursif considérés comme nuisibles » papier), les choses fonctionnent d'une manière beaucoup mieux. En outre, votre temps de construction diminue d'un ordre de grandeur, peut-être même deux ordres de grandeur si votre projet est très petit projet de 10-100 fichiers en langage C et vous avez des dizaines de cœurs par processeur et plusieurs processeurs. Il est aussi beaucoup plus facile à l'interface des outils de génération de code automatique sur mesure avec un système de construction personnalisé basé sur make standard au lieu de traiter le mess m4 de autotools. Avec make standard, vous pouvez au moins taper une commande shell dans le Makefile.

Alors, pour répondre à votre question: pourquoi utiliser autotools? Réponse: il n'y a aucune raison de le faire. Autotools est obsolète depuis quand Unix commercial est devenu obsolète. Et l'avènement des processeurs multi-core a autotools encore plus obsolète. Pourquoi les programmeurs ne sont pas encore rendu compte que, est un mystère. Je vais heureusement utiliser make standard sur mes systèmes de construction, je vous remercie. Oui, il faut une certaine quantité de travail pour générer les fichiers de dépendance pour l'inclusion d'en-tête de langage C, mais la quantité de travail est sauvé par ne pas avoirde se battre avec autotools.

Answer 8

Je ne crois que je suis un expert pour répondre à cette question, mais quand même vous donner une analogie peu avec mon expérience.

Parce que jusqu'à une certaine mesure, il est similaire à la raison pour laquelle nous devrions écrire des codes embarqués en langage C (langage de haut niveau) plutôt que d'écrire en langage assembleur. Les deux résoud le même but, mais celui-ci est plus lenghty, fastidieux, beaucoup de temps et plus d'erreurs (à moins que vous connaissez ISA du processeur très bien). La même chose est le cas avec l'outil Automake et écrire votre propre makefile. L'écriture Makefile.am et configure.ac est assez simple que l'écriture Makefile du projet individuel.