Introduction aux outils automatiques GNU

Avez-vous déjà téléchargé le code source d'un projet logiciel populaire qui vous obligeait à taper le presque rituel ./configure ; faire &&faire installer séquence de commandes pour le compiler et l'installer ? Si oui, vous avez utilisé GNU Autotools. Si vous avez déjà examiné certains des fichiers accompagnant un tel projet, vous avez probablement aussi été terrifié par l'apparente complexité d'un tel système de construction.

Bonnes nouvelles! GNU Autotools est beaucoup plus simple à configurer que vous ne le pensez, et c'est GNU Autotools lui-même qui génère ces fichiers de configuration de 1 000 lignes pour vous. Oui, vous pouvez écrire 20 ou 30 lignes de code d'installation et obtenir les 4 000 autres gratuitement.

Autotools au travail

Le Terminal Linux

Les 7 meilleurs émulateurs de terminaux pour Linux
10 outils de ligne de commande pour l'analyse de données sous Linux
Télécharger maintenant :Aide-mémoire SSH
Aide-mémoire des commandes Linux avancées
Tutoriels de ligne de commande Linux

Si vous êtes un utilisateur novice de Linux à la recherche d'informations sur l'installation d'applications, vous n'êtes pas obligé de lire cet article ! Vous pouvez le lire si vous souhaitez rechercher comment un logiciel est construit, mais si vous installez simplement une nouvelle application, lisez mon article sur l'installation d'applications sous Linux.

Pour les développeurs, Autotools est un moyen simple et rapide de gérer et de conditionner le code source afin que les utilisateurs puissent compiler et installer des logiciels. Autotools est également bien pris en charge par les principaux formats d'empaquetage, tels que DEB et RPM, de sorte que les responsables des référentiels de logiciels peuvent facilement préparer un projet construit avec Autotools.

Autotools fonctionne par étapes :

Tout d'abord, pendant le ./configure étape, Autotools analyse le système hôte (l'ordinateur sur lequel il est exécuté) pour découvrir les paramètres par défaut. Les paramètres par défaut incluent l'emplacement des bibliothèques d'assistance et l'emplacement des nouveaux logiciels sur le système.
Ensuite, pendant le make étape, Autotools construit l'application, généralement en convertissant le code source lisible par l'homme en langage machine.
Enfin, pendant le make install étape, Autotools copie les fichiers qu'il a créés aux emplacements appropriés (tels qu'ils ont été détectés lors de l'étape de configuration) sur votre ordinateur.

Ce processus semble simple, et il l'est, tant que vous utilisez Autotools.

L'avantage Autotools

GNU Autotools est un logiciel important et important que la plupart d'entre nous tenons pour acquis. Avec GCC (la collection de compilateurs GNU), Autotools est l'échafaudage qui permet de construire et d'installer des logiciels libres sur un système en cours d'exécution. Si vous utilisez un système POSIX, ce n'est pas un euphémisme de dire que la plupart de votre système d'exploitation existe en tant que logiciel exécutable sur votre ordinateur à cause de ces projets.

Dans le cas probable où votre projet favori n'est pas un système d'exploitation, vous pourriez supposer qu'Autotools est exagéré pour vos besoins. Mais, malgré sa réputation, Autotools possède de nombreuses petites fonctionnalités qui peuvent vous être utiles, même si votre projet est une application relativement simple ou une série de scripts.

Portabilité

