Attachment 109248 Details for Bug 165473 – teh file

teh file

autofailure.xml (text/plain), 15.38 KB, created by Alexis Ballier on 2007-02-05 18:49:37 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Alexis Ballier

Created: 2007-02-05 18:49:37 UTC

Size: 15.38 KB

patch

obsolete

><?xml version="1.0" encoding="UTF-8"?>
><!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
>
>
><guide link="/proj/fr/qa/autofailure.xml" lang="fr">
><title>Comment corriger les Ã©checs des autotools</title>
>
><author title="Auteur">
> <mail link="flameeyes@gentoo.org">Diego PettenÃ²</mail>
></author>
><author title="Traducteur">
> <mail link="aballier@gentoo.org">Alexis Ballier</mail>
></author>
>
><abstract>
>	Ce guide a pour but de dÃ©crire les situations courantes qui causent des erreurs
>	lors de l'appel aux autotools dans un ebuild et de donner des conseils sur comment
>	les corriger.
></abstract>
>
>
>
><license/>
>
><version>0.5</version>
><date>2006-10-28</date>
>
><chapter> 
><title>Introduction</title>
>
><section>
><body>
>
>	
>		Par le terme <e>autotools</e> 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, <c>autoconf</c>, <c>automake</c> et <c>libtool</c>. 
>		MÃªme si pas tous les paquets les utilisent tous en mÃªme temps, la plupart des modernes le font.
>		Souvent, de plus vieux paquets n'utilisent pas <c>automake</c> et <c>libtool</c>; 
>		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 <path>configure</path>, et un fichier <path>configure.in</path> ou
>	<path>configure.ac</path>, le systÃ¨me de compilation est basÃ© sur <c>autoconf</c>;
>	s'il y a un ou plusieurs fichiers <path>Makefile.am</path> dans divers sous-rÃ©pertoires,
>	il est aussi basÃ© sur <c>automake</c>;
>	s'il y a un script <path>ltmain.sh</path>, il utilise aussi <c>libtool</c>.
>
>
>
>	Pour compiler un paquet basÃ© sur les autotools, les outils eux-mÃªmes ne sont pas strictement nÃ©cessaires:
>	le script <path>configure</path> est un simple script Bourne Shell (usuellement, mais ceci sera traitÃ© plus tard)
>	et il transforme les fichiers <path>Makefile.in</path> en un, plus simple, <path>Makefile</path> pour
>	<c>make</c> (ou, plus souvnet, <c>gmake</c>). 
>	MalgrÃ© qu'ils soient optionels pour compiler le paquet, souvent des "patches" requis pour corriger des problÃ¨mes
>	tels que
><uri link="asneeded.xml">--as-needed build failure</uri> ou
><uri link="automagic.xml">automagic dependencies</uri> 
>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 
><uri link="/doc/en/articles/autotools-practices.xml">best practices with autotools</uri>. 
>	Au lieu de celÃ , il dÃ©crire les cas courants oÃ¹ relancer les autotools amÃ¨ne Ã  des erreurs, soit Ã  la reconstruction du script soit Ã  la compilation.
>
>
></body>
></section>
>
></chapter>
>
><chapter> 
><title>Relancer les autotools</title>
><section>
>
><body>
>
>	
>		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 causent 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Ã© <path>autogen.sh</path> ou
>	<path>bootstrap.sh</path> 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 ne s'entendent souvent pas bien). 
>	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 <c>autoconf</c> fournit un script automatique, appellÃ© <c>autoreconf</c>
>	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 <c>autopoint</c>, le script qui rajoute le support pour <c>gettext</c>
>	Ã  un paquet, cet appel n'est presque jamais requis aprÃ¨s avoir patchÃ© un paquet.
>	C'est pour cette raison que <c>autoreconf</c> 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 <path>autotools</path> a Ã©tÃ© ajoutÃ©e; cette eclass
>	fournit des fonctions autour des autotools GNU: <c>eautoconf</c>,
><c>eautomake</c>, <c>_elibtoolize</c> (avec le prÃ©fixe _ pour Ã©viter les collisions avec les fonctions
><c>elibtoolize</c> de l'eclass <path>libtool</path>) et la plus importante <c>eautoreconf</c>. 
>Cette fonction n'utilise pas le script cassÃ© <c>autoreconf</c>, mais analyse plutot les fichiers
>prÃ©sents pour le support des autotools et les lance dans le bon ordre.
>Il appelle aussi la fonction <c>elibtoolize</c> 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 <path>autotools</path> 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 <c>ebegin</c> et <c>eend</c>
>	pour que les utilisateurs sachent ce qu'il se passe, elles tracent aussi les cas d'erreurs
>	en fournissant des messages de sortie Ã  la <c>epatch</c> 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 <path>autotools</path> rajoute aussi les dÃ©pendances
>	Ã  la compilation aux paquets nÃ©cessaires
>(sys-devel/autoconf, sys-devel/automake,
>sys-devel/libtool).
>
>
><warn>
>	Les paquets KDE utilisent souvent un systÃ¨me plus complexe basÃ© sur les autotools
>	qui font usage de fichiers <path>configure.in.in</path> spÃ©cifiques
>	et un peu de magie de perl. Pour cette raison ils ne doivent jamais utiliser l'eclass <path>autotools</path>.
>	Si vous avez besoin de refaire appel aux autotools il est prÃ©fÃ©rable d'effacer le fichier
>	<path>${S}/configure</path> et de faire savoir Ã  la fonction <c>kde_src_compile</c>
>	qu'il faut relancer les scripts qui recrÃ©ent le support pour les autotools.
></warn>
>
></body>
></section>
>
><section>
><title>Possibly undefind macros</title>
>
><body>
>
>	
>		L'erreur la plus commune avec les autotools est Ã  propos du
>		message d'<c>autoconf</c> "possibly undefined macro: UNE_MACRO".
>		Ce message est affichÃ© quand une macro est appellÃ©e depuis le fichier
>		<path>configure.ac</path> ou <path>configure.in</path> mais elle n'est pas dÃ©finie
>		dans le fichier <path>aclocal.m4</path> crÃ©Ã© par <c>aclocal</c>.
>
>
>
>	Ceci arrive souvent car la macro mentionnÃ©e n'est pas disponible lorsque
>	<c>aclocal</c> est appellÃ©; comme, par dÃ©faut, il charge les macros trouvÃ©es
>	dans 
>	<path>/usr/share/aclocal</path>, 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 <path>/usr/share/aclocal</path>. 
>	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Ã© <path>m4</path>,
>	il est nÃ©cessaire d'en informer <c>aclocal</c>. Dans les projets utilisant <c>automake</c>
>	il est possible de dÃ©finir ceci dans le fichier <path>Makefile.am</path> principal en dÃ©finissant
>	la variable ACLOCAL_AMFLAGS:
>
>
><pre caption="exemple de comment dire Ã  aclocal de chercher ses fichiers de macro dans le rÃ©pertoire 'm4'">
>...
>ACLOCAL_AMFLAGS = -I m4
>...
></pre>
>
>
>	Ceci est souvent Ã©vitÃ© par les dÃ©veloppeurs de logiciels qui passent simplement le paramÃ¨tre
>	<c>-I m4</c> Ã  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 <c>automake</c> mais seulement <c>autoconf</c>.
>
>
><pre caption="dire Ã  eautoreconf de chercher des fichiers de macro dans le rÃ©pertoire 'm4'">
>src_unpack() {
> ...
> AT_M4DIR="m4" eautoreconf
>}
></pre>
>
>
>	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 Ã  <path>${S}/m4</path>.
>
>
><note>
>	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, <c>eautoreconf</c> seul devrait rÃ©soudre tous les problÃ¨mes.
></note>
>
>
>	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".
>
>
></body>
></section>
>
><section> 
><title>automake Ã©choue, requiert des fichiers manquants</title>
>
><body>
>
>	
>		Une autre erreur commune, cette fois avec <c>automake</c> 
>		est un Ã©chec Ã  cause de fichiers manquants, tels que <path>NEWS</path> ou <path>README</path>. 
>		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, <c>automake</c> doit Ãªtre appellÃ© avec le paramÃ¨tre <c>--foreign</c>, 
>		qui lui dit de ne pas Ã©chouer si les fichiers requis par GNU ne sont pas prÃ©sents.
>
>
>
>	Encore une fois, la fonction <c>eautomake</c> 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 <c>automake</c> 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 <e>foreign</e> pour qu'il sache tout seul
>	qu'il doit utiliser le support "foreign".
>
>
>
>	Quand des fichiers requis par le <path>configure.in</path> ou
>	<path>configure.ac</path> au lieu du <path>Makefile.am</path>,
>	et sont souvent les fichiers <path>config.guess</path> et <path>config.sub</path>, 
>	le problÃ¨me est que le paquet n'est pas proprement "bootstrappÃ©".
>	Pour rÃ©soudre ceci, <c>automake</c> doit Ãªtre appellÃ© avec les options 
>	<c>--add-missing --copy</c>. C'est ce que la fonction <c>eautomake</c> fait dÃ©jÃ ,
>	ainsi si vous rencontrez ce problÃ¨me vous devriez penser Ã  utiliser les fonctions 
>	fournies par l'eclass <path>autotools</path> au lieu d'appeller les outils manuellement
>	ou avec d'Ã©ventuels scripts fournis dans le paquet.
>
>
><warn>
>	Une erreur courante faite lorsque <c>automake</c> Ã©choue
>	est de ne pas mettre la condition <c>|| die</c>, Ã©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.
></warn>
>
></body>
></section>
>
><section>
><title>Version des dÃ©pendances manquantes</title>
>
><body>
>
>
>	Depuis l'Ã©tÃ© 2006, l'eclass <c>autotools</c> ne dÃ©pend plus de toutes les versions
>	des paquets <c>automake</c> et <c>autoconf</c> 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.
>
>
><pre caption="dependre d'autoconf 2.1 et automake 1.4">
>WANT_AUTOCONF="2.1"
>WANT_AUTOMAKE="1.4"
>
>inherit autotools
></pre>
>
>
>	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, <e>latest</e>, qui sera remplacÃ© pour <c>autoconf</c> par 
>	2.5 et pour <c>automake</c> 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.
>
>
><pre caption="dÃ©pendre de la version la plus rÃ©cente des autotools">
>WANT_AUTOCONF="latest"
>WANT_AUTOMAKE="latest"
>
>inherit autotools
></pre>
>
></body>
></section>
>
></chapter>
>
></guide>
>
>

Actions: View

Attachments on bug 165473: 109248 | 109382 | 109459