Attachment 109459 Details for Bug 165473 – updated again

updated again

autofailure.xml (text/plain), 15.36 KB, created by Alexis Ballier on 2007-02-07 20:22:39 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Alexis Ballier

Created: 2007-02-07 20:22:39 UTC

Size: 15.36 KB

patch

obsolete

><?xml version="1.0" encoding="UTF-8"?>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
>
><guide link="/proj/fr/qa/autofailure.xml" lang="fr">
><title>Comment corriger les Ã©checs des autotools</tillÃ©s>
>
><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Ã©fÃ¨re 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 chaque paquet ne 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>&nbsp;;
>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 reconnaÃ®tre un paquet dont le systÃ¨me de compilation est
>basÃ© sur les autotools&nbsp;: 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>&nbsp;; 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>&nbsp;; 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&nbsp;: 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
><path>Makefile</path>, plus simple, pour <c>make</c> (ou, plus souvent,
><c>gmake</c>). MalgrÃ© qu'ils soient optionnels pour compiler le paquet,
>souvent des "patches" requis pour corriger des problÃ¨mes tels que 
><uri link="/proj/en/qa/asneeded.xml">--as-needed build failure</uri> ou 
><uri link="/proj/en/qa/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
>plutÃ´t suggÃ©rÃ© de lire l'article <uri link="/doc/en/articles/autotools-practices.xml">
>best practices with autotools</uri>. 
>Au lieu de cela, il dÃ©crit 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 cause des erreurs dans certains
>ebuilds. L'ordre dans lequel les autotools sont appelÃ©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 appelÃ©
><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
>appelÃ©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'appeler les outils les uns aprÃ¨s les autres sans pour
>autant leur passer en argument 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, appelÃ©
><c>autoreconf</c> qui devrait dÃ©tecter automatiquement quels autotools
>sont utilisÃ©s et les appeler, 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&nbsp;;
>cette eclass fournit des fonctions autour des autotools GNU&nbsp;:
><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 plutÃ´t 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 appelÃ©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)&nbsp;; 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>Macros potentiellement non dÃ©finies</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 appelÃ©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 appelÃ©&nbsp;; 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
>appelÃ©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 susmentionnÃ© rÃ©pertoire
><path>/usr/share/aclocal</path>. Comme beaucoup de paquets utilisent
>ces macros pour des dÃ©pendances optionnelles, un fichier m4 peut Ãªtre
>nÃ©cessaire mais ne pas Ãªtre installÃ© sur le systÃ¨me oÃ¹ les autotools
>sont appelÃ©s&nbsp;; 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&nbsp;: 
>
>
><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&nbsp;; 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&nbsp;; 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&nbsp;; 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 miroirs 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 appelÃ© 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 appelant 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
>appelÃ© 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'appeler 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 parce que 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="dÃ©pendre 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