60 votes

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

Récemment, j'ai changé mon environnement de développement de Windows à Linux. Jusqu'à présent, je n'ai utilisé que Visual Studio pour le développement C++, si bien que de nombreux concepts, tels que faire y Autotools sont nouveaux pour moi. J'ai lu la documentation de GNU makefile et j'en ai presque une idée. Mais je suis un peu confus au sujet d'Autotools.

Pour autant que je sache, les makefiles sont utilisés pour faciliter le processus de construction.

  1. Pourquoi avons-nous besoin d'outils comme Autotools juste pour créer les makefiles ? Comme tout le monde sait comment créer un makefile, je ne comprends pas la véritable utilité d'Autotools.
  2. Quelle est la norme ? Devons-nous utiliser des outils de ce type ou des makefiles écrits à la main suffisent-ils ?

88voto

Tim Post Points 21270

Vous parlez ici de deux choses distinctes mais intimement liées :

  • Autotools
  • Normes de codage GNU

Dans Autotools, vous disposez de plusieurs projets :

  • Autoconf
  • Automake
  • Libtool

Examinons-les individuellement.

Autoconf

Autoconf analyse facilement une arborescence existante pour trouver ses dépendances et créer un configure script qui s'exécutera sous presque tout type de shell. Le configure script permet à l'utilisateur de contrôler le comportement de construction (c'est-à-dire. --with-foo , --without-foo , --prefix , --sysconfdir ) ainsi que des vérifications pour s'assurer que le système peut compiler le programme.

Configure génère un config.h (à partir d'un modèle) que les programmes peuvent inclure 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 un certain temps pour s'habituer à l'utilisation d'Autoconf. m4 . Cependant, cela permet de gagner du temps.

Vous pouvez faire en sorte que les makefiles héritent de certaines des valeurs que configure trouve sans utiliser automake.

Automake

En fournissant un court modèle qui décrit les programmes qui seront construits et les objets qui doivent être liés pour les construire, les Makefiles qui adhèrent aux standards de codage GNU peuvent être automatiquement créés. Cela inclut la gestion des dépendances et toutes les cibles GNU requises.

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 n'importe quel système Unix-like. Parfois, je l'utilise ; d'autres fois (surtout pour la construction d'objets de liens statiques), je le fais à la main.

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

Automatisation de la construction et normes de codage GNU

En bref, vous devriez vraiment utiliser un peu de une sorte de système de configuration de construction portable si vous diffusez votre code aux masses. Ce que vous utilisez dépend de vous. Les logiciels GNU sont connus pour se construire et fonctionner sur presque tout. Cependant, il se peut que vous n'ayez pas besoin d'adhérer à de telles normes (et parfois extrêmement pédantes).

Je vous recommande d'essayer Autoconf si vous écrivez des logiciels pour les systèmes POSIX. Ce n'est pas parce qu'Autotools produit une partie d'un environnement de construction compatible avec les standards GNU que vous devez suivre ces standards (beaucoup ne le font pas !) :) Il y a beaucoup d'autres options, aussi.

Modifier

N'ayez pas peur m4 :) Il y a toujours la Archive des macros Autoconf . De nombreux exemples, ou des vérifications à la volée. Ecrivez vos propres exemples ou utilisez ceux qui ont été testés. Autoconf est bien trop souvent confondu avec Automake . Ce sont deux choses distinctes.

1 votes

@janneb libtool est ce qu'il est parce que construire des librairies partagées sur certains systèmes est VRAIMENT pervers, et sans libtool il devient presque impossible de supporter ces systèmes puisqu'ils requièrent beaucoup de sauts de cerceaux supplémentaires que Linux ne fait pas... et Windows peut vous demander de faire quelques sauts de cerceaux supplémentaires pour obtenir des librairies partagées qui fonctionnent, surtout si vous vous souciez des gens qui utilisent VC++ plutôt que mingw. Donc oui, libtool existe pour une bonne raison. L'autre chose qu'il gère est des choses comme le code indépendant de la position, et partagé vs statique (parfois vous devez construire avec différentes options).

33voto

Pankrat Points 2145

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

Autoconf est le système de configuration qui crée le script configuré sur la base de contrôles de fonctionnalités qui sont censés fonctionner sur toutes sortes de plateformes. Une grande partie de la connaissance du système est entrée dans son m4 de la base de données macro pendant les 15 années de son existence. D'une part, je pense que ce dernier point est la raison principale pour laquelle Autotools n'a pas encore été remplacé par autre chose. D'autre part, Autoconf était bien plus important lorsque les plateformes cibles étaient plus hétérogènes et Linux, AIX , HP-UX , SunOS ..., et une grande variété d'architectures de processeurs différentes ont dû être supportées. Je ne vois pas vraiment son intérêt si vous ne voulez supporter que les distributions Linux récentes et les processeurs compatibles avec Intel.

Automake est une couche d'abstraction pour GNU Make et agit comme un générateur de Makefile à partir de modèles plus simples. Un certain nombre de projets se sont finalement débarrassés de l'abstraction Automake et sont revenus à l'écriture manuelle des Makefiles parce que vous perdez le contrôle de vos Makefiles et que vous n'avez peut-être pas besoin de toutes les cibles de compilation en boîte qui obscurcissent votre Makefile.

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

