Outils automatiques GNU - GNU Autotools

Logo GNU

Les Autotools GNU , également connus sous le nom de GNU Build System , sont une suite d' outils de programmation conçus pour aider à rendre les paquets de code source portables sur de nombreux systèmes de type Unix.

Il peut être difficile de rendre un logiciel portable: le compilateur C diffère d'un système à l'autre; certaines fonctions de bibliothèque manquent sur certains systèmes; les fichiers d'en-tête peuvent avoir des noms différents. Une façon de gérer cela est d'écrire du code conditionnel, avec des blocs de code sélectionnés au moyen de directives de préprocesseur ( #ifdef ); mais en raison de la grande variété d'environnements de construction, cette approche devient rapidement ingérable. Autotools est conçu pour résoudre ce problème de manière plus gérable.

Autotools fait partie de la chaîne d'outils GNU et est largement utilisé dans de nombreux logiciels libres et packages open source . Ses outils composants sont des logiciels libres , sous licence publique générale GNU avec des exceptions de licence spéciales permettant son utilisation avec des logiciels propriétaires .

Le système de construction GNU permet de construire de nombreux programmes en utilisant un processus en deux étapes: configure suivi de make .

Composants

Organigramme d'autoconf et d'automake

Autotools se compose des programmes utilitaires GNU Autoconf , Automake et Libtool . D'autres outils connexes fréquemment utilisés à côté incluent le programme make de GNU, GNU gettext , pkg-config et la collection de compilateurs GNU , également appelée GCC.

GNU Autoconf

Autoconf génère un configure script basé sur le contenu d'un configure.ac fichier, qui caractérise un corps particulier de code source. Le configure script, lorsqu'il est exécuté, analyse l'environnement de construction et génère un config.status script subordonné qui, à son tour, convertit d'autres fichiers d'entrée et le plus souvent Makefile.in en fichiers de sortie ( Makefile ), qui sont appropriés pour cet environnement de construction. Enfin, le make programme utilise Makefile pour générer des programmes exécutables à partir du code source.

La complexité des Autotools reflète la variété des circonstances dans lesquelles un corps de code source peut être construit.

  • Si un fichier de code source est modifié, il suffit de le réexécuter make , ce qui ne recompile que la partie du corps du code source affectée par la modification.
  • Si un .in fichier a changé, il suffit de réexécuter config.status et make .
  • Si le corps du code source est copié sur un autre ordinateur, il suffit de réexécuter configure (qui s'exécute config.status ) et make . (Pour cette raison, le code source utilisant Autotools est normalement distribué sans les fichiers configure générés.)
  • Si le corps du code source est modifié plus fondamentalement, configure.ac les .in fichiers doivent être modifiés et toutes les étapes suivantes doivent également être suivies.

Pour traiter les fichiers, autoconf utilise l'implémentation GNU du système de macros m4 .

Autoconf est livré avec plusieurs programmes auxiliaires tels que autoheader , qui est utilisé pour aider à gérer les fichiers d'en-tête C ; , qui peut créer un fichier d'entrée initial pour Autoconf; et , qui peut lister les identifiants de pré-processeur C utilisés dans le programme. autoscanifnames

GNU Automake

Automake aide à créer des portables Makefile , qui sont à leur tour traités avec l' utilitaire make . Il prend son entrée comme Makefile.am , et le transforme en Makefile.in , qui est utilisé par le script de configuration pour générer la Makefile sortie du fichier . Il effectue également un suivi automatique des dépendances; chaque fois qu'un fichier source est compilé, la liste des dépendances (par exemple, les fichiers d'en-tête C) est enregistrée. Plus tard, à chaque fois que make est exécuté et qu'une dépendance semble avoir changé, les fichiers dépendants seront reconstruits.

GNU Libtool

Libtool aide à gérer la création de bibliothèques statiques et dynamiques sur divers systèmes d' exploitation de type Unix. Libtool accomplit ceci en faisant abstraction du processus de création de bibliothèque, en cachant les différences entre les différents systèmes (par exemple les systèmes Linux contre Solaris ).

Usage

Autotools aide les développeurs de logiciels à écrire des logiciels multiplateformes et à les rendre disponibles à une communauté d'utilisateurs beaucoup plus large, y compris sous sa forme de code source aux utilisateurs qui souhaitent créer eux-mêmes le logiciel. Dans la plupart des cas, les utilisateurs exécutent simplement le configure script fourni (qui n'a pas de dépendances autres que la présence d'un shell compatible Bourne ), puis un programme. Ils n'ont pas besoin d'avoir les Autotools eux-mêmes installés sur l'ordinateur. make

Il peut être utilisé à la fois pour la construction de programmes natifs sur la machine de construction et également pour la compilation croisée vers d'autres architectures.

Un logiciel de compilation croisée à exécuter sur un hôte Windows à partir d'un système de construction de type Linux ou Unix est également possible, en utilisant MinGW, mais la compilation native est souvent souhaitable sur les systèmes d'exploitation (tels que la famille de systèmes Microsoft Windows ) qui ne peuvent pas exécuter Bourne scripts shell seuls. Cela rend la construction de tels logiciels sur le système d'exploitation Windows un peu plus difficile que sur un système de type Unix qui fournit le Bourne Shell en tant que composant standard. On peut cependant installer le système Cygwin ou MSYS au-dessus de Windows pour fournir une couche de compatibilité de type Unix , permettant l' exécution des scripts de configuration . Cygwin fournit également la collection de compilateurs GNU , GNU make et d'autres logiciels qui fournissent un système de type Unix presque complet dans Windows; MSYS fournit également GNU make et d'autres outils conçus pour fonctionner avec la version MinGW de GCC.

Bien que l'on s'attende à ce que le développeur fournisse un script de configuration à l'utilisateur final, il peut parfois souhaiter régénérer le script de configuration lui-même. Un tel travail peut être nécessaire si l'utilisateur souhaite modifier le code source lui-même. Ces utilisateurs devraient avoir installé Autotools et utiliser des composants tels que son autoreconf .

L'autoconf-généré configure peut être lent car il exécute plusieurs fois des programmes tels qu'un compilateur C afin de tester si diverses bibliothèques, fichiers d'en-tête et fonctionnalités de langage sont présents. Cela affecte particulièrement Cygwin , qui, en raison de son absence d' appel système de fork natif , peut exécuter des scripts de configuration beaucoup plus lentement que Linux .

Critique

Dans sa chronique pour ACM Queue , le développeur de FreeBSD Poul-Henning Kamp a critiqué le système de construction GNU:

L'idée est que le script configure effectue environ 200 tests automatisés, afin que l'utilisateur ne soit pas obligé de configurer manuellement libtool. C'est une idée horriblement mauvaise, déjà très critiquée dans les années 1980 lorsqu'elle est apparue, car elle permet au code source de prétendre être portable derrière le vernis du script de configuration, plutôt que d'avoir réellement la qualité de portabilité pour commencer. C'est une parodie que l'idée de configuration ait survécu.

Kamp esquisse l'histoire du système de construction dans les problèmes de portabilité inhérents à la multitude de variantes Unix des années 1980 , et déplore la nécessité de tels systèmes de construction pour exister:

les 31 085 lignes de configure pour libtool vérifient toujours si <sys / stat.h> et <stdlib.h> existent, même si l'Unixen, qui en manquait, n'avait ni suffisamment de mémoire pour exécuter libtool ni des disques assez grands pour ses 16 Mo code source.

Réponses aux critiques

Bien que les critiques des Autotools préconisent fréquemment des alternatives offrant une plus grande simplicité à leurs utilisateurs, certains ont fait valoir que ce n'était pas nécessairement une bonne chose. John Calcote, auteur des Autotools, 2e édition: Guide du praticien sur GNU Autoconf, Automake et Libtool , a déclaré:

Les Autotools sont en fait plus transparents que tous les autres outils de construction. Tous ces autres outils (cmake, maven, etc.) - qui prétendent être tellement plus simples car ils isolent l'utilisateur des détails sous-jacents du processus de construction - le principal échec de ces outils est que cette isolation même empêche les utilisateurs de pouvoir faire les changements dont ils ont besoin pour atteindre leurs objectifs de construction spécifiques à un projet.

Quiconque n'a que de bonnes choses à dire sur cet aspect de cmake, maven, gradle ou autre n'a tout simplement pas travaillé sur un projet qui les oblige à s'éloigner suffisamment des valeurs par défaut. Je les ai tous utilisés et j'ai passé des heures dans la frustration à essayer de déterminer comment contourner les lacunes de certaines fonctions d'outil «à tout faire» (sauf ce que je veux). Ce n'est tout simplement pas un problème avec les Autotools. Comme quelqu'un l'a mentionné plus tôt dans ce fil, vous pouvez déposer le script shell dans un fichier configure.ac et transformer le script en un fichier Makefile.am. Telle est la définition même de la transparence. Aucun autre outil existant ne permet ce niveau de flexibilité.

Voir également

Les références

Liens externes