Introduction
Par le terme autotools on se réferre usuellement aux outils
développés par le projet GNU pour créer des systèmes de compilation
indépendants de la plate-forme et du système, autoconf,
automake et libtool. Même si chaque paquet ne les
utilisent tous en même temps, la plupart des modernes le font. Souvent,
de plus vieux paquets n'utilisent pas automake et libtool ;
Les paquets KDE utilisent un système de compilation plus complexe qui
dépend au final des trois logiciels cités plus haut.
Il est aisé de reconaitre un paquet dont le système de compilation est
basé sur les autotools : s'il y a un script configure, et un
fichier configure.in ou configure.ac, le
système de compilation est basé sur autoconf ; s'il y a un ou
plusieurs fichiers Makefile.am dans divers
sous-répertoires, il est aussi basé sur automake ; s'il y a un
script ltmain.sh, il utilise aussi libtool.
Pour compiler un paquet basé sur les autotools, les outils eux-mêmes ne sont
pas strictement nécessaires : le script configure est un
simple script Bourne Shell (usuellement, mais ceci sera traité plus
tard) et il transforme les fichiers Makefile.in en un
Makefile, plus simple, pour make (ou, plus souvnet,
gmake). Malgré qu'ils soient optionels pour compiler le paquet,
souvent des "patches" requis pour corriger des problèmes tels que
--as-needed build failure ou
automagic dependencies nous forcent
à relancer ces outils pour recréer les scripts et schémas de makefiles.
Ce guide ne donnera pas de consigne sur comment corriger les erreurs des
paquets en utilisant les autotools car c'est un vaste sujet qui requiert
d'expliquer beaucoup de choses. Pour une simple introduction aux
erreurs les plus courantes faites en utilisant les autotools, il est
plutot suggéré de lire l'article
best practices with autotools.
Au lieu de celà, il décrit les cas courants où relancer les autotools amène à
des erreurs, soit à la reconstruction du script soit à la compilation.
Relancer les autotools
La première chose importante à savoir est comment reconstruire
proprement le support pour les autotools, étant donnée que c'est
un problème courant qui cause des erreurs dans certains
ebuilds. L'ordre dans lequel les autotools sont appellés est
important comme l'un dépend de l'autre et que le résultat final
dépend beaucoup du respect de cet ordre.
Beaucoup de paquets fournissent un seul script, souvent appellé
autogen.sh ou bootstrap.sh qui sert à exécuter
ces outils dans l'ordre qu'ils pensent être le bon, souvent en
définissant des variables pour que la bonne version des outils soit
appellée (différentes versions des autotools sont souvent incompatibles)
Ces scripts sont, en général, préférés aux autres méthodes mais
contiennent souvent des erreurs ou supposent être sur un certain
environnement qui peut être propre à une autre distribution, pour cette
raison ils doivent être attentivement vérifiés et lorsqu'ils n'apportent
aucun avantage par rapport aux autres méthodes (comme ils peuvent se
contenter d'appeller les outils les uns après les autres sans pour
autant leur passer en arguement de paramètres spéciaux ou vérifier leur
valeur de retour), ils ne devraient pas être utilisés.
Le paquet autoconf fournit un script automatique, appellé
autoreconf qui devrait détecter automatiquement quels autotools
sont utilisés et les appeller, mais il échoue trop souvent à détecter la
bonne version ou plante à cause de cas imprévus. De plus, il appelle
autopoint, le script qui rajoute le support pour gettext à
un paquet, cet appel n'est presque jamais requis après avoir patché un
paquet. C'est pour cette raison que autoreconf n'est pas
recommandé et évité autant que possible (la même chose prévaut pour
certains scripts maison fournis par des paquets qui les utilisent).
Pour pallier à ces problèmes, l'eclass autotools a été ajoutée ;
cette eclass fournit des fonctions autour des autotools GNU :
eautoconf, eautomake, _elibtoolize (avec le préfixe _
pour éviter les collisions avec les fonctions elibtoolize de
l'eclass libtool) et la plus importante eautoreconf.
Cette fonction n'utilise pas le script cassé autoreconf, mais
analyse plutot les fichiers présents pour le support des autotools et
les lance dans le bon ordre. Il appelle aussi la fonction
elibtoolize pour patcher les fichiers pour le support de libtool
si nécessaire, évitant ainsi les problèmes lorsqu'elle est appellée
avant la recréation des fichiers des autotools.
Les fonctions dans l'eclass autotools ont aussi l'avantage de
ne pas présenter aux utilisateurs de nombreux messages non formatés
(dans le cas d'avertissements) ou rien (dans le cas où il n'y a pas de
problème) ; au lieu de cela, elle fournissent des messages sur leur
status avec ebegin et eend pour que les utilisateurs
sachent ce qu'il se passe, elles tracent aussi les cas d'erreurs en
fournissant des messages de sortie à la epatch dans le cas
d'erreurs. Pour cette raison ces fonctions sont préférées aux appels
manuels ou mauvais ou aux scripts presque inutiles fournis dans les
paquets. Un autre avantage est que l'eclass autotools
rajoute aussi les dépendances à la compilation aux paquets nécessaires
(sys-devel/autoconf, sys-devel/automake,
sys-devel/libtool).
Les paquets KDE utilisent souvent un système plus complexe basé sur les
autotools qui font usage de fichiers configure.in.in
spécifiques et un peu de magie de perl. Pour cette raison ils ne doivent
jamais utiliser l'eclass autotools. Si vous avez
besoin de refaire appel aux autotools il est préférable d'effacer le
fichier ${S}/configure et de faire savoir à la fonction
kde_src_compile qu'il faut relancer les scripts qui recréent le
support pour les autotools.
Macros potentiellement non définies
L'erreur la plus commune avec les autotools est à propos du message
d'autoconf "possibly undefined macro: UNE_MACRO". Ce
message est affiché quand une macro est appellée depuis le
fichier configure.ac ou configure.in
mais elle n'est pas définie dans le fichier aclocal.m4
créé par aclocal.
Ceci arrive souvent car la macro mentionnée n'est pas disponible lorsque
aclocal est appellé ; comme, par défaut, il charge les macros
trouvées dans /usr/share/aclocal, ceci signifie que le
paquet fournissant cette macro n'est pas installé (ou la macro est
appellée avec un mauvais nom). Comme le second cas est soit trivial soit
complexe à résoudre, nous nous intéresserons aux premier, une définition
de macro manquante.
Les macros écrites par les développeurs pour que leur programme soit détecté
dans le système en utilisant les autotools sont souvent écrits dans des
fichiers m4 qui sont installés dans le sus-mentionné répertoire
/usr/share/aclocal. Comme beaucoup de paquets utilisent
ces macros pour des dépendances optionelles, un fichier m4 peut être
nécessaire mais ne pas être installé sur le système où les autotools
sont appellés ; pour pallier à ce problème il est possible de copier le
fichier m4 dans un sous-répertoire fourni avec le paquet lui même.
Malheureusement pour utiliser ce sous-répertoire, souvent nommé
m4, il est nécessaire d'en informer aclocal. Dans
les projets utilisant automake il est possible de définir ceci
dans le fichier Makefile.am principal en définissant la
variable ACLOCAL_AMFLAGS :
...
ACLOCAL_AMFLAGS = -I m4
...
Ceci est souvent évité par les développeurs de logiciels qui passent
simplement le paramètre -I m4 à aclocal lorsqu'ils font leur
paquet. Comme ajouter un patch pour résoudre ce problème est trop
violent, il est plus simple, si le paquet a un répertoire avec les
fichiers m4 requis de le définir dans la variable AT_M4DIR. La
même chose vaut si le paquet n'utilise pas automake mais
seulement autoconf.
src_unpack() {
...
AT_M4DIR="m4" eautoreconf
}
Dans de rares cas le programme utilise un système de construction à la
cygnus avec des "sous-configure", l'exemple précédent peut échouer
puisqu'il essaie de trouver un sous-répertoire m4 là où est le
configure ; pour résoudre ce genre de problème, définissez le à la place
à ${S}/m4.
C'est souvent une bonne idée d'informer les développeurs des programmes
s'ils ne définissent pas la variable ACLOCAL_AMFLAGS, comme ça il
peuvent l'arranger pour les versions ultérieures ; dans un monde
théorique et parfait, eautoreconf seul devrait résoudre tous les
problèmes.
Moins souvent, mais ça arrive tout de même, il n'y a pas de sous-répertoire
avec des fichiers m4, ou le fichier avec la macro indéfinie n'est pas
présent ; pour résoudre ce problème vous devez trouver quel paquet
fournit le fichier m4, et ensuite l'ajouter à ce répertoire, soit avec
un patch soit en le mettant sur les mirroirs et ensuite en l'ajoutant au
SRC_URI (auquel cas vous devez ajouter ${WORKDIR} à la
liste des répertoires dans lesquels chercher ou le déplacer dans le bon
répertoire). Ce genre de problème est un des plus pénibles, ainsi il
est souvent mieux d'en informer les développeurs du logiciel dès que
possible pour que les prochaines versions ne nécessitent pas de tels
"hacks".
automake échoue, requiert des fichiers manquants
Une autre erreur commune, cette fois avec automake est un
échec à cause de fichiers manquants, tels que NEWS
ou README. Ceci est à cause du fait que les
autotools supposent, si personne ne leur précise le contraire,
qu'ils travaillent sur un paquet GNU, qui ont une série de
fichiers dû au guide du style de code de GNU, et échoue ainsi
quand ces fichiers manquent. Dans ces cas, automake doit
être appellé avec le paramètre --foreign, qui lui dit de
ne pas échouer si les fichiers requis par GNU ne sont pas
présents.
Encore une fois, la fonction eautomake tente de rendre plus simple la
reconstruction des autotools en vérifiant si tous les fichiers requis
par GNU sont présents et en appellant ensuite automake avec la
bonne option si ce n'est pas le cas. La bonne façon de résoudre ce
problème (en l'envoyant aux développeurs du logiciel) est d'ajouter à la
variable AUTOMAKE_OPTIONS l'option foreign pour qu'il
sache tout seul qu'il doit utiliser le support "foreign".
Quand des fichiers requis par le configure.in ou
configure.ac au lieu du Makefile.am, et sont
souvent les fichiers config.guess et
config.sub, le problème est que le paquet n'est pas
proprement "bootstrappé". Pour résoudre ceci, automake doit être
appellé avec les options --add-missing --copy. C'est ce que la
fonction eautomake fait déjà, ainsi si vous rencontrez ce
problème vous devriez penser à utiliser les fonctions fournies par
l'eclass autotools au lieu d'appeller les outils
manuellement ou avec d'éventuels scripts fournis dans le paquet.
Une erreur courante faite lorsque automake échoue est de ne pas
mettre la condition || die, évitant ainsi d'interrompre le
processus de compilation. C'est une erreur parce que les fichiers
seront souvent nécessaires plus tard, il est préférable de toujours
forcer leur remplacement, aussi parceque dans de nombreux cas les
nouvelles versions des deux fichiers sont nécessaires pour compiler sur
certaines architectures.
Version des dépendances manquantes
Depuis l'été 2006, l'eclass autotools ne dépend plus de toutes les
versions des paquets automake et autoconf automatiquement,
ce qui signifie que vous ne pouvez pas supposer que les utilisateurs ont
installé toutes les versions, et les dépendances doivent être corrigées
pour avoir les bonnes versions installées. Pour simplifier la gestion
des dépendances et forcer les versions nécessaires, les variables
WANT_AUTOCONF et WANT_AUTOMAKE sont considérées comme
entrée pour l'eclass autotools qui se chargera de rajouter les bonnes
dépendances.
WANT_AUTOCONF="2.1"
WANT_AUTOMAKE="1.4"
inherit autotools
Dans de nombreux cas, au lieu de dépendre d'une version spécifique
d'automake ou autoconf, on veut dépendre de la dernière version
disponible, probablement déjà présente sur le système des utilisateurs.
Pour cette raison l'eclass autotools accepte une valeur spéciale pour
les variables mentionnées, latest, qui sera remplacé pour
autoconf par 2.5 et pour automake soit 1.9 soit 1.10 selon
ce qui est démasqué pour le système donné. Ceci est suggéré quand le
paquet ne dépend pas de quelques options ou mauvais comportement de plus
vieilles versions.
WANT_AUTOCONF="latest"
WANT_AUTOMAKE="latest"
inherit autotools