Tout d'abord, Autotools est conçu pour la portabilité. Bien qu'il ne puisse pas faire fonctionner votre projet sur toutes les plates-formes POSIX (c'est à vous, en tant que codeur), Autotools peut garantir que les fichiers que vous avez marqués pour l'installation sont installés aux emplacements les plus sensibles sur une plate-forme connue. Et grâce aux Autotools, il est facile pour un utilisateur expérimenté de personnaliser et de remplacer toute valeur non optimale, selon son propre système.

Avec Autotools, tout ce que vous devez savoir, c'est quels fichiers doivent être installés à quel emplacement général. Il s'occupe de tout le reste. Plus de scripts d'installation personnalisés qui se cassent sur un système d'exploitation non testé.

Emballage

Autotools est également bien pris en charge. Confiez un projet avec Autotools à un conditionneur de distribution, qu'il s'agisse de conditionner un RPM, un DEB, un TGZ ou autre chose, et leur travail est simple. Les outils d'emballage connaissent Autotools, il n'y aura donc probablement pas de correctifs, de piratage ou d'ajustements nécessaires. Dans de nombreux cas, l'intégration d'un projet Autotools dans un pipeline peut même être automatisée.

Comment utiliser les outils automatiques

Pour utiliser Autotools, vous devez d'abord avoir installé Autotools. Votre distribution peut fournir un package destiné à aider les développeurs à créer des projets, ou elle peut fournir des packages séparés pour chaque composant, vous devrez donc peut-être faire des recherches sur votre plate-forme pour découvrir quels packages vous devez installer.

Les principaux composants d'Autotools sont :

fabrication automatique
autoconf
faire

Bien que vous ayez probablement besoin d'installer le compilateur (GCC, par exemple) requis par votre projet, Autotools fonctionne très bien avec des scripts ou des actifs binaires qui n'ont pas besoin d'être compilés. En fait, Autotools peut être utile pour de tels projets car il fournit une désinstallation de make script pour une suppression facile.

Une fois tous les composants installés, il est temps d'examiner la structure des fichiers de votre projet.

Structure du projet Autotools

GNU Autotools a des attentes très spécifiques, et la plupart d'entre elles sont probablement familières si vous téléchargez et construisez souvent du code source. Tout d'abord, le code source lui-même devrait se trouver dans un sous-répertoire appelé src .

Votre projet n'a pas à répondre à toutes ces attentes, mais si vous placez des fichiers dans des emplacements non standard (du point de vue d'Autotools), vous devrez faire des ajustements pour cela dans votre Makefile plus tard.

De plus, ces fichiers sont requis :

ACTUALITÉS
LISEZMOI
AUTEURS
Journal des modifications

Vous n'avez pas besoin d'utiliser activement les fichiers, et ils peuvent être des liens symboliques vers un document monolithique (comme README.md ) qui englobe toutes ces informations, mais elles doivent être présentes.

Configuration des outils automatiques

Créez un fichier appelé configure.ac dans le répertoire racine de votre projet. Ce fichier est utilisé par autoconf pour créer la configuration script shell que les utilisateurs exécutent avant de créer. Le fichier doit contenir au minimum l'AC_INIT et AC_OUTPUT macro M4. Vous n'avez pas besoin de connaître le langage M4 pour utiliser ces macros; ils sont déjà écrits pour vous, et tous ceux qui concernent Autotools sont définis dans la documentation.

Ouvrez le fichier dans votre éditeur de texte préféré. Le AC_INIT La macro peut comprendre le nom du package, sa version, une adresse e-mail pour les rapports de bogue, l'URL du projet et éventuellement le nom du fichier TAR source.

Le AC_OUTPUT macro est beaucoup plus simple et n'accepte aucun argument.

AC_INIT([pingouin], [2019.3.6], [[email protected]])
AC_OUTPUT

Si vous deviez exécuter autoconf à ce stade, une configuration le script serait généré à partir de votre configure.ac fichier, et il fonctionnerait avec succès. C'est tout ce qu'il ferait, cependant, car tout ce que vous avez fait jusqu'à présent est de définir les métadonnées de votre projet et d'appeler à la création d'un script de configuration.

Les prochaines macros que vous devez invoquer dans votre configure.ac file sont des fonctions pour créer un Makefile. Un Makefile indique le make commande quoi faire (généralement, comment compiler et lier un programme).

Les macros pour créer un Makefile sont AM_INIT_AUTOMAKE , qui n'accepte aucun argument, et AC_CONFIG_FILES , qui accepte le nom que vous voulez donner à votre fichier de sortie.