CMake La réalisation la plus notable de l'entreprise est le remplacement d'AutoTools dans le système de gestion de l'information. KDE . C'est probablement ce qui se rapproche le plus de ce que l'on peut obtenir si l'on veut avoir une fonctionnalité de type Autoconf sans les idiosyncrasies de m4. Il apporte le support de Windows et a prouvé qu'il était applicable dans de grands projets. Mon problème avec CMake est qu'il est toujours un générateur de Makefile (au moins sur Linux) avec tous ses problèmes immanents (par exemple le débogage de Makefile, les signatures d'horodatage, l'ordre implicite des dépendances).

SCons est un remplacement de Make écrit en Python. Il utilise des scripts Python comme fichiers de contrôle de construction permettant des techniques très sophistiquées. Malheureusement, son système de configuration n'est pas à la hauteur d'Autoconf. SCons est souvent utilisé pour le développement interne lorsque l'adaptation aux exigences spécifiques est plus importante que le respect des conventions.

Si vous voulez vraiment vous en tenir à Autotools, je vous conseille vivement de lire le document suivant La fabrication récursive est considérée comme nuisible et écrire votre propre fichier GNU Makefile configuré par Autoconf.

0 votes

Autoconf a beaucoup plus d'usages que les vérifications triviales, par exemple, trouver rapidement si la structure foo dans foo/foo.h a un membre nommé 'bar', la version de libfoo, etc. De plus, les options de compilation sont très utiles pour la création de paquets .deb / .rpm. Mais, oui, c'est une question de préférence je suppose.

0 votes

@tinkertim : Vous avez raison, mais cela ne distingue pas Autoconf des autres systèmes de construction. Les exemples que vous avez donnés peuvent être facilement mis en œuvre dans SConf (le sous-système de configuration de SCons). Cependant, tous les contrôles de sanité et les choses que je ne penserais même pas à vérifier sont gratuits dans Autoconf.

23voto

thiton Points 21303

Les réponses déjà fournies ici sont bonnes, mais je recommande fortement de ne pas suivre le conseil d'écrire votre propre makefile si vous avez quelque chose qui ressemble à un projet C/C++ standard. Nous avons besoin des autotools au lieu de makefiles écrits à la main parce qu'un makefile conforme aux standards généré par automake offre beaucoup de cibles utiles sous des noms bien connus, et fournir toutes ces cibles à la main est fastidieux et source d'erreurs.

Tout d'abord, écrire un Makefile à la main semble une bonne idée au début, mais la plupart des gens ne prendront pas la peine d'écrire plus que les règles pour all, install et peut-être clean. automake génère dist, distcheck, clean, distclean, uninstall et toutes ces petites aides. Ces cibles supplémentaires sont une grande aubaine pour l'administrateur système qui installera éventuellement votre logiciel.

Deuxièmement, fournir toutes ces cibles d'une manière portable et flexible est assez sujet aux erreurs. J'ai fait beaucoup de compilations croisées avec des cibles Windows récemment, et les outils automatiques se sont très bien comportés. Contrairement à la plupart des fichiers écrits à la main, dont la compilation était une véritable plaie. Remarquez, c'est es possible de créer un bon Makefile à la main. Mais ne vous surestimez pas, cela demande beaucoup d'expérience et de connaissances sur un tas de systèmes différents, et automake crée de bons Makefiles pour vous dès la sortie de la boîte.

Edit : Et Ne soyez pas tenté d'utiliser les "alternatives". . CMake et ses amis sont une horreur pour le déployeur car ils ne sont pas compatibles avec l'interface de configure et ses amis. Tout administrateur système ou développeur à moitié compétent peut faire de grandes choses comme la compilation croisée ou des choses simples comme définir un préfixe de sa tête ou avec un simple --help avec un configure script. Mais vous êtes damné pour passer une heure ou trois quand vous devez faire de telles choses avec BJam. Ne vous méprenez pas, BJam est probablement un super système sous le capot, mais c'est une douleur dans le cul à utiliser parce qu'il n'y a presque pas de projets qui l'utilisent et une documentation très faible et incomplète. autoconf et automake ont une énorme avance ici en termes de connaissances établies.

Donc, 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 peut être un peu étrange, mais ils font un bien meilleur travail que 99% des développeurs ne le font par eux-mêmes.

11voto

Dan Hook Points 1765

Pour les petits projets ou même pour les grands projets qui ne fonctionnent que sur une seule plateforme, les makefiles manuscrits sont la solution.

Là où les autotools brillent vraiment, c'est lorsque vous compilez pour différentes plateformes qui requièrent différentes options. Autotools est souvent le cerveau derrière la typique

./configure

faire

faire installer

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

Cela dit, je trouve que les outils automatiques sont pénibles et j'ai cherché un meilleur système. Dernièrement, j'ai utilisé bjam, mais cela a aussi ses inconvénients. Bonne chance pour trouver ce qui fonctionne pour vous.

7voto

Zifre Points 14109

Les outils automatiques sont nécessaires car il n'est pas garanti que les Makefiles fonctionnent de la même manière sur les différentes plateformes. Si vous écrivez un Makefile à la main, et qu'il fonctionne sur votre machine, il y a de fortes chances qu'il ne fonctionne pas sur la mienne.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X