Pourquoi utiliser des outils de construction comme les Autotools quand il nous suffit d'écrire notre propre makefiles?

Vous parlez de deux choses distinctes mais étroitement liés choses ici:

• Autotools
• GNU normes de codage

Dans les Autotools, vous avez plusieurs projets:

• Autoconf
• Automake
• Libtool

Regardons chacun d'eux individuellement.

Autoconf

Autoconf facilement scanne un arbre existant à trouver ses dépendances et de créer un script de configuration qui sera exécuté sous presque n'importe quel type de coque. Le script de configuration permet à l'utilisateur de contrôler le comportement de construction (c'est à dire --with-foo, --without-foo, --prefix, --sysconfdir, etc..) ainsi que de faire des vérifications pour s'assurer que le système permet de compiler le programme.

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

Personnellement, je utiliser Autoconf sur de nombreux projets. Il prend habituellement les gens le temps de s'habituer à m4. Cependant, il permet de gagner du temps.

Vous pouvez avoir des makefiles hériter de certaines valeurs qui configure trouve sans l'aide d'automake.

Automake

En fournissant un modèle qui décrit ce que les programmes vont être construits et les objets doivent être liées à leur édification, les Makefiles qui respectent les standards de programmation GNU peut être automatiquement créé. Cela inclut la gestion des dépendances et tous les GNU cibles.

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

Libtool

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

Il y a d'autres options, voir StackOverflow question Des solutions de rechange à Autoconf et Autotools?.

L'automatisation de la génération & GNU normes de codage

En bref, vous devriez vraiment utiliser certains type de construction portables de configuration du système si vous relâchez votre code pour les masses. Ce que vous utilisez est à vous. Logiciel GNU est connu pour générer et exécuter sur presque rien. Toutefois, vous ne pourriez pas besoin d'adhérer à une telle (et parfois très pédant) des normes.

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

Modifier

N'ont pas peur de m4 🙂 Il y a toujours la Autoconf macro archive. De nombreux exemples, ou de tomber dans les contrôles. Écrivez votre propre ou utiliser ce qui est testé. Autoconf est trop souvent confondue avec Automake. Ils sont deux choses distinctes.

Les réponses déjà fournies ici sont bons, mais je vous recommande fortement de ne pas prendre les conseils pour écrire votre propre makefile si vous avez quelque chose qui ressemble à un standard C/C++ du projet. Nous avons besoin de la autotools au lieu de manuscrits makefiles parce que conforme à la norme makefile généré par automake offre un grand nombre de cibles utiles sous des noms bien connus, et en fournissant tous ces objectifs à la main est fastidieux et source d'erreurs.

Tout d'abord, l'écriture d'un Makefile à la main semble une bonne idée au premier abord, mais la plupart des gens ne sera pas la peine d'écrire plus de règles pour tous, installer et peut-être propre. automake génère dist, distcheck, propre, distclean, de désinstallation et de toutes ces aides. Ces objectifs sont une grande bénédiction pour le sysadmin qui finira par installer votre logiciel.

Deuxièmement, en offrant à tous ces objectifs dans un portable et flexible est tout à fait enclin à l'erreur. J'ai fait beaucoup de cross-compilation pour Windows cibles récemment, et les autotools effectuée tout simplement génial. Contrairement à la plupart des écrits à la main les fichiers, qui ont été surtout une douleur dans le cul pour compiler. Rappelez-vous, il est possible de créer un bon Makefile à la main. Mais ne vous surestimez pas, il faut beaucoup d'expérience et de connaissances sur un tas de différents systèmes, et automake crée une grande Makefiles pour vous, tout droit sorti de la boîte.

Edit: Et ne pas être tenté d'utiliser les "solutions de rechange". CMake et les amis sont une horreur pour le déployeur parce qu'ils ne sont pas compatible pour configurer et amis. Chaque demi-façon compétente sysadmin ou un développeur peut faire de grandes choses comme la cross-compilation ou des choses simples comme la configuration d'un préfixe de sa tête ou avec un simple --help avec un script de configuration. Mais vous êtes condamnés à passer une heure ou trois quand vous avez à faire de telles choses avec BJam. Ne m'obtenez pas le mal, BJam est probablement un excellent système sous le capot, mais c'est une douleur dans le cul à utiliser, car il n'y a presque pas de projets d'aide et de très peu et le caractère incomplet de la documentation. autoconf et automake ont une énorme avance ici en termes de connaissances établies.

Donc, même si je suis un peu en retard avec ces conseils pour cette question: Faites-vous une faveur et utiliser les autotools et automake. La syntaxe pourrait être un peu étrange, mais ils font un meilleur travail que 99% des développeurs de le faire sur leurs propres.

Autotools sont nécessaires parce que les Makefiles sont pas garantis pour fonctionner de la même à travers différentes plates-formes. Si vous écrivez un fichier Makefile, et il fonctionne sur votre machine, il ya une bonne chance qu'il ne soit pas sur le mien.

Autotools est une catastrophe.

Générés ./configure script vérifie pour des fonctionnalités qui n'ont pas été présents sur tout système Unix pour les 20 dernières années. Pour ce faire, il dépense une énorme quantité de temps.

De course ./configure prend pour des âges. Bien que moderne, serveur Cpu peut 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 PROCESSEUR ira jusqu'en fonction du temps. Donc, le temps ./configure faut de la volonté de rester à peu près constante alors que parallèlement, les temps de réalisation de réduire 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 peut même augmenter en raison de l'augmentation de la complexité du logiciel profitant de l'amélioration du matériel.

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

Et sur make -j${CPUCOUNT}. L'généré système de construction est récursive. Version récursive a pour une longue quantité de temps été considéré comme nocif.

Puis lorsque vous installez le logiciel qui a été compilé, vous trouverez que cela ne fonctionne pas. (Vous voulez une preuve? Clone protobuf référentiel à partir de Github, découvrez commettre 9f80df026933901883da1d556b38292e14836612, l'installer sur une Debian ou Ubuntu, système, et hop: protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory -- puisque c'est dans /usr/local/lib et pas /usr/lib; solution de contournement consiste à faire export LD_RUN_PATH=/usr/local/lib avant de taper make).

La théorie est que, 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? Tous les non-Linux système pour construire des paquets à partir des sources a de nombreux fichiers de patch dans leur référentiel pour contourner les autotools bugs. Il suffit de prendre un coup d'oeil à par exemple FreeBSD /usr/ports: c'est plein de patchs. Ainsi, il aurait été aussi facile de créer un petit patch, pour un non-autotools système de construction sur une base par projet de créer un petit patch pour un autotools système de construction sur une base par projet. Ou peut-être même plus facile, en tant que norme make est beaucoup plus facile à utiliser que les autotools.

Le fait est, si vous créez votre propre système de construction basé sur le standard make (et de le rendre inclusif et non récursive, en suivant les recommandations de la "version Récursive considéré comme nocif" papier), les choses sont dans une bien meilleure manière. Aussi, votre temps de construction descend par un ordre de grandeur, peut-être même deux ordres de grandeur si votre projet est très petit projet de 10-100 C les fichiers de langue et vous avez des dizaines de cœurs par PROCESSEUR et de plusieurs Processeurs. Il est également beaucoup plus facile à l'interface personnalisée automatique des outils de génération de code avec un système de construction basé sur le standard make au lieu de traiter avec la m4 mess des autotools. Avec la norme make, vous pouvez au moins tapez une commande shell dans le Makefile.

Donc, pour répondre à votre question: pourquoi utiliser des autotools? Réponse: il n'y a aucune raison de le faire. Autotools est obsolète depuis quand les Unix commerciaux est devenu obsolète. Et l'avènement des Processeurs multi-cœur a fait des autotools encore plus obsolète. Pourquoi les programmeurs n'ont pas réalisé que pourtant, c'est un mystère. Je vais joyeusement utilisation standard make 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 le langage C pour l'en-tête de l'inclusion, mais la quantité de travail est sauvé par ne pas avoir à se battre avec les autotools.