Enfin, vous devez ajouter une macro pour tenir compte du compilateur dont votre projet a besoin. La macro que vous utilisez dépend évidemment de votre projet. Si votre projet est écrit en C++, la macro appropriée est AC_PROG_CXX , alors qu'un projet écrit en C nécessite AC_PROG_CC , etc., comme détaillé dans la section Création de programmes et de bibliothèques de la documentation Autoconf.

Par exemple, je pourrais ajouter ce qui suit pour mon programme C++ :

AC_INIT([pingouin], [2019.3.6], [[email protected]])
AC_OUTPUT
AM_INIT_AUTOMAKE
AC_CONFIG_FILES([Makefile])
AC_PROG_CXX

Enregistrez le fichier. Il est temps de passer au Makefile.

Génération de Makefile d'outils automatiques

Les makefiles ne sont pas difficiles à écrire manuellement, mais Autotools peut en écrire un pour vous, et celui qu'il génère utilisera les options de configuration détectées lors du ./configure étape, et il contiendra beaucoup plus d'options que vous ne penseriez inclure ou que vous voudriez écrire vous-même. Cependant, Autotools ne peut pas détecter tout ce dont votre projet a besoin pour être construit, vous devez donc ajouter quelques détails dans le fichier Makefile.am , qui à son tour est utilisé par automake lors de la construction d'un Makefile.

Makefile.am utilise la même syntaxe qu'un Makefile, donc si vous avez déjà écrit un Makefile à partir de zéro, alors ce processus sera familier et simple. Souvent, un Makefile.am Le fichier n'a besoin que de quelques définitions de variables pour indiquer quels fichiers doivent être créés et où ils doivent être installés.

