Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 122528 Details for
Bug 182495
[fr] Automagic Dependancies
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
/proj/fr/qa/automagic.xml.patch
automagic.xml.patch (text/plain), 23.34 KB, created by
Camille Huot (RETIRED)
on 2007-06-19 16:36:27 UTC
(
hide
)
Description:
/proj/fr/qa/automagic.xml.patch
Filename:
MIME Type:
Creator:
Camille Huot (RETIRED)
Created:
2007-06-19 16:36:27 UTC
Size:
23.34 KB
patch
obsolete
>--- automagic.xml.orig 2007-06-19 14:08:58.000000000 +0200 >+++ automagic.xml 2007-06-19 18:30:39.000000000 +0200 >@@ -1,264 +1,254 @@ >-<?xml version="1.0" encoding="UTF-8"?> >-<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd"> >-<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/proj/en/qa/automagic.xml,v 1.2 2006/01/30 05:52:05 flameeyes Exp $ --> >- >-<guide link="/proj/en/qa/automagic.xml" lang="en"> >-<title>Les dépendances automagiques, ce qu'elles sont et comment les corriger</title> >- >-<author title="Author"> >- <mail link="flameeyes@gentoo.org">Diego Pettenò</mail> >-</author> >-<author title="Translator"> >- <mail link="nicolas@litchinko.fr">Nicolas Litchinko</mail> >-</author> >- >-<abstract> >-Ce guide a pour objectif de décrire le problème des «dépendances automagiques», >-la raison pour laquelle elles posent problème et comment les gérer dans les cas >-les plus courants. >-</abstract> >- >-<!-- The content of this document is licensed under the CC-BY-SA license --> >-<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> >-<license/> >- >-<version>0.1</version> >-<date>2006-01-30</date> >- >-<chapter> <!-- Introduction --> >-<title>Introduction</title> >- >-<section> >-<title>Qu'est-ce que les dépendances automagiques ?</title> >-<body> >- >-<p> >-Les fameuses <e>dépendances automagiques</e> sont des dépendances légères d'un >-logiciel qui ne sont reconnues qu'au moment de la compilation ou de l'exécution >-et qui influent sur le fonctionnement du logiciel. Le nom <e>automagique</e> >-est un jeu de mot en référence aux GNU autotools qui produisent le plus souvent >-des <e>dépendances automagiques</e>. >-</p> >- >-<p> >-Les logiciels ont en général deux catégories de dépendances : les >-dépendances indispensables et les dépendances optionnelles. La première >-catégorie de dépendance est requise pour l'utilisation du logiciel (cela peut >-être une bibliothèque ou une application) et elles ne peuvent manquer à l'appel >-lors de la compilation ou l'exécution du logiciel (selon leur type: dépendances >-de compilation ou d'exécution). Les dépendances optionnelles sont celles qui >-peuvent être désactivées, en général lors de la compilation (mais parfois aussi >-lors de l'exécution). >-</p> >- >-<p> >-Il revient souvent à l'utilisateur (ou à celui qui compile le logiciel) >-d'activer ou désactiver les dépendances optionnelles. L'exemple classique de ce >-cas sont les options <c>--enable-foo</c> ou <c>--with-bar</c> du script >-<c>./configure</c> (ces paramètres sont utilisés pour activer des dépendances >-qui sont désactivées par défaut, mais il y a également des cas pour lesquelles >-les dépendances sont activées par défault et il faut utiliser >-<c>--disable-foo</c> ou <c>--without-bar</c>) >-</p> >- >-<p> >-Cependant, avec des systèmes de compilation qui essaient de comprendre ce qui >-est présent sur le système qui sert à la compilation, il arrive que des >-dépendances deviennent <e>automagiques</e>. Cela signifie que le système de >-compilation ne demande pas à l'utilisateur s'il souhaite activer une option, >-et donc ajouter une dépendance, mais que la dépendance est activée si elle est >-détectée. Ce comportement est mauvais. >-</p> >- >-</body> >-</section> >- >-<section> <!-- Why automagic dependencies are wrong --> >-<title>Pourquoi les dépendances automagiques sont mauvaises</title> >- >-<body> >- >-<p> >-Dans le cas de distributions basées sur des binaires, comme celles basées sur >-RPM ou DEB, les dépendances automagiques ne changent rien : si >-l'utilisateur a quelque chose d'installé et compile à la main, c'est souvent ce >-qu'il veut activer l'option et s'il s'agit du mainteneur, il n'aura qu'à >-ajouter une dépendance sur les paquets requis pour exécuter les binaires qu'il >-a créé. >-</p> >- >-<p> >-Cela est différent pour les distributions basées sur les sources comme Gentoo >-Linux (et dérivés). Comme les distributions basées sur les sources ne séparent >-pas les paquets utilisateur et les paquets de développement, les systèmes de >-construction peuvent trouver plus que ce que l'utilisateur voudrait et vont >-essayer de se lier avec tout ce qu'ils connaissent. C'est la principale cause >-de cassure de liaison avec un depclean (NdT. nettoyage des dépendances non >-utilisées). >-</p> >- >-<p> >-Pour simplifier, lorsqu'une dépendance automagique n'est pas indiquée comme >-indispensable dans un ebuild mais qu'au lieu de cela il existe un mécanisme qui >-ajoute ou supprime la dépendance à un paquet donné, si le paquet est présent >-dans le système compilant le logiciel avec des dépendance automagiques et est >-ensuite supprimé, le logiciel cessera de fonctionner, nécessitant alors une >-exécution de <c>revdep-rebuild</c> pour corriger la liaison. Il est également >-possible qu'un utilisateur souhaite réellement désactiver une dépendance >-parce-qu'il sait qu'elle n'est pas stable ou parce qu'il crée un paquet binaire >-pour une autre machine sur laquelle la dépendance n'est peut-être pas installée >-(ou ne fonctionne même peut-être pas du tout). >-</p> >- >-<p> >-Lorsqu'un paquet a des dépendances automatiques il n'y a que deux choses qui >-peuvent être faites : la première est de déclarer la dépendance >-indispensable, sans considérer les choix fait par l'utilisateur dans la >-variable USE, mais cela peut signifier que le support de certaines >-fonctionnalités que certains utilisateurs ne souhaitent pas activer sera >-toujours présent et les dépendances seront toujours installées ; l'autre >-solution est de corriger le système de compilation pour être capable de >-désactiver la dépendance lors de la compilation même si elle est présente sur >-le système. >-</p> >- >-<p> >-La plupart du temps, les développeurs upstream (NdT. les développeurs du >-logiciel) ne pensent pas vraiment à ajouter la possibilité de désactiver les >-dépendances automagiques puisqu'ils ne le ressentent pas comme un véritable >-problème : ils les ont toutes d'installées, ou au moins celles dont ils >-ont besoin, et ils compilent en général avec toutes les options d'activées. >-Heureusement, la plupart des développeurs upstream acceptent d'ajouter des >-options pour désactiver ces dépendances si des correctifs sont fournis (parfois >-également sans correctifs, mais bien évidemment la demande sera mieux reçue si >-des correctifs sont déjà prêts). Ce n'est toutefois pas toujours le cas. Par >-exemple, les développeurs de Wine ne veulent pas ajouter la possibilité >-d'activer ou de désactiver des fonctionnalités lors de l'appel à >-<c>./configure</c> car ils désirent que leur logiciel utilise toujours le plus >-d'options possible. >-</p> >- >-</body> >- >-</section> >- >-</chapter> >- >-<chapter> <!-- Fixing automagic dependencies --> >-<title>Corriger les dépendances automagiques</title> >- >-<section> <!-- Autotools --> >-<title>Autotools</title> >- >-<body> >- >-<p> >-La majorité des dépendances automagiques, comme leur nom l'indique, sont due à >-un (mauvais) usage des GNU autotools (<c>autoconf</c> pour être exact). Il y a >-deux cas principaux dans lesquels des dépendances automagiques >-apparaissent : le premier est le cas des «développeurs paresseux» dans >-lequel les dépendances n'ont pas du tout de paramètre pour <c>./configure</c> >-et sont seulement vérifiées à l'aide de <b>AC_CHECK_LIB</b> ou la macro >-<b>PKG_CHECK_MODULE</b> de <c>pkg-config</c> qui permettent l'exécution de code >-spécifique lorsqu'une bibliothèque (ou un paquet) sont présent ou non ; >-l'autre cas est celui du «paramètre malicieux» dans lequel le paramètre >-<c>--disable-foo</c> ou <c>--without-bar</c> est accepté par <c>./configure</c> >-mais n'est pas correctement interprété. >-</p> >- >-<p> >-Le premier cas est facile à corriger, il n'y a qu'à ajouter un appel à >-<b>AC_ARG_WITH</b> (ou <b>AC_ARG_ENABLE</b>) et ensuite vérifier la valeur de >-la variable correspondante avant de faire le test. Il est utile de savoir que >-le premier paramètre passé à cette macro crée une variable qui est chargée par >-<c>autoconf</c> sans avoir à ajouter les autres paramètres qui déterminent >-l'action à effectuer lorsque le paramètre est présent et lorsqu'il ne l'est >-pas. Cette variable est appelée <path>$enable_foo</path> ou >-<path>$with_bar</path> en fonction de la macro utilisée. >-</p> >- >-<note> >-Pour que les correctifs soient acceptés par les développeurs upstream, il est >-en général suggéré de ne pas changer le comportement de <c>./configure</c> >-lorsqu'il est appelé sans paramètres ; c'est pourquoi nous allons vous >-présenter deux méthodes pour rendre les dépendances non-automagiques, une pour >-les dépendances activées par défaut et une autre pour les dépendances >-désactivées par défaut. >-</note> >- >-<pre caption="Ajouter une dépendance optionnelle activée par défaut"> >-<i>AC_ARG_WITH([foo], AS_HELP_STRING([--without-foo], [Build without foo library (default: test)]))</i> >- >-<i>if test "x$with_foo" != "xno"; then</i> >- PKG_CHECK_MODULES([FOO], [foo >= 0.1]) >-<i>fi</i> >-</pre> >- >-<pre caption="Ajouter une dépendance optionnelle désactiver par défaut"> >-<i>AC_ARG_WITH([foo], AS_HELP_STRING([--with-foo], [Build with foo library (default: disabled)]))</i> >- >-<i>if test "x$with_foo" == "xyes"; then</i> >- PKG_CHECK_MODULES([FOO], [foo >= 0.1]) >-<i>fi</i> >-</pre> >- >-<p> >-Lorsque le paramètre est présent mais n'est pas honoré, corriger le problème de >-dépendance peut aussi bien être simple que complexe. Il peut s'agir d'un test >-qui n'est pas correctement écrit, et dans ce cas il faut le modifier en quelque >-chose qui ressemble aux tests présentés précédemment, ou il peut s'agir d'un >-mélange complet des appels aux macros <b>AC_ARG_WITH</b>. Dans ces cas, il vaut >-mieux vérifier le code avec précaution et contacter les développeurs upstream >-s'il s'agit d'une erreur complexe. >-</p> >- >-<warn> >-Souvent (presque tout le temps lorsque le paquet utilise automake), les >-dépendances automagiques sont associées avec des appels à >-<b>AM_CONDITIONAL</b>. Il est très important que ces appels soient placés >-<e>hors</e> des blocs if/fi, ou alors les appels à <c>./configure</c> vont >-exploser. >-</warn> >- >-<p> >-Il y a en réalité une autre méthode pour contourner le problème, sans corriger >-(et patcher), les dépendances automagiques générées par <b>AC_CHECK_LIB</b> et >-c'est en jouant avec les valeurs mises en cache par <c>autoconf</c>. Cette >-méthode est en fait dépréciée parce-qu'elle ne règle pas la cause du problème >-et peut en créer d'autres si les développeurs upstream modifient légèrement les >-tests en utilisant un autre nom pour la variable mise en cache. De plus, de >-cette façon, les correctifs ne peuvent être envoyés aux développeurs upstream >-pour être intégrés dans les prochaines versions. >-</p> >- >-</body> >-</section> >- >-<section> <!-- Other build systems --> >-<title>Les autres systèmes de compilation</title> >- >-<body> >- >-<impo> >-Veuillez contribuer à ce guide ;) Des notes a propos d'autres systèmes de >-construction non-personnalisés comme <c>scons</c> sont les bienvenues. Si le >-système de construction peut définir des dépendances automagiques, il devrait >-également y avoir un moyen de les corriger. >-</impo> >- >-<p> >-Les dépendances automagiques peuvent également être créées par des systèmes de >-construction utilisés par certains logiciels. Malheureusement, du fait de leur >-personnalisation, ces systèmes de construction sont en général difficile à >-optimiser et il n'est pas possible de définir une méthode d'approche générale >-pour les corriger. >-</p> >- >-</body> >-</section> >- >-</chapter> >- >-</guide> >- >-<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; --> >+<?xml version="1.0" encoding="UTF-8"?> >+<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd"> >+<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/proj/en/qa/automagic.xml,v 1.2 2006/01/30 05:52:05 flameeyes Exp $ --> >+ >+<guide link="/proj/fr/qa/automagic.xml" lang="fr"> >+<title>Les dépendances automagiques, ce qu'elles sont et comment les corriger</title> >+ >+<author title="Auteur"> >+ <mail link="flameeyes@gentoo.org">Diego Pettenò</mail> >+</author> >+<author title="Traducteur"> >+ <mail link="nicolas@litchinko.fr">Nicolas Litchinko</mail> >+</author> >+ >+<abstract> >+Ce guide a pour objectif de décrire le problème des « dépendances automagiques », >+la raison pour laquelle elles posent problème et comment les gérer dans les cas >+les plus courants. >+</abstract> >+ >+<!-- The content of this document is licensed under the CC-BY-SA license --> >+<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> >+<license/> >+ >+<version>0.1</version> >+<date>2006-01-30</date> >+ >+<chapter> <!-- Introduction --> >+<title>Introduction</title> >+<section> >+<title>Qu'est-ce que les dépendances automagiques ?</title> >+<body> >+ >+<p> >+Les fameuses <e>dépendances automagiques</e> sont des dépendances légères d'un >+logiciel qui ne sont reconnues qu'au moment de la compilation ou de l'exécution >+et qui influent sur le fonctionnement du logiciel. Le nom <e>automagique</e> >+est un jeu de mot en référence aux GNU autotools qui produisent le plus souvent >+des <e>dépendances automagiques</e>. >+</p> >+ >+<p> >+Les logiciels ont en général deux catégories de dépendances : les >+dépendances indispensables et les dépendances optionnelles. La première >+catégorie de dépendance est requise pour l'utilisation du logiciel (cela peut >+être une bibliothèque ou une application) et elles ne peuvent manquer à l'appel >+lors de la compilation ou l'exécution du logiciel (selon leur type :: dépendances >+de compilation ou d'exécution). Les dépendances optionnelles sont celles qui >+peuvent être désactivées, en général lors de la compilation (mais parfois aussi >+lors de l'exécution). >+</p> >+ >+<p> >+Il revient souvent à l'utilisateur (ou à celui qui compile le logiciel) >+d'activer ou désactiver les dépendances optionnelles. L'exemple classique de ce >+cas sont les options <c>--enable-foo</c> ou <c>--with-bar</c> du script >+<c>./configure</c> (ces paramètres sont utilisés pour activer des dépendances >+qui sont désactivées par défaut, mais il y a également des cas pour lesquelles >+les dépendances sont activées par défaut et il faut donc utiliser >+<c>--disable-foo</c> ou <c>--without-bar</c>). >+</p> >+ >+<p> >+Cependant, avec des systèmes de compilation qui essaient de comprendre ce qui >+est présent sur le système qui sert à la compilation, il arrive que des >+dépendances deviennent <e>automagiques</e>. Cela signifie que le système de >+compilation ne demande pas à l'utilisateur s'il souhaite activer une option >+et donc ajouter une dépendance, mais que la dépendance est activée si elle est >+détectée. Ce comportement est mauvais. >+</p> >+ >+</body> >+</section> >+<section> <!-- Why automagic dependencies are wrong --> >+<title>Pourquoi les dépendances automagiques sont mauvaises</title> >+<body> >+ >+<p> >+Dans le cas de distributions basées sur des binaires, comme celles basées sur >+RPM ou DEB, les dépendances automagiques ne changent rien : si >+l'utilisateur a quelque chose d'installé et qu'il compile à la main, c'est souvent >+qu'il veut activer l'option et, s'il s'agit du mainteneur, il n'aura qu'à >+ajouter une dépendance sur les paquets requis pour exécuter les binaires qu'il >+a créés. >+</p> >+ >+<p> >+Cela est différent pour les distributions basées sur les sources comme Gentoo >+Linux (et dérivés). Comme les distributions basées sur les sources ne séparent >+pas les paquets pour l'utilisateur des paquets de développement, les systèmes de >+construction peuvent trouver plus que ce que l'utilisateur voudrait et vont >+essayer de se lier avec tout ce qu'ils connaissent. C'est la principale cause >+de cassure des liaisons après un depclean (N.d.T. : nettoyage des dépendances non >+utilisées). >+</p> >+ >+<p> >+Pour simplifier, lorsqu'une dépendance automagique n'est pas indiquée comme >+indispensable dans un ebuild, mais qu'au lieu de cela il existe un mécanisme qui >+ajoute ou supprime la dépendance d'un paquet donné, si le paquet est présent >+dans le système compilant le logiciel avec des dépendances automagiques et est >+ensuite supprimé, le logiciel cessera de fonctionner, nécessitant alors une >+exécution de <c>revdep-rebuild</c> pour corriger la liaison. Il est également >+possible qu'un utilisateur souhaite réellement désactiver une dépendance >+parce qu'il sait qu'elle n'est pas stable ou parce qu'il crée un paquet binaire >+pour une autre machine sur laquelle la dépendance n'est peut-être pas installée >+(ou ne fonctionne même peut-être pas du tout). >+</p> >+ >+<p> >+Lorsqu'un paquet a des dépendances automagiques, il n'y a que deux solutions : >+la première est de déclarer la dépendance comme étant >+indispensable, sans considérer les choix faits par l'utilisateur dans la >+variable USE, mais cela peut signifier que le support de certaines >+fonctionnalités que certains utilisateurs ne souhaitent pas activer sera >+toujours présent et les dépendances seront toujours installées ; l'autre >+solution est de corriger le système de compilation pour qu'il soit capable de >+désactiver la dépendance lors de la compilation même si elle est présente sur >+le système. >+</p> >+ >+<p> >+La plupart du temps, les développeurs upstream (N.d.T. : les développeurs du >+logiciel) ne pensent pas vraiment à ajouter la possibilité de désactiver les >+dépendances automagiques puisqu'ils ne le ressentent pas comme un véritable >+problème : ils les ont toutes d'installées, ou au moins celles dont ils >+ont besoin, et ils compilent en général avec toutes les options d'activées. >+Heureusement, la plupart des développeurs upstream acceptent d'ajouter des >+options pour désactiver ces dépendances si des correctifs sont fournis (parfois >+également sans correctif, mais bien évidemment la demande sera mieux reçue si >+des correctifs sont déjà prêts). Ce n'est toutefois pas toujours le cas. Par >+exemple, les développeurs de Wine ne veulent pas ajouter la possibilité >+d'activer ou de désactiver des fonctionnalités lors de l'appel à >+<c>./configure</c> car ils désirent que leur logiciel utilise toujours le plus >+d'options possible. >+</p> >+ >+</body> >+</section> >+</chapter> >+ >+<chapter> <!-- Fixing automagic dependencies --> >+<title>Corriger les dépendances automagiques</title> >+<section> <!-- Autotools --> >+<title>Autotools</title> >+<body> >+ >+<p> >+La majorité des dépendances automagiques, comme leur nom l'indique, sont dues à >+un (mauvais) usage des GNU autotools (<c>autoconf</c> pour être exact). Il y a >+deux cas principaux dans lesquels des dépendances automagiques >+apparaissent : le premier est le cas des « développeurs paresseux », dans >+lequel les dépendances n'ont pas du tout de paramètre pour <c>./configure</c> >+et sont seulement vérifiées à l'aide de <b>AC_CHECK_LIB</b> ou la macro >+<b>PKG_CHECK_MODULE</b> de <c>pkg-config</c>, qui permettent l'exécution de code >+spécifique lorsqu'une bibliothèque ou un paquet sont présents ou non ; >+l'autre cas est celui du « paramètre malicieux » dans lequel les paramètres >+<c>--disable-foo</c> ou <c>--without-bar</c> sont acceptés par <c>./configure</c> >+mais ne sont pas correctement interprétés. >+</p> >+ >+<p> >+Le premier cas est facile à corriger, il n'y a qu'à ajouter un appel à >+<b>AC_ARG_WITH</b> (ou <b>AC_ARG_ENABLE</b>) et ensuite vérifier la valeur de >+la variable correspondante avant de faire le test. Il est utile de savoir que >+le premier paramètre passé à cette macro crée une variable qui est chargée par >+<c>autoconf</c> sans avoir à ajouter les autres paramètres qui déterminent >+l'action à effectuer lorsque le paramètre est présent et lorsqu'il ne l'est >+pas. Cette variable est appelée <path>$enable_foo</path> ou >+<path>$with_bar</path> en fonction de la macro utilisée. >+</p> >+ >+<note> >+Pour que les correctifs soient acceptés par les développeurs upstream, il est >+en général suggéré de ne pas changer le comportement de <c>./configure</c> >+lorsqu'il est appelé sans paramètre ; c'est pourquoi nous allons vous >+présenter deux méthodes pour rendre les dépendances non-automagiques, une pour >+les dépendances activées par défaut et une autre pour les dépendances >+désactivées par défaut. >+</note> >+ >+<pre caption="Ajouter une dépendance optionnelle activée par défaut"> >+<i>AC_ARG_WITH([foo], AS_HELP_STRING([--without-foo], [Build without foo library (default: test)]))</i> >+ >+<i>if test "x$with_foo" != "xno"; then</i> >+ PKG_CHECK_MODULES([FOO], [foo >= 0.1]) >+<i>fi</i> >+</pre> >+ >+<pre caption="Ajouter une dépendance optionnelle désactivée par défaut"> >+<i>AC_ARG_WITH([foo], AS_HELP_STRING([--with-foo], [Build with foo library (default: disabled)]))</i> >+ >+<i>if test "x$with_foo" == "xyes"; then</i> >+ PKG_CHECK_MODULES([FOO], [foo >= 0.1]) >+<i>fi</i> >+</pre> >+ >+<p> >+Lorsque le paramètre est présent mais n'est pas honoré, corriger le problème de >+dépendance peut aussi bien être simple que complexe. Il peut s'agir d'un test >+qui n'est pas correctement écrit, et dans ce cas il faut le modifier en quelque >+chose qui ressemble aux tests présentés précédemment, ou il peut s'agir d'un >+mélange complet des appels aux macros <b>AC_ARG_WITH</b>. Dans ces cas, il vaut >+mieux vérifier le code avec précaution et contacter les développeurs upstream >+s'il s'agit d'une erreur complexe. >+</p> >+ >+<warn> >+Souvent (presque tout le temps lorsque le paquet utilise automake), les >+dépendances automagiques sont associées à des appels à >+<b>AM_CONDITIONAL</b>. Il est très important que ces appels soient placés >+<e>hors</e> des blocs if/fi, ou alors les appels à <c>./configure</c> vont >+exploser. >+</warn> >+ >+<p> >+Il y a en réalité une autre méthode, sans correction, pour contourner le problème >+des dépendances automagiques générées par <b>AC_CHECK_LIB</b> et >+c'est en jouant avec les valeurs mises en cache par <c>autoconf</c>. Cette >+méthode est en fait dépréciée parce qu'elle ne règle pas la cause du problème >+et peut en créer d'autres si les développeurs upstream modifient légèrement les >+tests en utilisant un autre nom pour la variable mise en cache. De plus, de >+cette façon, les correctifs ne peuvent être envoyés aux développeurs upstream >+pour être intégrés dans les prochaines versions. >+</p> >+ >+</body> >+</section> >+ >+<section> <!-- Other build systems --> >+<title>Les autres systèmes de compilation</title> >+<body> >+ >+<impo> >+Veuillez contribuer à ce guide ;) Des notes à propos d'autres systèmes de >+construction non-personnalisés comme <c>scons</c> sont les bienvenues. Si le >+système de construction peut définir des dépendances automagiques, il devrait >+également y avoir un moyen de les corriger. >+</impo> >+ >+<p> >+Les dépendances automagiques peuvent également être créées par des systèmes de >+construction utilisés par certains logiciels. Malheureusement, du fait de leur >+personnalisation, ces systèmes de construction sont en général difficiles à >+optimiser et il n'est pas possible de définir une méthode d'approche générale >+pour les corriger. >+</p> >+ >+</body> >+</section> >+</chapter> >+</guide> >+ >+<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; -->
<b>You cannot view the attachment while viewing its details because your browser does not support IFRAMEs. <a href="attachment.cgi?id=122528">View the attachment on a separate page</a>.</b>
View Attachment As Raw
Actions:
View
Attachments on
bug 182495
:
122429
|
122528
|
122530
