Depuis le numéro 41 de Linux Magazine, les Mongueurs de Perl vous proposent tous les mois de découvrir le langage Perl. Après une longue introduction au langage, vous avez pu lire dans ces pages des articles consacrés à des techniques de programmation, à des modules très utiles, aux options de Perl et j'en passe. Notre objectif avec ces articles est de vous faire découvrir des aspects de l'utilisation de Perl qui ne sont pas décrits habituellement dans les tutoriels sur le net ou dans les livres qu'on trouve en librairie.
Pour faire simple, les fichiers Makefile sont composés de définitions de variables et de règles, dont la forme générale est :
target ... : prerequisites ...
command
...
...
Les commandes sont généralement des commandes de l'OS suivies d'options, de paramètres et de redirections. En fait, la partie command n'est pas interprétée par gmake qui ne fait que la transmettre au shell. Donc, un bout de script shell peut être utilisé comme commande.
Quand on commence à vouloir faire des choses non triviales, on tombe sur les problèmes classiques de portabilité et de dépendance :
- Quel shell va être appelé ? Bash, ou un autre ?
- Quelles commandes sont disponibles sur toutes les machines ?
Une façon de résoudre ces problèmes est de se reposer sur Perl.
L'utilisation de one-liners montre vite ses limites. L'expansion des variables par gmake permet de gagner en lisibilité et maintenabilité (l'objectif n'est surtout pas d'utiliser des astuces de golfeur). Le code Perl est déclaré dans une variable, par exemple, script_pl. Ensuite, il est utilisé dans la commande perl -e '$(script_pl)'. L'intérêt est de tout regrouper dans le seul fichier Makefile et ainsi d'éviter une dispersion dans plein de petits fichiers.
Exemple 1 : MANIFEST
Mon premier exemple permet de créer le fichier MANIFEST pour un projet archivé avec Git. Le gros du travail est fait par la commande git ls-files, le script Perl va s'occuper des finitions et des détails. Le fichier MANIFEST n'a pas besoin d'être archivé, mais il doit se référencer lui-même. Les fichiers cachés, par exemple, .gitignore, utiles lors du développement, sont exclus de la distribution. Finalement, le fichier MANIFEST doit être trié (ça fait plus professionnel).
manifest_pl := \
use strict; \
use warnings; \
my @files = qw{MANIFEST}; \
while (<>) { \
chomp; \
next if m{^\.}; \
push @files, $$_; \
} \
print join qq{\n}, sort @files;
MANIFEST:
git ls-files | perl -e '$(manifest_pl)' > MANIFEST
Techniquement, c'est un uniligne, mais il est découpé en plusieurs lignes grâce au backslash. Ceci permet d'écrire du code en respectant les bonnes pratiques Perl, qui commencent par l'utilisation des pragmas use strict; et use warnings;. Mais il n'est pas possible d'inclure du Pod, des commentaires et du heredoc.
Les commentaires commençant par # sont possibles dans un Makefile, mais pas à l'intérieur d'une variable multilignes ou d'une commande passée au shell, sauf évidemment en toute fin.
Pour éviter les problèmes d'interpolation avec gmake et le shell, il faut utiliser :
- q{} pour les chaînes littérales sans interpolation entre simples quotes '
- qq{} pour les chaînes littérales avec interpolation entre doubles quotes "
- qx{} pour les commandes entre `
- m{regex} au lieu de /regex/
C'est un exercice intéressant que d'écrire du code Perl sans les caractères ', ", `, / et #.
De plus, gmake nous oblige à doubler les $.
Exemple 2 : pkginfo
Mon deuxième exemple permet de créer un fichier pkginfo à partir d'un modèle pkginfo.in en ajoutant des données dynamiquement. Ces données peuvent provenir de variables du Makefile ou être calculées comme ici le checksum MD5 du fichier tarball. C'est un exemple de bonne pratique pour l'ouverture d'un fichier :
- la variable du descripteur de fichier est localisée par le my
- le mode d'ouverture est explicité, < pour lecture
- abandon en cas d'erreur, avec un message contenant le nom du fichier et le message provenant du système $!
TARBALL := $(PKG)-$(VERSION).tar.gz
pkginfo_pl := \
use strict; \
use warnings; \
use 5.008; \
use Digest::MD5; \
open my $$FH, q{<}, q{$(TARBALL)} \
or die qq{Cannot open $(TARBALL) ($$!)}; \
binmode $$FH; \
my %config = ( \
version => q{$(VERSION)}, \
rev => q{$(REV)}, \
md5 => Digest::MD5->new->addfile($$FH)->hexdigest(), \
); \
close $$FH; \
while (<>) { \
s{@(\w+)@}{$$config{$$1}}g; \
print; \
}
pkginfo: $(TARBALL)
perl -e '$(pkginfo_pl)' pkginfo.in > pkginfo
Ci-dessous, un fragment du fichier modèle. Les variables à substituer sont encadrées par des @ et les valeurs proviennent du hash config.
$ tail -n 3 pkginfo.in
version = '@version@-@rev@'
source = {
md5 = '@md5@',
Dans ce deuxième exemple, le script Perl contient des variables qui sont substituées par gmake. Si on avait un script externe, il aurait fallu passer par des arguments en ligne de commandes.
Pour ne pas retomber dans des problèmes de dépendance, il faut utiliser des modules core de Perl, comme ici Digest::MD5, core depuis la version 5.7.3. (Rappel : le module Module::CoreList permet de savoir depuis quand un module fait partie du core).
Exemple 3 : CHANGES
Finalement pour les habitués de la rubrique, mon troisième exemple est quand même un uniligne qui met la date courante dans un fichier CHANGES sur la ligne de la version en cours de packaging.
timestamp:
perl -i.bak -pe 's{^$(VERSION).*}{q{$(VERSION) }.localtime()}e' CHANGES
Et pour conclure, on peut utiliser cette technique d'expansion de script dans un Makefile avec d'autres langages, par exemple Ruby. En revanche, c'est impossible pour Python qui est dépendant de l'indentation du source.
Cette technique est aussi utilisable sous Windows, mais les fichiers Makefile ne sont pas portables. En effet, il faut double-quoter les commandes perl -e "$(script_pl)" et doubler les caractères %.