Variables se terminant par _PROGRAMS identifier le code qui doit être construit (ceci est généralement considéré comme le code principal cibler; c'est la principale raison pour laquelle le Makefile existe). Automake reconnaît d'autres primaires, comme _SCRIPTS , _DATA , _LIBRAIRES , et d'autres parties communes qui composent un projet logiciel.

Si votre application est littéralement compilée pendant le processus de construction, alors vous l'identifiez comme un programme binaire avec le bin_PROGRAMS variable, puis faites référence à toute partie du code source nécessaire pour la construire (ces parties peuvent être un ou plusieurs fichiers à compiler et à relier) en utilisant le nom du programme comme préfixe de variable :

bin_PROGRAMS =pingouin
penguin_SOURCES =pingouin.cpp

La cible de bin_PROGRAMS est installé dans le bindir , qui est configurable par l'utilisateur lors de la compilation.

Si votre application n'est pas réellement compilée, votre projet n'a pas besoin d'un bin_PROGRAMS variables du tout. Par exemple, si votre projet est un script écrit en Bash, Perl ou un langage interprété similaire, définissez un _SCRIPTS variable à la place :

bin_SCRIPTS =bin/pingouin

Automake s'attend à ce que les sources soient situées dans un répertoire appelé src , donc si votre projet utilise une structure de répertoires alternative pour sa mise en page, vous devez indiquer à Automake d'accepter le code provenant de sources extérieures :

AUTOMAKE_OPTIONS =objets de sous-répertoire étrangers

Enfin, vous pouvez créer des règles Makefile personnalisées dans Makefile.am et ils seront copiés textuellement dans le Makefile généré. Par exemple, si vous savez qu'une valeur temporaire doit être remplacée dans votre code source avant que l'installation ne se poursuive, vous pouvez créer une règle personnalisée pour ce processus :

all-am :penguin
        touch bin/penguin.sh
        
penguin :bin/penguin.sh
        @sed "s|__datadir__|@datadir@|" $<>bin/$@

Une astuce particulièrement utile consiste à étendre le propre existant cible, au moins pendant le développement. Le rendre propre supprime généralement tous les fichiers de construction générés à l'exception de l'infrastructure Automake. Il est conçu de cette façon parce que la plupart des utilisateurs veulent rarement rendre propre pour effacer les fichiers qui facilitent la construction de leur code.

Cependant, pendant le développement, vous souhaiterez peut-être une méthode pour ramener votre projet de manière fiable à un état relativement non affecté par Autotools. Dans ce cas, vous pouvez ajouter ceci :

clean-local :
        @rm config.status configure config.log
        @rm Makefile 
        @rm -r autom4te.cache/
        @rm aclocal.m4 
        @rm compile install-sh manquant Makefile.in

Il y a beaucoup de flexibilité ici, et si vous n'êtes pas déjà familier avec les Makefiles, il peut être difficile de savoir ce que votre Makefile.am Besoins. La nécessité la plus stricte est une cible principale, qu'il s'agisse d'un programme binaire ou d'un script, et une indication de l'emplacement du code source (que ce soit via un _SOURCES variable ou en utilisant AUTOMAKE_OPTIONS pour dire à Automake où chercher le code source).

Une fois que vous avez défini ces variables et paramètres, vous pouvez essayer de générer vos scripts de construction comme vous le voyez dans la section suivante, et ajuster pour tout ce qui manque.

Génération de scripts de compilation Autotools

Vous avez construit l'infrastructure, il est maintenant temps de laisser Autotools faire ce qu'il fait le mieux :automatiser l'outillage de votre projet. La façon dont le développeur (vous) interagit avec Autotools est différente de la façon dont les utilisateurs construisent votre code.

Les constructeurs utilisent généralement cette séquence bien connue :

$ ./configure
$ make
$ sudo make install

Cependant, pour que cette incantation fonctionne, vous, en tant que développeur, devez amorcer l'infrastructure de construction. Tout d'abord, exécutez autoreconf pour générer le script de configuration que les utilisateurs invoquent avant d'exécuter make . Utilisez le -install possibilité d'apporter des fichiers auxiliaires, comme un lien symbolique vers depcomp , un script pour générer des dépendances pendant le processus de compilation et une copie de la compile script, un wrapper pour les compilateurs pour tenir compte de la variance de syntaxe, etc.

$ autoreconf --install
configure.ac:3 :installation de './compile'
configure.ac:2 :installation de './install-sh'
configure.ac :2 :installation de './missing'

Avec cet environnement de construction de développement, vous pouvez ensuite créer un package pour la distribution du code source :

$ faire la distribution

La dist target est une règle que vous obtenez "gratuitement" de la part d'Autotools.

C'est une fonctionnalité qui est intégrée au Makefile généré à partir de votre humble Makefile.am configuration. Cette cible produit un tar.gz archive contenant tout votre code source et toute l'infrastructure essentielle d'Autotools afin que les personnes téléchargeant le package puissent construire le projet.

À ce stade, vous devez examiner attentivement le contenu de l'archive pour vous assurer qu'elle contient tout ce que vous avez l'intention d'expédier à vos utilisateurs. Vous devriez aussi, bien sûr, essayer de créer vous-même :

$ tar --extract --file penguin-0.0.1.tar.gz
$ cd penguin-0.0.1
$ ./configure 
$ make 
$ DESTDIR=/tmp/penguin-test-build make install

Si votre construction réussit, vous trouvez une copie locale de votre application compilée spécifiée par DESTDIR (dans le cas de cet exemple, /tmp/penguin-test-build ).

$ /tmp/example-test-build/usr/local/bin/example 
bonjour le monde de GNU Autotools

Temps d'utilisation des outils automatiques

Autotools est une excellente collection de scripts pour un processus de publication prévisible et automatisé. Cet ensemble d'outils peut être nouveau pour vous si vous êtes habitué aux constructeurs Python ou Bash, mais il vaut probablement la peine d'apprendre pour la structure et l'adaptabilité qu'il offre à votre projet.

Et Autotools n'est pas seulement pour le code non plus. Les Autotools peuvent être utilisés pour créer des projets Docbook, pour organiser les médias (j'utilise Autotools pour mes sorties musicales), des projets de documentation et tout ce qui pourrait bénéficier de cibles d'installation personnalisables.