<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!--*- mode: nxml -*-->
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- process to HTML with: xmlto xhtml-nochunks -m ../custom.xsl index.docbook -->
<article id="index" lang="fr">
  <articleinfo>
    <title>Manuel de JHBuild</title>
    <authorgroup>
      <author role="maintainer">
        <firstname>James</firstname>
        <surname>Henstridge</surname>
      </author>
      <author>
        <firstname>C.J.</firstname>
        <surname>Adams-Collier</surname>
      </author>
      <author>
        <firstname>Frederic</firstname>
        <surname>Peters</surname>
      </author>
      <author>
        <firstname>David</firstname>
        <surname>Turner</surname>
      </author>
    </authorgroup>
    <copyright>
      <year>2004, 2008</year>
      <holder>James Henstridge</holder>
    </copyright>
    <revhistory>
      <revision>
        <revnumber>JHBuild Manual v0.5</revnumber>
        <date>January 2008</date>
      </revision>
      <revision>
        <revnumber>JHBuild Manual v0.1</revnumber>
        <date>August 2007</date>
      </revision>
    </revhistory>
    <abstract role="description">
      <para>JHBuild est un outil utilisé pour compiler l'ensemble du bureau GNOME à partir du gestionnaire de versions. Il peut aussi être configuré pour compiler d'autres projets.</para>
    </abstract>
  </articleinfo>

  <section id="introduction">
    <title>Introduction</title>

    <para>JHBuild est un outil conçu pour faciliter la compilation d'ensembles de paquets source, appelés <quote>modules</quote>. Il utilise des fichiers de « jeux de modules » (moduleset) pour décrire les modules disponibles pour la compilation. Ces fichiers contiennent des informations sur les dépendances, ce qui permet à JHBuild de déterminer les modules à compiler et dans quel ordre.</para>

    <para>JHBuild a été d'abord créé pour compiler <ulink url="http://www.gnome.org">GNOME</ulink>, mais il a été complété depuis pour être utilisable par d'autres projets. Un fichier jeux de modules (moduleset) peut se trouver sur un serveur Web, permettant ainsi de fournir des règles de compilation indépendamment du projet JHBuild.</para>

    <para>JHBuild can build modules from a variety of sources, including
      <ulink url="http://www.cvshome.org/">CVS</ulink>,
      <ulink url="http://subversion.tigris.org/">Subversion</ulink>,
      <ulink url="http://www.bazaar-vcs.org/">Bazaar</ulink>,
      <ulink url="http://darcs.net/">Darcs</ulink>,
      <ulink url="http://git.or.cz/">Git</ulink> and
      <ulink url="http://www.selenic.com/mercurial/">Mercurial</ulink>
      repositories, as well as Tar and Zip archives hosted on web or FTP sites.
      JHBuild can build modules using a variety of build systems, including
      Autotools, CMake, WAF, Python Distutils and Perl Makefiles.</para>

    <para>JHBuild n'est pas destiné à remplacer le système de gestion de paquets d'une distribution. Au contraire, il simplifie la compilation de logiciels à l'intérieur d'un préfixe d'installation distinct afin de ne pas interférer avec le reste du système.</para>
  </section>

  <section id="getting-started">
    <title>Premiers pas</title>

    <para>Quelques manipulations sont nécessaires pour configurer JHBuild avant de pouvoir compiler des logiciels. Certains logiciels sont nécessaires au fonctionnement de JHBuild, et il est aussi nécessaire d'installer des outils indispensables à l'obtention et à la construction des sources de logiciels.</para>

    <section id="getting-started-install">
      <title>Installation de JHBuild</title>

      <para>JHBuild nécessite un moteur d'exécution Python. Vérifiez que Python &gt;= 2.3 est installé.</para>

      <para>La façon recommandée de télécharger JHBuild est d'utiliser le gestionnaire de versions <command>git</command>. La commande à utiliser est présentée ci-dessous. Il est recommandé d'exécuter cette commande dans un nouveau répertoire où tout le code source sera téléchargé, par exemple <filename>~/checkout/gnome</filename>).</para>

<screen><prompt>$</prompt> <userinput>git clone git://git.gnome.org/jhbuild</userinput>
<computeroutput>...</computeroutput>
<prompt>$</prompt></screen>

      <para>Cela va télécharger JHBuild dans un nouveau dossier nommé <filename>jhbuild</filename> dans le répertoire actuel. Ensuite, pour le construire et l'installer :</para>

<screen><prompt>$</prompt> <userinput>cd jhbuild</userinput>
<prompt>$</prompt> <userinput>./autogen.sh</userinput>
<computeroutput>...</computeroutput>
<prompt>$</prompt> <userinput>make</userinput>
<computeroutput>...</computeroutput>
<prompt>$</prompt> <userinput>make install</userinput>
<computeroutput>...</computeroutput>
<prompt>$</prompt></screen>

      <para>If <application>gnome-common</application>,
        <application>yelp-tools</application> and
        <application>autotools</application> are available,
        <filename>autogen.sh</filename> will configure JHBuild to install via
        <application>autotools</application>. If
        <application>gnome-common</application>,
        <application>yelp-tools</application> and
        <application>autotools</application> are not available,
        <filename>autogen.sh</filename> will configure JHBuild to install via a
        plain Makefile. To always use the plain Makefile method pass
        <option>--simple-install</option> to <filename>autogen.sh</filename>.
      </para>

      <para>Si les étapes ci-dessus se sont déroulées avec succès, un petit script shell sera installé dans <filename>~/.local/bin</filename> pour lancer JHBuild. Ajoutez ce chemin dans votre variable <envar>PATH</envar> :</para>

<screen><prompt>$</prompt> <userinput>PATH=$PATH:~/.local/bin</userinput>
<prompt>$</prompt></screen>

      <para>Pour ajouter <filename>~/.local/bin</filename> de façon permanente à la variable <envar>PATH</envar>, exécutez la commande suivante :</para>

<screen>
<prompt>$</prompt> <userinput>echo PATH=$PATH:~/.local/bin &gt;&gt; ~/.bashrc</userinput>
<prompt>$</prompt></screen>

      <para>Avant de lancer JHBuild, il est nécessaire de paramétrer le fichier de configuration <filename>~/.jhbuildrc</filename>.</para>
    </section>

    <section id="getting-started-configure">
      <title>Configuration de JHBuild</title>

      <para>The <filename>~/.jhbuildrc</filename> file uses Python syntax to
        set configuration variables for JHBuild. An example is provided with
        JHBuild, see <filename>examples/sample.jhbuildrc</filename>. Copy
        <filename>examples/sample.jhbuildrc</filename> to
        <filename>~/.jhbuildrc</filename> and customize as required.</para>

      <para>The sample configuration will make JHBuild build the
        <application>meta-gnome-core</application> and
        <application>meta-gnome-apps-tested</application> modules and
        dependencies from the <systemitem>gnome-apps</systemitem> module
        set. JHBuild will unpack source trees to
        <filename>~/checkout/gnome</filename> and install all files to
        subdirectories of <filename>/opt/gnome</filename>. The two directories
        must be writable.</para>

      <para>Les variables de configuration sont documentées dans <xref linkend="config-reference"/>. En voici quelques-unes parmi les plus utilisées :</para>

      <variablelist>
<?dbhtml list-presentation="table"?>
        <varlistentry>
          <term>
            <link linkend="cfg-repos"><varname>repos</varname></link>
          </term>
          <listitem>
            <simpara>Un dictionnaire pouvant être utilisé pour indiquer un emplacement de dépôt alternatif pour un dépôt spécifique. Cette variable de configuration est utile pour les développeurs de modules. Par défaut, JHBuild extrait le code dans les dépôts par un accès anonyme. Les clés du dictionnaire sont des noms de dépôts courts et les valeurs sont des chaînes d'accès à des emplacements de dépôts alternatifs. Par exemple :</simpara>

<programlisting>repos['git.gnome.org'] = 'ssh://<replaceable>nom_utilisateur</replaceable>@git.gnome.org/git/'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <link linkend="cfg-moduleset"><varname>moduleset</varname></link>
          </term>
          <listitem>
            <simpara>Une chaîne ou une liste de chaînes indiquant le ou les noms des jeux de modules à utiliser. Cela peut être le nom de fichier d'un jeu de modules inclus dans JHBuild (sans chemin ni extension) ou un URL HTTP complet d'un jeu de modules géré en externe. Les jeux de modules ayant un URL HTTP sont placés dans un cache local. Si le nom d'un module figure dans plus d'un jeu de modules, le dernier jeu de modules dans la liste est prioritaire. Les jeux de modules fournis avec JHBuild sont mis à jour au gré de la progression du développement de GNOME.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <link linkend="cfg-modules"><varname>modules</varname></link>
          </term>
          <listitem>
            <simpara>A list of strings specifying the modules to build. The
              list of modules actually built will be recursively expanded to
              include all the dependencies unless the
              <link linkend="command-reference-buildone">
              <command>buildone</command></link> command is used. Defaults to
              <literal>['meta-gnome-desktop']</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <link linkend="cfg-checkoutroot"><varname>checkoutroot</varname></link>
          </term>
          <listitem>
            <simpara>A string specifying the directory to unpack source trees
              to. Unless <link linkend="cfg-buildroot">
              <varname>buildroot</varname></link> is set, builds will occur in
              this directory too. Defaults to
              <filename>~/checkout/gnome</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <link linkend="cfg-prefix"><varname>prefix</varname></link>
          </term>
          <listitem>
            <simpara>A string specifying the prefix to install modules to.
              <varname>prefix</varname> must be an absolute path. This directory
              must be writable. Defaults to <literal>'/opt/gnome'</literal>.
            </simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <link linkend="cfg-autogenargs"><varname>autogenargs</varname></link>
          </term>
          <listitem>
            <simpara>A string containing arguments passed to the
              <command>autogen.sh</command> script of all modules. Can be
              overridden for particular modules using the
              <link linkend="cfg-module-autogenargs">
              <varname>module_autogenargs</varname></link> dictionary.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <link linkend="cfg-makeargs"><varname>makeargs</varname></link>
          </term>
          <listitem>
            <simpara>Une chaîne énumérant des paramètres supplémentaires à passer à <command>make</command>. La valeur par défaut est <literal>''</literal>.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="getting-started-bootstrap">
      <title>Prérequis pour la construction</title>

      <para>Before any modules can be built, it is necessary to have certain
        build tools installed. Common build tools include the GNU Autotools
        (<application>autoconf</application>,
        <application>automake</application>, <application>libtool</application>
        and <application>gettext</application>), The GNU Toolchain
        (<application>binutils</application>, <application>gcc</application>,
        <application>g++</application>), make, pkg-config and Python, depending
        on which modules will be built.</para>

      <para>JHBuild peut vérifier si ces outils sont installés sur votre système à l'aide de la commande <command>sanitycheck</command> :</para>

<screen><prompt>$</prompt> <userinput>jhbuild sanitycheck</userinput></screen>

      <para>Si cette commande affiche un message, il est possible de corriger les erreurs de deux manières :</para>

      <orderedlist>
        <listitem>
          <simpara>Installez le paquet requis à partir du dépôt de votre distribution. Une liste de <ulink url="http://live.gnome.org/JhbuildDependencies">noms de paquets</ulink> de différentes distributions est disponible sur le wiki de GNOME. Exécutez à nouveau la commande <command>sanitycheck</command> après avoir installé les paquets de la distribution pour s'assurer que les outils requis sont maintenant présents.</simpara>
        </listitem>
        <listitem>
          <simpara>Lancez la commande <command>bootstrap</command> pour télécharger, compiler et installer les prérequis de construction :</simpara>

<screen><prompt>$</prompt> <userinput>jhbuild bootstrap</userinput></screen>

          <para>Lorsque l'opération est terminée, lancez la commande <command>sanitycheck</command> pour vérifier que les outils requis sont présents.</para>

          <note>
            <para>La commande <command>bootstrap</command> ne construit pas toutes les dépendances des paquets requis par les outils de construction. Si votre distribution ne fournit pas ces paquets, ils devront alors être construits en dehors de l'environnement JHBuild.</para>

            <para>Les dépendances des outils de construction comprennent notamment <application>m4</application>, <application>perl</application> et un compilateur C (par exemple <application>gcc</application>).</para>
          </note>
        </listitem>
      </orderedlist>
    </section>

    <section id="getting-started-use">
      <title>Utilisation de JHBuild</title>

      <para>Après que tout a été configuré, JHBuild peut se mettre à construire des logiciels. Pour construire tous les modules indiqués dans le fichier <filename>~/.jhbuildrc</filename>, exécutez la commande suivante :</para>

<screen><prompt>$</prompt> <userinput>jhbuild build</userinput></screen>

      <para>JHBuild va télécharger, configurer, compiler et installer chaque module. Si une erreur se produit à n'importe quelle étape, JHBuild présente un menu pour savoir ce qu'il doit faire. Les choix possibles comprennent le passage dans un shell pour corriger l'erreur, une nouvelle passe de construction à différentes étapes, l'abandon de la construction du module ou la non prise en compte de l'erreur en continuant le processus.</para>

      <note>
        <simpara>L'abandon d'un module provoque l'échec de construction de tout module dépendant de ce module.</simpara>
      </note>

      <para>Voici un exemple de menu qui est affiché :</para>

<screen>  [1] Rerun phase build
  [2] Ignore error and continue to install
  [3] Give up on module
  [4] Start shell
  [5] Reload configuration
  [6] Go to phase "wipe directory and start over"
  [7] Go to phase "configure"
  [8] Go to phase "clean"
  [9] Go to phase "distclean"
<prompt>choice:</prompt> </screen>

      <para>Il est aussi possible de construire un jeu différent de modules (et leurs dépendances) en passant les noms des modules en paramètre de la commande <command>build</command>. Par exemple, pour construire gtk+ :</para>

<screen><prompt>$</prompt> <userinput>jhbuild build gtk+</userinput></screen>

      <para>Si JHBuild est interrompu en cours de construction d'un module, quelle qu'en soit la raison, il est possible de reprendre la construction à partir d'un module précis en utilisant l'option <option>--start-at</option> :</para>

<screen><prompt>$</prompt> <userinput>jhbuild build --start-at=pango</userinput></screen>

      <para>Pour construire un ou plusieurs modules en ignorant leurs dépendances, JHBuild fournit la commande <command>buildone</command>. Pour que cette commande se déroule correctement, toutes les dépendances du module indiqué doivent être préalablement construites et installées, ou fournies par des paquets de votre distribution.</para>

<screen><prompt>$</prompt> <userinput>jhbuild buildone gtk+</userinput></screen>

      <para>When actively developing a module, you are likely in a source
        working directory. The <command>make</command> will invoke the build
        system and install the module. This will be a key part of your
        edit-compile-install-test cycle.</para>

<screen><prompt>$</prompt> <userinput>jhbuild make</userinput></screen>

      <para>Si JHBuild est interrompu en cours de construction d'un module, quelle qu'en soit la raison, il est possible de reprendre la construction à partir d'un module précis en utilisant l'option <option>--start-at</option> :</para>

      <para>Pour obtenir une liste ordonnancée des modules et des dépendances que JHBuild va construire, utilisez la commande <command>list</command> :</para>

<screen><prompt>$</prompt> <userinput>jhbuild list</userinput></screen>

      <para>Pour obtenir des informations sur un module particulier, utilisez la commande <command>info</command> :</para>

<screen><prompt>$</prompt> <userinput>jhbuild info gtk+</userinput></screen>

      <para>Pour télécharger ou mettre à jour toutes les sources de logiciels sans rien compiler, utilisez la commande <command>update</command>. Cette commande donne l'occasion de modifier les sources avant la compilation et peut se révéler utile quand la disponibilité de bande passante Internet est instable.</para>

<screen><prompt>$</prompt> <userinput>jhbuild update</userinput></screen>

      <para>Plus tard, JHBuild peut tout construire sans télécharger ni mettre à jour les sources :</para>

<screen><prompt>$</prompt> <userinput>jhbuild build --no-network</userinput></screen>

      <para>Pour lancer une commande précise dans le même environnement utilisé par JHBuild, utilisez la commande <command>run</command> :</para>

<screen><prompt>$</prompt> <userinput>jhbuild run <replaceable>program</replaceable></userinput></screen>

      <para>Pour lancer un shell avec l'environnement utilisé par JHBuild, utilisez la commande <command>shell</command> :</para>

<screen><prompt>$</prompt> <userinput>jhbuild shell</userinput></screen>
    </section>
  </section>

  <section id="jhbuild-and-gnome">
    <title>JHBuild et GNOME</title>

    <para>Cette section fournit des indications sur la compilation, l'installation et le fonctionnement de GNOME.</para>

    <section id="building-gnome">
      <title>Construction de GNOME</title>

      <para>Pour compiler GNOME, certains paquets de développement sont nécessaires, notamment :</para>

      <itemizedlist>
        <listitem>
          <simpara>La DTD DocBook XML et les feuilles de styles XSLT. Elles doivent être enregistrées dans le catalogue XML (<filename>/etc/xml/catalog</filename>).</simpara>
        </listitem>
        <listitem>
          <simpara>Les bibliothèques X</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libsmbclient</filename> de Samba (utilisé pour parcourir les réseaux Windows).</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libbz2</filename> de bzip2.</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libpng</filename>, <filename>libjpeg</filename> et <filename>libtiff</filename> (utilisés pour le chargement d'images).</simpara>
        </listitem>
      </itemizedlist>

      <para>Si vous installez des paquets de votre distribution et si cela s'applique à votre distribution, installez les paquets <quote>dev</quote> ou <quote>devel</quote> correspondants. Une liste de <ulink url="http://live.gnome.org/JhbuildDependencies">noms de paquets</ulink> de différentes distributions est disponible sur le wiki de GNOME.</para>
    </section>

    <section id="running-single-application">
      <title>Lancement d'une application GNOME unique</title>

      <para>Cette section décrit comment lancer une seule application GNOME. L'application se lance dans l'environnement de bureau actuel. Pour lancer une application dans le contexte d'un GNOME JHBuild complet, consultez <xref linkend="running-gnome"/>.</para>

      <para>Exécutez un shell JHBuild. Ce shell dispose de toutes les variables d'environnement nécessaires déjà configurées.</para>

<screen><prompt>$ </prompt><userinput>jhbuild shell</userinput></screen>

      <para>Vérifiez que la bonne application va être lancée. Par exemple :</para>

<screen><prompt>$ </prompt><userinput>which gedit</userinput>
/opt/gnome/bin/gedit</screen>

      <para>lancez l'application :</para>

<screen><prompt>$ </prompt><userinput>gedit &amp;</userinput></screen>

      <para>Il est aussi possible de lancer l'application en utilisant la commande <command>run</command> :</para>

<screen><prompt>$ </prompt><userinput>jhbuild run gedit</userinput></screen>
    </section>

    <section id="running-gnome">
      <title>Lancement de l'environnement de bureau GNOME</title>

      <para>Créez un nouveau compte utilisateur pour faire fonctionner le GNOME JHBuild. Il est recommandé d'utiliser un compte utilisateur différent pour GNOME JHBuild, afin d'éviter des problèmes liés aux paramètres utilisateur stockés dans le dossier personnel. Ce manuel fait référence à ce nouveau compte par le nom  <systemitem class="username">gnomedev</systemitem>.</para>

      <para>Configurez JHBuild dans le nouveau compte <systemitem class="username">gnomedev</systemitem>. Copiez ou créez un lien symbolique pour <filename>~/.jhbuildrc</filename> et <filename>~/.local/bin/jhbuild</filename> dans le dossier personnel de <systemitem class="username">gnomedev</systemitem>.</para>

      <para>Ouvrez un terminal en tant qu'utilisateur <systemitem class="username">gnomedev</systemitem>. Ajoutez <filename>~/.local/bin</filename> de façon permanente à la variable <envar>PATH</envar> en exécutant la commande suivante :</para>

<screen><prompt>$</prompt> <userinput>echo PATH=$PATH:~/.local/bin &gt;&gt; ~/.bashrc</userinput></screen>

      <para>Testez que JHBuild fonctionne :</para>

<screen><prompt>$</prompt> <userinput>jhbuild run pkg-config gtk+-2.0 --modversion</userinput>
2.20.1</screen>

      <section>
        <title>Configuration de GNOME en mode « gestionnaire d'affichage »</title>

        <para>Compilez et installez GNOME JHBuild.</para>

        <para>Activez les services système. GNOME JHBuild utilise le démon <application>D-Bus</application> système <filename>/usr/bin</filename> et les services système dans <filename>/usr/share/dbus-1/system-services/</filename>. GNOME JHBuild utilise le démon <application>D-Bus</application> de session et les services dans <filename><replaceable>/opt/gnome/</replaceable>share/dbus-1/services/</filename>. Remplacez <filename>/opt/gnome</filename> par le préfixe d'installation de GNOME dans la commande ci-après :</para>

<screen><prompt>$ </prompt><userinput>rm -rf <replaceable>/opt/gnome</replaceable>/var/run/dbus</userinput>
<prompt>$ </prompt><userinput>ln -s /var/run/dbus <replaceable>/opt/gnome</replaceable>/var/run/dbus</userinput>
<prompt>$ </prompt><userinput>rm -rf <replaceable>/opt/gnome</replaceable>/var/lib/dbus/machine-id</userinput>
<prompt>$ </prompt><userinput>ln -s /var/lib/dbus/machine-id <replaceable>/opt/gnome</replaceable>/var/lib/dbus/machine-id</userinput></screen>

        <para>Créez un script de démarrage GNOME dans <filename>/usr/bin/gnome-jhbuild-session</filename> contenant le texte suivant, en remplaçant <filename>/opt/gnome</filename> par le préfixe d'installation de GNOME :</para>

<programlisting>#!/bin/sh

GNOME=<replaceable>/opt/gnome</replaceable>
 
GDK_USE_XFT=1
XDG_DATA_DIRS=$XDG_DATA_DIRS:$GNOME/share
XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:$GNOME/etc/xdg

jhbuild run gnome-session
</programlisting>

        <para>Rendez exécutable le fichier <filename>/usr/bin/gnome-jhbuild-session</filename> :</para>

<screen><prompt>$ </prompt><userinput>chmod a+x /usr/bin/gnome-jhbuild-session</userinput></screen>

        <para>Pour ajouter une nouvelle entrée de session dans le gestionnaire d'affichage, créez le fichier <filename>/usr/share/xsessions/gnome-jhbuild.desktop</filename> avec un contenu semblable à ceci :</para>

<programlisting>[Desktop Entry]
Name=GNOME (JHBuild)
Comment=Cette session vous connecte dans une session GNOME de test
Exec=/usr/bin/gnome-jhbuild-session
Icon=
Type=Application</programlisting>

        <para>Redémarrez <command>gdm</command>.</para>

        <para/>
      </section>

      <section>
        <title>Lancement de GNOME depuis le gestionnaire d'affichage</title>

        <para>Pour lancer GNOME JHBuild, sélectionnez la session GNOME (JHBuild) dans l'écran de bienvenue du gestionnaire d'affichage, avant de saisir les informations de connexion du compte <systemitem class="username">gnomedev</systemitem>. Si tout fonctionne correctement, GNOME JHBuild va apparaître. Sinon, inspectez le journal dans le fichier <filename>~gnomedev/.xsession-errors</filename>.</para>
      </section>
    </section>
  </section>

  <section id="buildbot-integration">
    <title>Intégration à un robot de compilation (buildbot)</title>

    <para>Associé au projet <ulink url="http://buildbot.net">Buildbot</ulink>, JHBuild peut aussi fonctionner comme outil d'intégration continue. Le projet GNOME utilise une configuration Buildbot sur <ulink url="http://build.gnome.org">build.gnome.org</ulink>.</para>

    <section id="buildbot-slave">
      <title>Configuration d'un esclave de robot de compilation</title>

      <para>Un esclave de robot de compilation est une variante d'une installation JHBuild normale qui va servir les requêtes d'un maître de compilation. Il est conseillé de d'abord faire fonctionner JHBuild correctement en effectuant une compilation complète et réussie de la majorité des modules avant de le configurer en tant que robot de compilation.</para>

      <para>Les commandes des robots de compilation sont des options de la commande <command>bot</command>. Pour télécharger et installer les logiciels supplémentaires requis, exécutez la commande suivante :</para>

<screen><prompt>$</prompt> <userinput>jhbuild bot --setup</userinput></screen>

      <para>Après l'exécution réussie de cette étape, trois nouvelles variables de configuration sont nécessaires dans <filename>~/.jhbuildrc</filename>.</para>

      <note>
        <para>Il n'est pas possible d'utiliser un fichier de configuration différent, l'option <link linkend="option-file"><option>--file</option></link> ne produira pas l'effet désiré.</para>
      </note>

<programlisting>
jhbuildbot_master = 'build.gnome.org:9070'
jhbuildbot_slavename = 'nom_esclave'
jhbuildbot_password = 'mot_de_passe'
</programlisting>

      <para><varname>jhbuildbot_master</varname> est une chaîne indiquant le serveur maître du robot de compilation. Par défaut, c'est <literal>'build.gnome.org:9070'</literal>. <varname>jhbuildbot_slavename</varname> et <varname>jhbuildbot_password</varname> permettent d'identifier l'esclave sur le serveur maître. Contactez les administrateurs du robot maître pour obtenir les nom d'utilisateur et mot de passe de l'esclave.</para>

      <note>
        <para>Les administrateurs de <ulink url="http://build.gnome.org">build.gnome.org</ulink> peuvent être contactés via la <ulink url="mailto:build-brigade-list@gnome.org">liste de diffusion de l'équipe de compilation</ulink>.</para>
      </note>
    </section>

<!-- TODO: configuring a buildbot master
    <section id="buildbot-master">
      <title>Configuring a Buildbot Master</title>
    </section>
    -->
  </section>

  <section id="command-reference">
    <title>Référence des commandes</title>

    <para>JHBuild utilise une syntaxe de ligne de commande similaire aux outils du style CVS :</para>

    <cmdsynopsis><command>jhbuild</command>
      <arg><replaceable>global-options</replaceable></arg>
      <arg choice="plain"><replaceable>command</replaceable></arg>
      <arg><replaceable>command-arguments</replaceable></arg>
    </cmdsynopsis>

    <para>Les options globales de JHBuild sont :</para>

    <variablelist>
      <varlistentry>
        <term id="option-file">
          <option>-f</option>, <option>--file</option>
          <replaceable>config</replaceable>
        </term>
        <listitem>
          <simpara>Utilise un fichier de configuration alternatif au lieu du fichier <filename>~/.jhbuildrc</filename> par défaut.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>
          <option>-m</option>, <option>--moduleset</option>
          <replaceable>moduleset</replaceable>
        </term>
        <listitem>
          <simpara>Utilise un autre jeu de modules que celui qui est indiqué dans le fichier de configuration. Cette option peut être un chemin relatif si le jeu de modules se trouve dans le dossier des jeux de modules de JHBuild, ou un chemin absolu s'il se trouve ailleurs.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>
          <option>--no-interact</option>
        </term>
        <listitem>
          <simpara>N'interroge jamais l'utilisateur quant à un choix à faire. Cette option est utile pour effectuer une construction sans intervention humaine, afin de s'assurer que la construction ne soit pas interrompue.</simpara>
        </listitem>
      </varlistentry>
    </variablelist>

    <para>Les options particulières à certaines commandes sont énumérées ci-dessous.</para>

    <section id="command-reference-autobuild">
      <title>autobuild</title>

      <para>La commande <command>autobuild</command> construit automatiquement les modules indiqués dans le fichier de configuration, puis envoie les résultats vers JHAutobuild.</para>

      <cmdsynopsis><command>jhbuild autobuild</command>
        <arg>--autogen</arg>
        <arg>--clean</arg>
        <arg>--distcheck</arg>
        <arg rep="repeat">--skip=<replaceable>module</replaceable></arg>
        <arg>--start-at=<replaceable>module</replaceable></arg>
        <arg>--report-url=<replaceable>reporturl</replaceable></arg>
        <arg>--verbose</arg>
      </cmdsynopsis>

      <para>The <option>--autogen</option>, <option>--clean</option>,
        <option>--distcheck</option>, <option>--skip</option> and
        <option>--start-at</option> options are processed as per the
        <link linkend="command-reference-build"><command>build</command></link>
        command.</para>

      <variablelist>
        <varlistentry>
          <term><option>--report-url=<replaceable>url-de-rapport</replaceable></option>, <option>-r <replaceable>url-de-rapport</replaceable></option></term>
          <listitem>
            <simpara>Cette option indique l'URL de JhAutobuild où envoyer le rapport.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--verbose</option>, <option>-v</option></term>
          <listitem>
            <simpara>Si indiquée, cette option produit des messages de JHBuild plus verbeux.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="command-reference-bootstrap">
      <title>bootstrap</title>

      <para>La commande <command>bootstrap</command> installe un ensemble d'utilitaires de construction requis pour la plupart des modules (par ex. <application>autoconf</application>, <application>automake</application>, etc).</para>

      <cmdsynopsis><command>jhbuild bootstrap</command>
      </cmdsynopsis>

      <para>La commande <command>bootstrap</command> construit les modules avec la même méthode que la commande <command>build</command>, mais en utilisant le jeu de modules <filename>bootstrap.modules</filename>.</para>

      <para>Consultez la documentation de la commande <link linkend="command-reference-build"><command>build</command></link> pour connaître les options disponibles.</para>
    </section>

    <section id="command-reference-build">
      <title>build</title>

      <para>La commande <command>build</command> construit un ou plusieurs paquets ainsi que leurs dépendances.</para>

      <cmdsynopsis><command>jhbuild build</command>
        <arg>--autogen</arg>
        <arg>--clean</arg>
        <arg>--check</arg>
        <arg>--dist</arg>
        <arg>--distcheck</arg>
        <arg>--ignore-suggests</arg>
        <arg>--no-network</arg>
        <arg rep="repeat">--skip=<replaceable>module</replaceable></arg>
        <arg>--start-at=<replaceable>module</replaceable></arg>
        <arg>--tags=<replaceable>tags</replaceable></arg>
        <arg>-D <replaceable>date</replaceable></arg>
        <arg>--no-xvfb</arg>
        <arg>--try-checkout</arg>
        <arg>--no-poison</arg>
        <arg>--force</arg>
        <arg>--build-optional-modules</arg>
        <arg>--min-age=<replaceable>time</replaceable></arg>
        <arg rep="repeat">module</arg>
      </cmdsynopsis>

      <para>Si aucun nom de module n'est indiqué dans la ligne de commande, c'est la liste des <link linkend="cfg-modules">modules</link> du fichier de configuration qui est utilisée.</para>

      <variablelist>
        <varlistentry>
          <term><option>-c</option>, <option>--clean</option></term>
          <listitem>
            <simpara>Exécute <command>make clean</command> avant de construire les modules.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <option>--check</option>
          </term>
          <listitem>
            <simpara>Exécute <command>make check</command> après la construction des modules.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-d</option>, <option>--dist</option></term>
          <listitem>
            <simpara>Exécute <command>make dist</command> après la construction des modules.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <option>--distcheck</option>
          </term>
          <listitem>
            <simpara>Exécute <command>make distcheck</command> après la construction des modules.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <option>--ignore-suggests</option>
          </term>
          <listitem>
            <simpara>Ne compile pas les dépendances faibles.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-n</option>, <option>--no-network</option></term>
          <listitem>
            <simpara>N'accède pas au réseau lors de la construction des modules. Cette option évite les étapes de téléchargement ou de mise à jour lors des constructions. Si un module ne peut pas être construit sans accès réseau, sa construction échouera.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-s</option>, <option>--skip</option>=<replaceable>module,...</replaceable></term>
          <listitem>
            <simpara>Ne compile pas les modules de la liste. Utilisé pour éviter la construction de dépendances spécifiques.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--tags</option>=<replaceable>étiquette,...</replaceable></term>
          <listitem>
            <simpara>Ignore les modules qui ne correspondent pas à <replaceable>étiquette</replaceable>. Une étiquette correspondant au nom du jeu de modules conteneur est automatiquement attribuée à chaque module.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-t</option>, <option>--start-at</option>=<replaceable>module</replaceable></term>
          <listitem>
            <simpara>Commence par le module indiqué plutôt qu'au début de la liste des dépendances. Cette option est utile quand la construction précédente a échoué.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <option>-D</option> <replaceable>date</replaceable>
          </term>
          <listitem>
            <simpara>Si le système de gestion de version sous-jacent le prend en charge, met à jour l'arborescence source selon son état à la date indiquée, avant de commencer la construction. La date doit être indiquée au format ISO, par exemple <literal>"2009-09-18 02:32Z"</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-x</option>, <option>--no-xvfb</option></term>
          <listitem>
            <simpara>Effectue les tests graphiques avec le serveur X réel au lieu d'utiliser une simulation Xvfb.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-C</option>, <option>--try-checkout</option></term>
          <listitem>
            <simpara>Si la construction échoue et que le système de gestion de version le prend en charge, force une extraction et exécute <command>autogen.sh</command> avant de recommencer la construction.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-N</option>, <option>--no-poison</option></term>
          <listitem>
            <simpara>Si l'une ou plusieurs des dépendances du module échouent, cette option force JHBuild à essayer tout de même de construire le module.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-f</option>, <option>--force</option></term>
          <listitem>
            <simpara>Construit les modules même si la stratégie habituelle indique que ce n'est pas nécessaire.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <option>--build-optional-modules</option>
          </term>
          <listitem>
            <simpara>Certains modules énumérés comme dépendances facultatives ne sont pas absolument nécessaires pour construire le module. Cette option force JHBuild à construire aussi les dépendances facultatives.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <option>--min-age</option>=<replaceable>time</replaceable>
          </term>
          <listitem>
            <simpara>Skip modules installed more recently than the specified
              relative time. The <replaceable>time</replaceable> string format
              is a number followed by a unit. The following units are supported:
              seconds (s), minutes (m), hours (h) and days (d). For example,
              <option>--min-age=2h</option> will skip modules built less than
              two hours ago.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="command-reference-make">
      <title>make</title>

      <para>The <command>make</command> command is for actively developing on
        a particular module. It requires the current directory be a source
        checkout, and does the equivalent of <command>buildone -nf $(basename
        $(pwd))</command>.</para>

      <cmdsynopsis><command>jhbuild make</command>
        <arg>--clean</arg>
        <arg>--check</arg>
        <arg>--distcheck</arg>
        <arg>--quiet</arg>
      </cmdsynopsis>

      <para>The options are the same as those available for the
        <link linkend="command-reference-build"><command>buildone</command></link>
        command.</para>
    </section>

    <section id="command-reference-buildone">
      <title>buildone</title>

      <para>La commande <command>buildone</command> est semblable à <command>build</command>, mais elle ne construit pas les dépendances du module. Elle est utile pour reconstruire un ou plusieurs modules.</para>

      <cmdsynopsis><command>jhbuild buildone</command>
        <arg>--clean</arg>
        <arg>--check</arg>
        <arg>--distcheck</arg>
        <arg>--no-network</arg>
        <arg>-D <replaceable>date</replaceable></arg>
        <arg>--no-xvfb</arg>
        <arg>--force</arg>
        <arg>--min-age=<replaceable>time</replaceable></arg>
        <arg choice="plain" rep="repeat">module</arg>
      </cmdsynopsis>

      <para>The <option>--check</option>, <option>--clean</option>,
        <option>-d</option>, <option>--distcheck</option>,
        <option>--no-network</option>, <option>-D</option> and
        <option>-x</option> options are processed as per the
        <link linkend="command-reference-build"><command>build</command></link>
        command.</para>

      <para>Cette commande nécessite au minimum un module dans la ligne de commande.</para>
    </section>

    <section id="command-reference-checkbranches">
      <title>checkbranches</title>

      <para>La commande <command>checkbranches</command> vérifie si les branches des modules sont définies correctement dans le gestionnaire de version et si les branches sont cohérentes avec le jeu de modules.</para>

      <cmdsynopsis><command>jhbuild checkbranches</command>
        <arg rep="repeat">--branch=<replaceable>branch</replaceable></arg>
      </cmdsynopsis>

      <variablelist>
        <varlistentry>
          <term>
            <option>--branch</option>=<replaceable>branch</replaceable>,
            <option>-b</option> <replaceable>branch</replaceable>
          </term>
          <listitem>
            <simpara>La branche à vérifier</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

<screen><prompt>$</prompt> <userinput>jhbuild -m gnome-2.20 checkbranches</userinput>
libgnomecanvas is missing branch definition for gnome-2-20
<prompt>$</prompt></screen>
    </section>

    <section id="command-reference-clean">
      <title>clean</title>

      <para>La commande <command>clean</command> nettoie les répertoires de compilation d'un ou de plusieurs modules.</para>

      <cmdsynopsis><command>jhbuild clean</command>
        <arg rep="repeat">--skip=<replaceable>module</replaceable></arg>
        <arg>--start-at=<replaceable>module</replaceable></arg>
      </cmdsynopsis>

      <para>Si aucun nom de module n'est indiqué dans la ligne de commande, c'est la liste des <link linkend="cfg-modules">modules</link> du fichier de configuration qui est utilisée.</para>

      <para>Consultez la documentation de la commande <link linkend="command-reference-build"><command>build</command></link> pour une description des options disponibles.</para>
    </section>

    <section id="command-reference-dot">
      <title>dot</title>

      <para>La commande <command>dot</command> génère un fichier décrivant le graphe directionnel formé par les dépendances dans un jeu de modules. Ce fichier peut ensuite être traité par le logiciel <ulink url="http://www.graphviz.org/">GraphViz</ulink> pour produire un diagramme.</para>

      <cmdsynopsis><command>jhbuild dot</command>
        <arg>--soft-deps</arg>
        <arg>--clusters</arg>
        <arg rep="repeat">module</arg>
      </cmdsynopsis>

      <para>Si aucun nom de module n'est indiqué dans la ligne de commande, c'est la liste des <link linkend="cfg-modules">modules</link> du fichier de configuration qui est utilisée.</para>

      <para>L'option <option>--soft-deps</option> ajoute des lignes pointillées depuis les modules vers leurs dépendances faibles. L'option <option>--clusters</option> groupe les modules selon les <link linkend="moduleset-syntax-defs-metamodule">métamodules</link>.</para>

      <para>La sortie de la commande dot peut être redirigée vers l'utilitaire dot pour générer un fichier PostScript :</para>

<screen><prompt>$</prompt> <userinput>jhbuild dot <replaceable>modules</replaceable> | dot -Tps &gt; dependencies.ps</userinput></screen>

      <para>Ou une image PNG :</para>

<screen><prompt>$</prompt> <userinput>jhbuild dot <replaceable>modules</replaceable> | dot -Tpng &gt; dependencies.png</userinput></screen>

      <figure id="sample-dot-output">
        <title>Exemple de sortie dot de JHBuild</title>
        <screenshot>
          <mediaobject>
            <imageobject>
              <imagedata fileref="figures/jhbuild_sample_dot_output.png" format="PNG"/>
            </imageobject>
          </mediaobject>
        </screenshot>
      </figure>
    </section>

    <section id="command-reference-gui">
      <title>gui</title>

      <para>La commande <command>gui</command> lance une interface graphique de JHBuild qui permet de sélectionner des modules à construire et de modifier certaines options.</para>

      <cmdsynopsis><command>jhbuild gui</command>
      </cmdsynopsis>

      <para>L'interface graphique est basée sur GTK, ce qui requiert des bibliothèques supplémentaires.</para>
    </section>

    <section id="command-reference-info">
      <title>info</title>

      <para>La commande <command>info</command> affiche des informations sur un ou plusieurs modules.</para>

      <cmdsynopsis><command>jhbuild info</command>
        <arg choice="plain" rep="repeat">module</arg>
      </cmdsynopsis>

      <para>Cette commande affiche le nom du module, son type, ses dépendances, les paquets qui en dépendent, le répertoire source et la date de sa dernière installation avec JHBuild. Le cas échéant, elle affiche également certaines informations spécifiques au type de module, telles que le dépôt CVS ou l'URL de téléchargement.</para>

      <para>Si aucun module n'est précisé dans la commande, des informations sont affichées au sujet de tous les modules définis dans le jeu de modules.</para>
    </section>

    <section id="command-reference-list">
      <title>list</title>

      <para>La commande <command>list</command> affiche la liste complète des modules que la commande <command>build</command> construirait.</para>

      <cmdsynopsis><command>jhbuild list</command>
        <arg>-a</arg>
        <arg>-r</arg>
        <arg>-s</arg>
        <arg>--start-at=<replaceable>module</replaceable></arg>
        <arg>--tags=<replaceable>tags</replaceable></arg>
        <arg>--ignore-suggests</arg>
        <arg>--list-optional-modules</arg>
        <arg rep="repeat">module</arg>
      </cmdsynopsis>

      <para>Si aucun nom de module n'est indiqué dans la ligne de commande, c'est la liste des <link linkend="cfg-modules">modules</link> du fichier de configuration qui est utilisée.</para>

      <para>Les options <option>--skip</option>, <option>--start-at</option>, <option>--tags</option> et <option>--ignore-suggests</option> sont traitées de la même manière que pour la commande <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>-a</option>, <option>--all-modules</option></term>
          <listitem>
            <simpara>Énumère tous les modules du jeu de modules, sans tenir compte des dépendances de construction.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-r</option>, <option>--show-revision</option></term>
          <listitem>
            <simpara>Si un module est défini par une de ses branches, affiche le nom de la branche avec le nom de module.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <option>--list-optional-modules</option>
          </term>
          <listitem>
            <simpara>Cette option force JHBuild à énumérer les dépendances facultatives.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="command-reference-rdepends">
      <title>rdepends</title>

      <para>La commande <command>rdepends</command> affiche les dépendances inverses d'un module.</para>

      <cmdsynopsis><command>jhbuild rdepends</command>
        <arg>module</arg>
      </cmdsynopsis>

      <variablelist>
        <varlistentry>
          <term>
            <option>--dependencies</option>
          </term>
          <listitem>
            <simpara>Affiche le chemin de dépendance à la suite des modules.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term>
            <option>--direct</option>
          </term>
          <listitem>
            <simpara>Limite l'affichage aux modules dépendant directement du module indiqué.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="command-reference-run">
      <title>run</title>

      <para>La commande <command>run</command> exécute la commande indiquée dans le même environnement que JHBuild utilise lors de la construction de modules.</para>

      <cmdsynopsis><command>jhbuild run</command>
        <arg>--in-builddir</arg>
        <arg>--in-checkoutdir</arg>
        <arg choice="plain"><replaceable>program</replaceable></arg>
        <arg rep="repeat"><replaceable>argument</replaceable></arg>
      </cmdsynopsis>

      <para>En cas d'utilisation de JHBuild pour construire GNOME, cette commande est utile dans les scripts de démarrage de X.</para>

      <variablelist>
        <varlistentry>
          <term><option>--in-builddir</option>=<replaceable>module</replaceable></term>
          <listitem>
            <simpara>Exécute la commande dans le répertoire de construction du module indiqué.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

      <variablelist>
        <varlistentry>
          <term><option>--in-checkoutdir</option>=<replaceable>module</replaceable></term>
          <listitem>
            <simpara>Exécute la commande dans le répertoire source du module indiqué.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="command-reference-sanitycheck">
      <title>sanitycheck</title>

      <para>La commande <command>sanitycheck</command> effectue un certain nombre de contrôles pour vérifier que l'environnement de construction est correct.</para>

      <cmdsynopsis><command>jhbuild sanitycheck</command>
      </cmdsynopsis>

      <para>Ces contrôles vérifient notamment que :</para>

      <itemizedlist>
        <listitem>
          <simpara>les préfixes d'extraction et d'installation sont accessibles en écriture ;</simpara>
        </listitem>
        <listitem>
          <simpara>les outils de construction indispensables sont installés ;</simpara>
        </listitem>
        <listitem>
          <simpara>certaines macros couramment utilisées sont disponibles dans les chemins de recherche des commandes <command>aclocal</command> associées aux différentes versions de <command>automake</command> ;</simpara>
        </listitem>
        <listitem>
          <simpara>le catalogue XML contient les DTD et feuilles de style DocBook.</simpara>
        </listitem>
      </itemizedlist>
    </section>

    <section id="command-reference-shell">
      <title>shell</title>

      <para>La commande <command>shell</command> lance un shell utilisateur dans le même environnement que JHBuild lorsqu'il construit des modules.</para>

      <cmdsynopsis><command>jhbuild shell</command>
      </cmdsynopsis>

      <para>Cette commande est équivalente à ceci :</para>

<screen><prompt>$</prompt> <userinput>jhbuild run $SHELL</userinput></screen>

      <para>La variable d'environnement <envar>UNDER_JHBUILD</envar> est définie à « true » (vrai) lorsque ce shell est actif. Vous pouvez utiliser la présence de cette variable pour personnaliser votre invite de commande afin d'indiquer que vous êtes dans un shell contrôlé par JHBuild. Par exemple, il est possible d'indiquer cela dans votre <filename>.bashrc</filename> :</para>

<screen>
	if [ -n "$UNDER_JHBUILD" ]; then
	    PS1="[jhbuild] $PS1"
	fi
      </screen>

      <para>En conséquence, vous verrez apparaître la séquence <literal>[jhbuild]</literal> au début de votre invite de commande habituelle, ce qui rend plus évident la distinction entre un shell normal et un shell contrôlé par JHBuild.</para>
    </section>

    <section id="command-reference-sysdeps">
      <title>sysdeps</title>

      <para>The <command>sysdeps</command> command displays a list of
        dependency modules that are provided by installed system packages.
        JHBuild will not build the modules from source if the configuration
        variable
        <link linkend="cfg-partial-build"><varname>partial_build</varname></link>
        is <constant>True</constant>.</para>

      <para>The <command>sysdeps</command> command also displays a list of
        dependency modules where the installed system packages are too old.
        JHBuild will build newer modules from source.</para>

      <para>The <command>sysdeps</command> command also displays a list of
        dependency modules with no matching system package installed.</para>

      <cmdsynopsis><command>jhbuild sysdeps</command>
        <arg>--install</arg>
      </cmdsynopsis>

      <variablelist>
        <varlistentry>
          <term>
            <option>--install</option>
          </term>
          <listitem>
            <simpara>This option installs system packages which are
              dependencies of the moduleset. The system packages are installed
              using <application>PackageKit</application>.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

      <example>
        <title><command>sysdeps</command> example</title>
<screen><prompt>$</prompt> <userinput>jhbuild sysdeps</userinput>
System installed packages which are new enough:
  speex (required=1.2rc1, installed=1.2rc1)
  libdiscid (required=0.2.2, installed=0.2.2)
  telepathy-farsight (required=0.0.14, installed=0.0.16)
  lcms2 (required=2.2, installed=2.2)
...
System installed packages which are too old:
  webkitgtk-3.0 (required=1.5.1, installed=1.4.0)
  ...
No matching system package installed:
  libvala-0.14 (required=0.13.1)
  ...</screen>
      </example>
    </section>

    <section id="command-reference-tinderbox">
      <title>tinderbox</title>

      <para>La commande <command>tinderbox</command> est semblable à la commande <command>build</command>, mais écrit toutes les sorties de terminal dans des fichiers HTML prêts à être publiés sur un site Web. Elle permet de mettre en place des systèmes tels que Mozilla Tinderbox ou Debian Buildd.</para>

      <cmdsynopsis><command>jhbuild tinderbox</command>
        <arg>--clean</arg>
        <arg>--no-network</arg>
        <arg>--output=<replaceable>directory</replaceable></arg>
        <arg rep="repeat">--skip=<replaceable>module</replaceable></arg>
        <arg>--start-at=<replaceable>module</replaceable></arg>
        <arg>-D <replaceable>date</replaceable></arg>
        <arg>-C</arg>
        <arg>-N</arg>
        <arg>-f</arg>
        <arg rep="repeat">module</arg>
      </cmdsynopsis>

      <para>The <option>--clean</option>, <option>--no-network</option>,
        <option>--skip</option>, <option>--start-at</option>,
        <option>-D</option>, <option>-C</option>, <option>-N</option> and
        <option>-f</option> options are processed as per the
        <link linkend="command-reference-build"><command>build</command></link>
        command.</para>

      <variablelist>
        <varlistentry>
          <term><option>-o</option>, <option>--output</option>=<replaceable>répertoire</replaceable></term>
          <listitem>
            <simpara>Le répertoire dans lequel écrire les fichiers HTML.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="command-reference-uninstall">
      <title>uninstall</title>

      <para>La commande <command>uninstall</command> désinstalle un ou plusieurs modules.</para>

      <cmdsynopsis><command>jhbuild uninstall</command>
        <arg choice="plain" rep="repeat">module</arg>
      </cmdsynopsis>
    </section>

    <section id="command-reference-update">
      <title>update</title>

      <para>La commande <command>update</command> est semblable à <command>build</command>, mais n'effectue que les étapes de téléchargement et de mise à jour des modules, sans les construire.</para>

      <cmdsynopsis><command>jhbuild update</command>
        <arg rep="repeat">--skip=<replaceable>module</replaceable></arg>
        <arg>--start-at=<replaceable>module</replaceable></arg>
        <arg>--tags=<replaceable>tags</replaceable></arg>
        <arg>--ignore-suggests</arg>
        <arg>-D <replaceable>date</replaceable></arg>
        <arg rep="repeat">module</arg>
      </cmdsynopsis>

      <para>Les options <option>--skip</option>, <option>--start-at</option>, <option>--tags</option>, <option>--ignore-suggests</option> et <option>-D</option> sont traitées de la même manière que pour la commande <link linkend="command-reference-build"><command>build</command></link>.</para>
    </section>

    <section id="command-reference-updateone">
      <title>updateone</title>

      <para>La commande <command>updateone</command> est semblable à <command>update</command>, mais elle ne met pas à jour les modules dépendants. Elle est utile pour mettre à jour un ou plusieurs modules.</para>

      <cmdsynopsis><command>jhbuild updateone</command>
        <arg>-D <replaceable>date</replaceable></arg>
        <arg choice="plain" rep="repeat">module</arg>
      </cmdsynopsis>

      <para>L'option <option>-D</option> est traitée de la même manière que pour <link linkend="command-reference-build"><command>build</command></link>.</para>

      <para>Cette commande nécessite au minimum un module dans la ligne de commande.</para>
    </section>
  </section>

  <section id="config-reference">
    <title>Référence du fichier de configuration</title>

    <para>Le fichier <filename>~/.jhbuildrc</filename> utilise la syntaxe Python standard. Le fichier est exécuté et les variables résultantes définies dans l'espace de noms sont utilisées pour contrôler le comportement de JHBuild. Un ensemble de valeurs par défaut sont insérées dans l'espace de noms avant d'exécuter le fichier de configuration de l'utilisateur.</para>

    <para>Les variables de configuration booléennes sont définies avec une syntaxe correspondant à l'exemple suivant :</para>

<programlisting>use_local_modulesets = True</programlisting>

    <para>Les variables de configuration « chaînes de caractères » sont définies avec une syntaxe correspondant à l'exemple suivant :</para>

<programlisting>autogenargs = '--disable-static --disable-gtk-doc'</programlisting>

    <para>Les variables de configuration contenant des listes sont définies avec une syntaxe correspondant à l'exemple suivant :</para>

<programlisting>skip = ['mozilla', 'pulseaudio']</programlisting>

    <para>Les variables de configuration contenant des dictionnaires sont définies avec une syntaxe correspondant à l'exemple suivant :</para>

<programlisting>repos['git.gnome.org'] = 'ssh://username@git.gnome.org/git/'</programlisting>

    <section id="config-reference-variables">
      <title>Variables de configuration</title>

      <variablelist>
<?dbhtml list-presentation="table"?>
        <varlistentry>
          <term id="cfg-autogenargs">
            <varname>autogenargs</varname>
          </term>
          <listitem>
            <simpara>Une chaîne contenant des paramètres passés au script <command>autogen.sh</command> de tous les modules. Peut être surchargée par des modules précis en utilisant le dictionnaire <varname>module_autogenargs</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-branches">
            <varname>branches</varname>
          </term>
          <listitem>
            <simpara>A dictionary specifying which branch to use for specific
              modules. This is useful if you are making some changes on a branch
              of a module and want JHBuild to build that branch instead of the
              one listed in the module set.</simpara>

            <simpara>La définition des branches dépend du gestionnaire de version du module :</simpara>

            <itemizedlist>
              <listitem>
                <simpara>CVS : révision. Par ex. <literal>'BRANCH-PROJECT-0_8'</literal></simpara>
              </listitem>
              <listitem>
                <simpara>Bazaar : URI de la branche du module. Par ex. <literal>'http://bzr.example.net/project/gnome-2-28'</literal></simpara>
              </listitem>
              <listitem>
                <simpara>Git : tuple dont la première partie est un dépôt (facultatif, peut contenir la valeur None) et la seconde partie le nom de la branche. Par ex. <literal>('git://git.example.net/project', 'gnome-2-28')</literal></simpara>

                <example>
                  <title>Simple example</title>
<programlisting>branches['modulename'] = (None, 'branchname')</programlisting>
                </example>
              </listitem>
              <listitem>
                <simpara>Subversion : URI de la branche du module. Par ex. <literal>'svn://svn.example.net/project/gnome-2-28'</literal></simpara>
              </listitem>
            </itemizedlist>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-builddir-pattern">
            <varname>builddir_pattern</varname>
          </term>
          <listitem>
            <simpara>A <function>printf</function> style formatting pattern
              used to generate build directory names. This is only used when
              using separate source and build trees. The <literal>%s</literal>
              in the format string will be replaced with
              <varname>checkoutdir</varname>. Defaults to
              <literal>'%s'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-buildroot">
            <varname>buildroot</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant le répertoire parent contenant les arborescences de construction. La valeur par défaut est <constant>None</constant>, ce qui signifie que la construction s'effectue dans les arborescences source.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-buildscript">
            <varname>buildscript</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant le script de construction à utiliser. La valeur recommandée est la valeur par défaut, <literal>terminal</literal>. En particulier, n'indiquez pas <literal>gtk</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cf-build-policy">
            <varname>build_policy</varname>
          </term>
          <listitem>
            <simpara>A string specifying which modules to build. The three
              possible options are <literal>all</literal>, to build all modules
              requested, <literal>updated</literal> to build only modules which
              have changed, or <literal>updated-deps</literal> to build modules
              which have changed or which have dependencies which have changed.
              Defaults to <literal>updated-deps</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-checkoutroot">
            <varname>checkoutroot</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant le répertoire dans lequel décompresser les arborescences source. À moins que <varname>buildroot</varname> ne soit défini, la construction s'opère également dans ce répertoire. La valeur par défaut est <filename>~/checkout/gnome</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-checkout-mode">
            <varname>checkout_mode</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant la méthode d'extraction des répertoires dans la gestion de versions. La valeur par défaut est <literal>update</literal> (mise à jour). Cette valeur peut être définie pour chaque module avec <varname>module_checkout_mode</varname>. Les valeurs possibles sont : <literal>update</literal> (mettre à jour le répertoire extrait), <literal>clobber</literal> (effacer le répertoire avant d'extraire les sources), <literal>export</literal> (effacer le répertoire puis créer une copie non versionnée des sources) et <literal>copy</literal> (extraire dans un répertoire différent de celui où il sera construit).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-copy-dir">
            <varname>copy_dir</varname>
          </term>
          <listitem>
            <simpara>A string specifying the directory to copy to, if the copy
              <link linkend="cfg-checkout-mode">
              <varname>checkout_mode</varname></link> is in use. Defaults to the
              checkout directory.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-cvs-program">
            <varname>cvs_program</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant le programme à utiliser pour la prise en charge de CVS. Cela peut être <literal>git-cvsimport</literal> ou <literal>cvs</literal>. La valeur par défaut est <literal>cvs</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-dvcs-mirror-dir">
            <varname>dvcs_mirror_dir</varname>
          </term>
          <listitem>
            <simpara>A string specifying a local mirror directory. JHBuild
              will create local mirrors of repositories at the specified
              directory. The mirrors can be shared by multiple repository
              groups, saving space and time because hard-links will be used for
              local clones. The commands <command>update</command> and
              <command>updateone</command> will create the mirrors and fetch new
              commits from the online repositories. This option is only
              supported by Git and Bazaar repositories.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-installprog">
            <varname>installprog</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant un programme à utiliser en remplacement de <literal>/usr/bin/install</literal>. Si présente, sa valeur par défaut correspond au script d'encapsulation <literal>install-check</literal> fourni par JHBuild. Ce script optimise l'installation des en-têtes afin de réduire le temps nécessaire aux recompilations.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-ignore-suggests">
            <varname>ignore_suggests</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant s'il faut ignorer les dépendances faibles lors de la génération de l'arbre des dépendances. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-interact">
            <varname>interact</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant si l'interaction avec l'utilisateur est autorisée. La définition de cette valeur à <constant>False</constant> équivaut à passer l'option <option>--no-interact</option> à JHBuild. La valeur par défaut est <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-makeargs">
            <varname>makeargs</varname>
          </term>
          <listitem>
            <simpara>Une chaîne énumérant des paramètres supplémentaires à passer à <command>make</command>. La valeur par défaut est <literal>''</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-makecheck">
            <varname>makecheck</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant s'il faut exécuter <command>make check</command> après <command>make</command>. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-makecheck-advistory">
            <varname>makecheck_advisory</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant si les échecs d'exécution de la commande <command>make check</command> doivent être considérés comme des avertissements ou s'ils produisent un échec de la construction. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-makeclean">
            <varname>makeclean</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant s'il faut exécuter <command>make clean</command> après <command>make</command>. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-makedist">
            <varname>makedist</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant s'il faut exécuter <command>make dist</command> après <command>make</command>. La valeur par défaut est <constant>False</constant>. Ce réglage équivaut à passer l'option <option>--dist</option> à JHBuild.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-makedistcheck">
            <varname>makedistcheck</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant s'il faut exécuter <command>make distcheck</command> après <command>make</command>. La valeur par défaut est <constant>False</constant>. Ce réglage équivaut à passer l'option <option>--distcheck</option> à JHBuild.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-module-autogenargs">
            <varname>module_autogenargs</varname>
          </term>
          <listitem>
            <simpara>Un dictionnaire faisant correspondre les noms de modules à des chaînes donnant des paramètres à passer à <command>autogen.sh</command>. Le paramètre dans <varname>module_autogenargs</varname> est utilisé à la place du paramètre global <varname>autogenargs</varname>. Si un module particulier n'est pas dans le dictionnaire, c'est le paramètre global <varname>autogenargs</varname> qui est utilisé.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-module-checkout-mode">
            <varname>module_checkout_mode</varname>
          </term>
          <listitem>
            <simpara>Un dictionnaire indiquant le mode d'extraction à employer pour les modules. Ce paramètre écrase le paramètre global <varname>checkout_mode</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-module-makeargs">
            <varname>module_makeargs</varname>
          </term>
          <listitem>
            <simpara>Un dictionnaire faisant correspondre les noms de modules à des chaînes indiquant les paramètres à passer à <command>make</command>. Le paramètre dans <varname>module_makeargs</varname> est utilisé à la place du paramètre global <varname>makeargs</varname>. Si un module particulier n'est pas dans le dictionnaire, c'est le paramètre global <varname>makeargs</varname> qui est utilisé.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-module-makecheck">
            <varname>module_makecheck</varname>
          </term>
          <listitem>
            <simpara>Un dictionnaire faisant correspondre les noms de modules à des valeurs booléennes indiquant s'il faut exécuter <command>make check</command> après <command>make</command>. Le paramètre dans <varname>module_makecheck</varname> remplace la valeur de <varname>makecheck</varname>. Si un module particulier n'est pas dans le dictionnaire, c'est le paramètre global <varname>makecheck</varname> qui est utilisé.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-module-nopoison">
            <varname>module_nopoison</varname>
          </term>
          <listitem>
            <simpara>Un dictionnaire faisant correspondre les noms de modules à des valeurs booléennes. Si la valeur pour un module vaut <constant>True</constant>, JHBuild essaye de construire les modules dépendants même si le module indiqué échoue. Le paramètre dans <varname>module_nopoison</varname> remplace la valeur de <varname>nopoison</varname>. Si un module particulier n'est pas dans le dictionnaire, c'est le paramètre global <varname>nopoisons</varname> qui est utilisé.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-module-extra-env">
            <varname>module_extra_env</varname>
          </term>
          <listitem>
            <simpara>Un dictionnaire faisant correspondre les noms de modules à des dictionnaires contenant des variables d'environnement supplémentaires à passer lors de l'exécution de commandes pour le module.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-modules">
            <varname>modules</varname>
          </term>
          <listitem>
            <simpara>A list of strings specifying the modules to build. The
              list of modules actually built will be recursively expanded to
              include all the dependencies unless the
              <link linkend="command-reference-buildone">
              <command>buildone</command></link> command is used. Defaults to
              <literal>['meta-gnome-desktop']</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-moduleset">
            <varname>moduleset</varname>
          </term>
          <listitem>
            <simpara>Une chaîne ou une liste de chaînes indiquant le ou les noms des jeux de modules à utiliser. Cela peut être le nom de fichier d'un jeu de modules inclus dans JHBuild (sans chemin ni extension) ou un URL HTTP complet d'un jeu de modules géré en externe. Les jeux de modules ayant un URL HTTP sont placés dans un cache local. Si le nom d'un module figure dans plus d'un jeu de modules, le dernier jeu de modules dans la liste est prioritaire. Les jeux de modules fournis avec JHBuild sont mis à jour au gré de la progression du développement de GNOME.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-modulesets-dir">
            <varname>modulesets_dir</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant le répertoire contenant les jeux de modules à utiliser. Par défaut, c'est le répertoire <filename>modulesets/</filename> dans les sources de JHBuild.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-nice-build">
            <varname>nice_build</varname>
          </term>
          <listitem>
            <simpara>Run builds under the <constant>SCHED_IDLE</constant>
              priority on Linux, <command>nice</command> on other Unix. This can
              dramatically improve desktop interactivity for parallel builds
              while having only a negligible impact on build throughput.
            </simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-nobuild">
            <varname>nobuild</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne qui si elle est définie à <constant>True</constant> indique à JHBuild de ne pas construire les modules, mais uniquement de les télécharger et de décompresser les sources. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-nonetwork">
            <varname>nonetwork</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant si l'accès au réseau est autorisé. Cela affecte l'extraction ou la mise à jour de modules CVS, le téléchargement d'archives tar et la mise à jour des jeux de modules. Définir cette valeur à <constant>True</constant> équivaut à passer l'option <option>--no-network</option>. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-nonotify">
            <varname>nonotify</varname>
          </term>
          <listitem>
            <simpara>A boolean value specifying whether to emit notifications
              using the notification daemon. If set to
              <constant>False</constant>, notifications are emitted. Defaults to
              <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-nopoison">
            <varname>nopoison</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne qui, si elle est définie à <constant>True</constant>, indique à JHBuild d'essayer la construction des modules même si la construction d'une ou de plusieurs dépendances a échoué. Cette option est équivalente au paramètre <option>--no-poison</option>. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-notrayicon">
            <varname>notrayicon</varname>
          </term>
          <listitem>
            <simpara>A boolean value specifying whether to show an icon in the
              system tray using Zenity. If set to <constant>False</constant>,
              notifications are emitted. Defaults to <constant>True</constant>.
            </simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-noxvfb">
            <varname>noxvfb</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne qui, si elle est définie à <constant>True</constant>, indique à JHBuild d'exécuter tout test graphique avec le serveur X réel au lieu d'utiliser <command>Xvfb</command>. Cette option est équivalente au paramètre <option>--no-xfvb</option>. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-partial-build">
            <varname>partial_build</varname>
          </term>
          <listitem>
            <simpara>A boolean value, if set to <constant>True</constant>
              JHBuild will not build dependency modules if corresponding system
              packages are installed and sufficient version. Defaults to
              <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-prefix">
            <varname>prefix</varname>
          </term>
          <listitem>
            <simpara>A string specifying the prefix to install modules to.
              <varname>prefix</varname> must be an absolute path. This directory
              must be writable. Defaults to <literal>'/opt/gnome'</literal>.
            </simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-pretty-print">
            <varname>pretty_print</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant s'il s'agit d'améliorer la mise en forme de la sortie des sous-processus. Seules les sorties CVS gèrent la mise en forme améliorée. Cette option peut être désactivée si la mise en forme améliorée pose des problèmes. La valeur par défaut est <literal>True</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-print-command-pattern">
            <varname>print_command_pattern</varname>
          </term>
          <listitem>
            <simpara>A string displayed before JHBuild executes a command.
              <varname>%(command)s</varname> in the string will be replaced with
              the command about to be executed. <varname>%(cwd)s</varname> in
              the string will be replaced with the current working directory.
              Defaults to <literal>'%(command)s'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-progress-bar">
            <varname>progress_bar</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant s'il faut afficher une barre de progression lorsque JHBuild fonctionne en <link linkend="cfg-quiet-mode">mode silencieux</link>. La valeur par défaut est <literal>True</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-quiet-mode">
            <varname>quiet_mode</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne. Si définie à <constant>True</constant>, elle désactive la sortie des commandes qui s'exécutent. La valeur par défaut est <literal>False</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term id="cfg-repos">
            <varname>repos</varname>
          </term>
          <listitem>
            <simpara>Un dictionnaire indiquant un emplacement de dépôt alternatif pour un dépôt spécifique. Cette variable de configuration est utile aux développeurs de modules. Par défaut, JHBuild extrait le code à partir des dépôts en utilisant des emplacements anonymes. Les clés du dictionnaire sont des noms de dépôts courts et les valeurs sont des chaînes d'emplacement des dépôts alternatifs. Par exemple :</simpara>

<programlisting>repos['git.gnome.org'] = 'ssh://username@git.gnome.org/git/'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-skip">
          <term>
            <varname>skip</varname>
          </term>
          <listitem>
            <simpara>Une liste de modules à ignorer. L'option de ligne de commande <option>--skip</option> étend cette liste. Par défaut, cette liste est vide.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-sticky-date">
          <term>
            <varname>sticky_date</varname>
          </term>
          <listitem>
            <simpara>Une chaîne de caractères. Si définie et si le gestionnaire de versions sous-jacent le prend en charge, JHBuild met à jour l'arborescence source selon son état à la date indiquée. La date doit être fournie au format ISO, par ex. <literal>'<replaceable>aaaa</replaceable>-<replaceable>mm</replaceable>-<replaceable>jj</replaceable>'</literal>. La valeur par défaut est <constant>None</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-svn-program">
          <term>
            <varname>svn_program</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant le programme à utiliser pour la prise en charge de Subversion. Cela peut être <literal>svn</literal>, <literal>git-svn</literal> ou <literal>bzr</literal>. La valeur par défaut est <literal>svn</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-tarballdir">
          <term>
            <varname>tarballdir</varname>
          </term>
          <listitem>
            <simpara>Une chaîne de caractères ; si définie, les archives tar sont téléchargées dans ce répertoire au lieu de <varname>checkoutroot</varname>. C'est utile si vous avez plusieurs environnements JHBuild ou que vous nettoyez régulièrement <varname>checkoutroot</varname> et que vous souhaitez restreindre la consommation de bande passante.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-tinderbox-outputdir">
          <term>
            <varname>tinderbox_outputdir</varname>
          </term>
          <listitem>
            <simpara>Une chaîne indiquant le répertoire de stockage de la sortie de <command>jhbuild tinderbox</command>. Cette chaîne peut être remplacée par l'option <option>--output</option>. La valeur par défaut est <constant>None</constant>, ce qui signifie qu'il faut obligatoirement définir cette option soit dans la ligne de commande, soit dans le fichier de configuration.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-trycheckout">
          <term>
            <varname>trycheckout</varname>
          </term>
          <listitem>
            <simpara>Une option booléenne qui, si elle est définie à <constant>True</constant>, indique à JHBuild d'essayer de résoudre automatiquement les échecs en 1) exécutant une nouvelle fois <command>autogen.sh</command> et 2) extrayant une nouvelle version du module à partir du contrôle de version. Ce paramètre équivaut à passer l'option <option>--try-checkout</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-use-lib64">
          <term>
            <varname>use_lib64</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne qui indique s'il faut installer les bibliothèques dans les répertoires <filename>lib64</filename>. Lorsque c'est le cas, <literal>--libdir=\${exec_prefix}/lib64</literal> est transmis à « configure ». Lorsque JHBuild fonctionne sur un système Linux <literal>x86_64</literal>, <literal>ppc64</literal> ou <literal>s390x</literal>, cette valeur vaut <constant>True</constant> par défaut, sinon elle est définie à <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-use-local-modulesets">
          <term>
            <varname>use_local_modulesets</varname>
          </term>
          <listitem>
            <simpara>Une valeur booléenne indiquant d'utiliser des jeux de modules qui ont été extraits parallèlement au code source de JHBuild, au lieu de les télécharger au fur et à mesure, à partir du dépôt du gestionnaire de versions de GNOME. La valeur par défaut est <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-xvfbargs">
          <term>
            <varname>xvfbargs</varname>
          </term>
          <listitem>
            <simpara>Une chaîne contenant des paramètres à passer à <command>Xvfb</command> si des tests graphiques sont effectués.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="config-reference-other">
      <title>Autres structures du fichier de configuration</title>

      <para>En plus des variables ci-dessus, d'autres paramètres peuvent être définis dans le fichier de configuration :</para>

      <variablelist>
        <varlistentry id="cfg-os-environ">
          <term>
            <varname>os.environ</varname>
          </term>
          <listitem>
            <para>Un dictionnaire représentant l'environnement. Cet environnement est transmis aux processus générés par JHBuild.</para>

            <para>Certaines variables d'environnement ont un impact certain, comme  <envar>CPPFLAGS</envar>, <envar>CFLAGS</envar>, <envar>INSTALL</envar> et <envar>LDFLAGS</envar>. Par exemple :</para>

<programlisting>os.environ['CFLAGS'] = '-O0 -g'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><function>addpath</function>(<parameter>var_env</parameter>, <parameter>chemin</parameter>)</term>
          <listitem>
            <para>Cela ajoute un répertoire à la variable d'environnement <envar>PATH</envar> (chemin). <function>addpath</function> gère correctement le cas où la variable d'environnement est initialement vide (un deux-points isolé au début ou à la fin d'une variable d'environnement peut avoir des conséquences inattendues).</para>

            <para><function>addpath</function> prend en charge de manière particulière la variable d'environnement <envar>ACLOCAL_FLAGS</envar> dont la liste de chemins doit être de la forme <literal>-I <replaceable>chemin</replaceable></literal>.</para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><function>prependpath</function>(<parameter>var_env</parameter>, <parameter>chemin</parameter>)</term>
          <listitem>
            <para>Après le traitement du fichier de configuration, JHBuild modifie certains chemins sur la base de variables telles que <varname>prefix</varname> (par ex. en ajoutant <literal>$prefix/bin</literal> au début de la variable <envar>PATH</envar>).</para>

            <para>La fonction <function>prependpath</function> fonctionne comme <function>addpath</function>, sauf que la variable d'environnement est modifiée après que JHBuild ait modifié l'environnement.</para>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>
  </section>

  <section id="moduleset-syntax">
    <title>Syntaxe des fichiers de jeu de modules</title>

    <para>JHBuild utilise des fichiers XML pour décrire les dépendances entre modules. Un schéma RELAX-NG et une définition de type de document (DTD : Document Type Definition) sont inclus avec JHBuild dans le répertoire <filename>modulesets/</filename>. Le schéma RELAX-NG peut être utilisé pour modifier les fichiers de jeux de modules au moyen du mode <literal>nxml-mode</literal> dans Emacs.</para>

    <para>L'élément de premier niveau dans un fichier de jeu de modules est l'élément <sgmltag class="element">moduleset</sgmltag>. Aucun espace de nom XML n'est utilisé. Les éléments sous le premier niveau sont de trois types : sources de module, commandes d'inclusion et définitions de module.</para>

    <section id="moduleset-syntax-sources">
      <title>Sources de module</title>

      <para>Plutôt que d'énumérer l'emplacement exact de chaque module, plusieurs « sources de modules » sont listées dans le jeu de modules, puis référencées par leur nom dans les définitions de modules. En plus de réduire la quantité d'informations redondantes dans le jeu de modules, cela facilite l'indication d'une source alternative pour ces modules (avec CVS et Subversion, il arrive fréquemment que les développeurs et les utilisateurs utilisent des méthodes différentes pour accéder aux dépôts).</para>

      <para>L'élément <sgmltag class="element">repository</sgmltag> est utilisé pour décrire tout type de dépôt. L'élément <sgmltag class="element">branch</sgmltag> est utilisé dans une définition de module pour préciser des paramètres supplémentaires.</para>

<programlisting>
&lt;repository name="<replaceable>nom</replaceable>"
  type="<replaceable>type</replaceable>"
  [ default="<replaceable>valeur_par_défault</replaceable>" ]
  [ password="<replaceable>mot_de_passe</replaceable>" ]
  [ cvsroot="<replaceable>racine_cvs</replaceable>" ]
  [ archive="<replaceable>archive</replaceable>" ]
  [ href="<replaceable>href</replaceable>" ]
  [ server="<replaceable>serveur</replaceable>" ]
  [ database="<replaceable>base_de_données</replaceable>" ]
  [ defbranch="<replaceable>définition_branche</replaceable>" ]
  [ trunk-template="<replaceable>modèle_de_tronc</replaceable>" ]
  [ branches-template="<replaceable>modèle_de_branche</replaceable>" ]
  [ tags-template="<replaceable>modèle_de_tag</replaceable>" ]
  [ developer-href-example="<replaceable>exemple_href_pour_développeur</replaceable>" ] /&gt;
</programlisting>

      <para>L'attribut <sgmltag class="attribute">name</sgmltag> est un identifiant unique pour le dépôt.</para>

      <para>L'attribut <sgmltag class="attribute">default</sgmltag> indique si ce dépôt est la source par défaut pour ce jeu de modules.</para>

      <para>The <sgmltag class="attribute">type</sgmltag> attribute specifies
        the type of repository. It can be one of: <literal>bzr</literal>,
        <literal>cvs</literal>, <literal>darcs</literal>,
        <literal>fossil</literal>, <literal>git</literal>,
        <literal>hg</literal>, <literal>mnt</literal>, <literal>svn</literal>,
        <literal>tarball</literal>. Other attributes depend on the
        <sgmltag class="attribute">type</sgmltag>, as well as the
        <sgmltag class="element">branch</sgmltag> used inside module
        definitions. Those are described below in the repository type
        sub-sections.</para>

      <para>L'attribut <sgmltag class="attribute">developer-href-example</sgmltag> sert à indiquer le format de l'URL pour le dépôt tel qu'utilisé par les développeurs, à titre informatif.</para>

      <para>L'élément <sgmltag class="element">branch</sgmltag> est employé dans les définitions de modules.</para>

<programlisting>
&lt;branch
  [ repo="<replaceable>dépôt</replaceable>" ]
  [ module="<replaceable>nom_de_module</replaceable>" ]
  [ checkoutdir="<replaceable>dossier_extraction</replaceable>" ]
  [ revision="<replaceable>révision</replaceable>" ]
  [ tag="<replaceable>tag</replaceable>" ]
  [ update-new-dirs="<replaceable>mise_à_jour_nouveaux_dossiers</replaceable>" ]
  [ override-checkoutdir="<replaceable>écraser_dossier_extraction</replaceable>" ]
  [ subdir="<replaceable>sous-dossier</replaceable>" ]
  [ branch="<replaceable>branche</replaceable>" ]
  [ version="<replaceable>version</replaceable>" ]
  [ size="<replaceable>taille</replaceable>" ]
  [ source-subdir="<replaceable>sous-dossier_source</replaceable>" ]
  [ hash="<replaceable>hâchage</replaceable>" ]/&gt;
</programlisting>

      <para>Tous les attributs possèdent des valeurs par défaut convenables et dépendent des définitions de modules et de dépôts. Les attributs courants sont décrits ici.</para>

      <para>L'attribut <sgmltag class="attribute">repo</sgmltag> permet d'indiquer un nom de dépôt différent de la valeur par défaut.</para>

      <para>L'attribut <sgmltag class="attribute">module</sgmltag> permet d'indiquer un nom de module pour l'extraction du dépôt. Par défaut, c'est l'identifiant du module.</para>

      <para>L'attribut <sgmltag class="attribute">checkoutdir</sgmltag> permet d'indiquer le nom du dossier d'extraction. Par défaut, c'est l'identifiant du module.</para>

      <para>D'autres attributs sont décrits ci-dessous</para>

      <section id="moduleset-syntax-sources-bzr">
        <title>Bazaar</title>

        <para>Ce type de dépôt permet de définir un dépôt Bazaar. Il est recommandé de posséder une version de Bazaar 1.16 ou plus élevée.</para>

<programlisting>
&lt;repository type="bzr" name="launchpad.net"
      href="lp:"/&gt;
        </programlisting>

        <para>Voici des attributs supplémentaires : <sgmltag class="attribute">trunk-template</sgmltag> (égal à <literal>« %(module)s »</literal> par défaut) et <sgmltag class="attribute">branches-template</sgmltag> (égal à <literal>« %(branch)s »</literal> par défaut). Ces attributs sont utilisés pour indiquer des modèles dans la construction des URL. Un élément <sgmltag class="element">branch</sgmltag> dans les définitions de modules peut préciser des attributs <sgmltag class="attribute">branch</sgmltag> et <sgmltag class="attribute">user</sgmltag>. Ces valeurs sont substituées dans les modèles. Si l'un des deux est défini, c'est <sgmltag class="attribute">branches-template</sgmltag> qui est utilisé, sinon c'est <sgmltag class="attribute">trunk-template</sgmltag>. Ainsi, vous pouvez redéfinir un dépôt pour construire des modules à partir de votre branche personnelle ou construire plusieurs modules à partir d'un dépôt qui n'est pas structuré de manière standard.</para>

        <para>Un élément <sgmltag class="element">branch</sgmltag> supplémentaire accepte un attribut <sgmltag class="attribute">revspec</sgmltag> pour se fixer sur une révision particulière. N'importe quelle <literal>bzr revspec</literal> valide est acceptée, par exemple <literal>date:yesterday, -5, tag:0.1</literal> pour obtenir la première révision depuis hier, 5 commits derrière la tête (tip) ou l'étiquette « 0.1 ». Consultez <literal>bzr help revisionspec</literal> pour connaître toutes les valeurs possibles.</para>

        <para>Par exemple, un dépôt avec des attributs <sgmltag class="attribute">template</sgmltag> :</para>

<programlisting>
&lt;repository type="bzr" name="launchpad.net"
      href="lp:"
      trunk-template="~bzr-pqm/%(module)s/bzr.dev"
      branches-template="~bzr-pqm/%(module)s/%(branch)s"/&gt;
        </programlisting>

        <para>Des exemples d'éléments <sgmltag class="element">branch</sgmltag> pour le dépôt ci-dessus :</para>

<programlisting>
&lt;branch repo="launchpad.net"
      module="bzr"
      checkoutdir="bzr-next"/&gt;
        </programlisting>

<programlisting>
&lt;branch repo="launchpad.net"
      module="bzr"
      branch="2.2"
      checkoutdir="bzr-beta"/&gt;
        </programlisting>
      </section>

      <section id="moduleset-syntax-sources-cvs">
        <title>CVS</title>

        <para>Ce type de dépôt permet de définir un dépôt CVS.</para>

        <para>L'attribut <sgmltag class="attribute">password</sgmltag> permet d'indiquer le mot de passe pour accéder au dépôt.</para>

        <para>L'attribut <sgmltag class="attribute">cvsroot</sgmltag> permet d'indiquer la racine du dépôt.</para>

<programlisting>
&lt;repository type="cvs" name="tango.freedesktop.org"
    cvsroot=":pserver:anoncvs@anoncvs.freedesktop.org:/cvs/tango"
    password=""/&gt;
        </programlisting>

<!-- TODO describe these attributes -->

        <para>Attributs supplémentaires : <sgmltag class="attribute">revision</sgmltag>, <sgmltag class="attribute">update-new-dirs</sgmltag> et <sgmltag class="attribute">override-checkoutdir</sgmltag>.</para>
      </section>

      <section id="moduleset-syntax-sources-darcs">
        <title>Darcs</title>

        <para>Ce type de dépôt permet de définir un dépôt Darcs.</para>

<programlisting>
&lt;repository type="darcs" name="telepathy.freedesktop.org"
      href="http://projects.collabora.co.uk/darcs/telepathy/"/&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-sources-git">
        <title>Git</title>

        <para>Ce type de dépôt permet de définir un dépôt Git.</para>

<programlisting>
&lt;repository type="git" name="git.freedesktop.org"
    href="git://anongit.freedesktop.org/git/"/&gt;
        </programlisting>

        <para>Il autorise les attributs suivants sur l'élément <sgmltag class="element">branch</sgmltag> :</para>

        <para>L'attribut <sgmltag class="attribute">revision</sgmltag> est utilisé pour indiquer une branche locale ou qui suit une branche distante vers laquelle basculer lors de la phase de mise à jour. Par défaut, il contient « master ». Il est possible de redéfinir cet attribut avec la variable de configuration <varname>branches</varname>. Ce basculement ne se produit que si la branche actuelle suit une branche distante, afin de ne pas interférer avec votre propre développement.</para>

        <para>L'attribut <sgmltag class="attribute">tag</sgmltag> indique la révision à extraire absolument durant la phase de mise à jour. Il surcharge l'attribut <sgmltag class="attribute">revision</sgmltag>.</para>

<!-- TODO I can't say much about the subdir attribute. In the
        end it will just be appended to checkoutdir.
        https://bugzilla.gnome.org/show_bug.cgi?id=342846
        -->

<programlisting>
&lt;branch repo="git.freedesktop.org" module="swfdec/swfdec"
        checkoutdir="swfdec"
        revision="<replaceable>branche-locale-ou-distante</replaceable>"
        tag="<replaceable>étiquette</replaceable>"/&gt;
        </programlisting>
      </section>

      <section id="moduleset-syntax-sources-hg">
        <title>Mercurial</title>

        <para>Ce type de dépôt permet de définir un dépôt Mercurial.</para>

<programlisting>
&lt;repository type="hg" name="hg.gtk-vnc"
    href="http://gtk-vnc.codemonkey.ws/hg/" /&gt;
</programlisting>

<programlisting>
&lt;branch repo="hg.gtk-vnc" module="outgoing.hg" checkoutdir="gtk-vnc"/&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-sources-mtn">
        <title>Monotone</title>

        <para>Ce type de dépôt permet de définir un dépôt Monotone.</para>

        <para>L'attribut <sgmltag class="attribute">server</sgmltag> permet d'indiquer le serveur du dépôt.</para>

        <para>L'attribut <sgmltag class="attribute">database</sgmltag> permet d'indiquer la base de données à utiliser pour le dépôt.</para>

        <para>L'attribut <sgmltag class="attribute">defbranch</sgmltag> permet d'indiquer la branche à utiliser dans le dépôt.</para>

<programlisting>
&lt;repository type="mtn" name="pidgin.im"
    server="pidgin.im" database="pidgin.im.mtn"
    defbranch="im.pidgin.pidgin"/&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-sources-svn">
        <title>Subversion</title>

        <para>Ce type de dépôt permet de définir un dépôt Subversion.</para>

<programlisting>
&lt;repository type="svn" name="svn.gnome.org" default="yes"
    href="http://svn.gnome.org/svn/"/&gt;
        </programlisting>

<!-- So how do I checkut out branch at a specific revision? -->

        <para>Il autorise un attribut <sgmltag class="attribute">revision</sgmltag> sur l'élément <sgmltag class="element">branch</sgmltag>. Cet attribut définit la branche à extraire ou, si c'est un nombre, une révision spécifique à extraire.</para>

<programlisting>
&lt;branch revision="gnome-2-20"/&gt;
        </programlisting>

        <para>Il est possible de définir un agencement <literal>svn</literal> personnalisé en utilisant <sgmltag class="attribute">trunk-template</sgmltag> (qui vaut par défaut « %(module)s/trunk »), <sgmltag class="attribute">branches-template</sgmltag> (qui vaut par défaut « %(module)s/branches/%(branch)s ») et <sgmltag class="attribute">tags-template</sgmltag> (qui vaut par défaut « %(module)s/tags/%(tag)s »).</para>
      </section>

      <section id="moduleset-syntax-sources-tarball">
        <title>Tarballs (archives tar)</title>

        <para>Ce type de dépôt permet de définir un dépôt tarball.</para>

<programlisting>
&lt;repository type="tarball" name="dbus/dbus-python"
    href="http://dbus.freedesktop.org/releases/dbus-python/"/&gt;
</programlisting>

        <para>Il autorise les attributs suivants sur l'élément <sgmltag class="element">branch</sgmltag> :</para>

        <para>L'attribut <sgmltag class="attribute">module</sgmltag> indique le fichier à télécharger et compiler. L'attribut <sgmltag class="attribute">version</sgmltag> indique la version du module.</para>

        <para>Les attributs <sgmltag class="attribute">size</sgmltag> et <sgmltag class="attribute">hash</sgmltag>, ainsi que l'ancien attribut <sgmltag class="attribute">md5sum</sgmltag> sont facultatifs. Si ces attributs existent, ils sont utilisés pour vérifier que le paquet source a été correctement téléchargé.</para>

        <para>Any number of <sgmltag class="element">patch</sgmltag> elements
          may be nested inside the <sgmltag class="element">branch</sgmltag>
          element. These patches are applied, in order, to the source tree after
          unpacking. The <sgmltag class="attribute">file</sgmltag> attribute
          gives the patch filename, and the
          <sgmltag class="attribute">strip</sgmltag> attribute says how many
          levels of directories to prune when applying the patch.</para>

        <para>Pour les jeux de modules livrés avec JHBuild, les fichiers de correctifs sont situés dans le répertoire <filename>jhbuild/patches/</filename> ; pour les jeux de modules référencés par URI, les fichiers de correctifs doivent se trouver dans le même répertoire que le jeu de modules ou dans le sous-répertoire <filename>patches/</filename>. Il est aussi possible que l'attribut <sgmltag class="attribute">file</sgmltag> indique un URI, auquel cas il sera téléchargé à cet emplacement.</para>

<programlisting>
&lt;branch module="dbus-python-0.80.2.tar.gz" version="0.80.2"
    repo="dbus/dbus-python"
    hash="md5:2807bc85215c995bd595e01edd9d2077" size="453499"&gt;
  &lt;patch file="dbus-glib-build.patch" strip="1" /&gt;
&lt;/branch&gt;
</programlisting>

        <para>A tarball <sgmltag class="element">branch</sgmltag> element may
          also contain <sgmltag class="element">quilt</sgmltag> elements which
          specify nested <sgmltag class="element">branch</sgmltag> to import.
        </para>
      </section>
    </section>

    <section id="moduleset-syntax-includes">
      <title>Inclusion d'autres jeux de modules</title>

      <para>JHBuild autorise un jeu de modules à inclure le contenu d'un autre jeu de modules en le référençant au moyen de l'élément <sgmltag class="element">include</sgmltag>.</para>

<programlisting>
&lt;include href="<replaceable>uri</replaceable>"/&gt;
</programlisting>

      <para>L'attribut <sgmltag class="attribute">href</sgmltag> est une référence sous forme d'URI vers le jeu de modules à inclure, relatif au fichier contenant l'élément <sgmltag class="element">include</sgmltag>.</para>

      <para>Seules les définitions de modules sont importées à partir du jeu de modules référencé, et non pas les sources de modules. Plusieurs niveaux d'imbrication sont autorisés, mais pas les inclusions en boucle (il n'y a pas de code de détection de boucle pour l'instant).</para>
    </section>

    <section id="moduleset-syntax-defs">
      <title>Définitions de modules</title>

      <para>Il existe plusieurs types de définitions de modules utilisables dans un fichier de jeu de modules, et la liste peut facilement être augmentée. Seuls les types les plus courants sont mentionnés ici.</para>

      <para>À la base, ils sont tous formés d'un élément <sgmltag class="element">branch</sgmltag> décrivant la manière d'obtenir le module et d'éléments <sgmltag class="element">dependencies</sgmltag>, <sgmltag class="element">suggests</sgmltag> et <sgmltag class="element">after</sgmltag> pour déclarer les dépendances du module.</para>

      <para>Tout module mentionné dans l'élément <sgmltag class="element">dependencies</sgmltag> est ajouté à la liste des modules lors de la commande <command>jhbuild build</command> (s'il n'y est pas déjà) ; JHBuild s'assure que les modules dépendants soient construits en premier.</para>

      <para>Après avoir généré la liste des modules, les modules mentionnés dans l'élément <sgmltag class="element">suggests</sgmltag> sont utilisés pour trier la liste des modules (sans y ajouter de module supplémentaire). Ceci est prévu pour les cas où un module possède une dépendance facultative sur un autre module.</para>

      <section id="moduleset-syntax-defs-autotools">
        <title>autotools</title>

        <para>L'élément <sgmltag class="element">autotools</sgmltag> sert à définir un module qui doit être compilé à l'aide du système de construction GNU Autotools.</para>

<programlisting>
&lt;autotools id="<replaceable>id</replaceable>"
	      [ autogenargs="<replaceable>paramètres_autogen</replaceable>" ]
	      [ makeargs="<replaceable>paramètres_make</replaceable>" ]
	      [ makeinstallargs="<replaceable>paramètres_make_install</replaceable>" ]
	      [ autogen-sh="<replaceable>autogen-sh</replaceable>" ]
	      [ makefile="<replaceable>makefile</replaceable>" ]
	      [ skip-autogen="<replaceable>ignorer-autogen</replaceable>" ]
	      [ autogen-template="<replaceable>modèle_autogen</replaceable>" ]
	      [ check-target="<replaceable>cible_contrôle</replaceable>" ]
	      [ supports-non-srcdir-builds="<replaceable>gère_construction_non_srcdir</replaceable>" ]&gt;

  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/after&gt;

&lt;/autotools&gt;
</programlisting>

        <para>Les attributs <sgmltag class="attribute">autogenargs</sgmltag>, <sgmltag class="attribute">makeargs</sgmltag> et <sgmltag class="attribute">makeinstallargs</sgmltag> servent à indiquer des paramètres supplémentaires à transmettre respectivement à <command>autogen.sh</command>, <command>make</command> et <command>make install</command>.</para>

        <para>L'attribut <sgmltag class="attribute">autogen-sh</sgmltag> indique le nom du script autogen.sh à exécuter. La valeur <literal>autoreconf</literal> peut être utilisée si le module n'a pas d'équivalent du script <command>autogen.sh</command>. Dans ce cas, JHBuild exécutera <command>autoreconf -i</command>, suivi par la phase <command>configure</command>. L'attribut <sgmltag class="attribute">skip-autogen</sgmltag> indique s'il faut exécuter autogen.sh, il s'agit d'une valeur booléenne admettant également la valeur <literal>never</literal> pour signifier à JHBuild de ne jamais ignorer le lancement de <command>autogen.sh</command>. L'attribut <sgmltag class="attribute">makefile</sgmltag> indique le nom du fichier makefile à utiliser.</para>

        <para>L'attribut <sgmltag class="attribute">supports-non-srcdir-builds</sgmltag> sert à marquer les modules qui ne peuvent être proprement construits en utilisant un répertoire source séparé.</para>

        <para>L'attribut <sgmltag class="attribute">autogen-template</sgmltag> peut être utilisé en cas de besoin de contrôle fin sur la ligne de commande autogen. C'est une chaîne de formatage Python, qui sera substituée par les variables suivantes : <varname>srcdir</varname>, <varname>autogen-sh</varname>, <varname>prefix</varname>, <varname>libdir</varname>, et <varname>autogenargs</varname>. Par exemple, voici la valeur par défaut de autogen-template :</para>

<programlisting>
%(srcdir)s/%(autogen-sh)s --prefix %(prefix)s --libdir %(libdir)s %(autogenargs)s
</programlisting>

        <para>L'attribut <sgmltag class="attribute">check-target</sgmltag> doit être indiqué (avec la valeur « false ») pour les modules qui n'ont pas de cible <command>make check</command>.</para>
      </section>

      <section id="moduleset-syntax-defs-cmake">
        <title>cmake</title>

        <para>L'élément <sgmltag class="element">cmake</sgmltag> permet de définir un module construit à l'aide du système de construction CMake.</para>

<programlisting>
&lt;cmake id="<replaceable>nom_module</replaceable>"&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/cmake&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-defs-distutils">
        <title>distutils</title>

        <para>L'élément <sgmltag class="element">distutils</sgmltag> permet de définir un module construit à l'aide de Python distutils.</para>

<programlisting>
&lt;distutils id="<replaceable>nom_module</replaceable>"
            [ supports-non-srcdir-builds="<replaceable>yes|no</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/distutils&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-defs-linux">
        <title>linux</title>

        <para>L'élément <sgmltag class="element">linux</sgmltag> permet de définir un module utilisé pour construire un noyau linux. De plus, une configuration de noyau séparée peut être choisie en utilisant le sous-élément <sgmltag class="element">kconfig</sgmltag>.</para>

<programlisting>
&lt;linux id="<replaceable>id</replaceable>"
	  [ makeargs="<replaceable>paramètres_make</replaceable>" ]&gt;

  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/after&gt;

  &lt;kconfig [ repo="<replaceable>dépôt</replaceable>" ]
	    version="<replaceable>version</replaceable>"
	    [ module="<replaceable>module</replaceable>" ]
	    [ config="<replaceable>config</replaceable>" ] /&gt;

&lt;/linux&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-defs-perl">
        <title>perl</title>

        <para>L'élément <sgmltag class="element">perl</sgmltag> permet de construire des modules Perl.</para>

        <para>L'attribut <sgmltag class="attribute">makeargs</sgmltag> permet de définir des paramètres supplémentaires à passer à <command>make</command>.</para>

<programlisting>
&lt;perl id="<replaceable>nom_module</replaceable>"
	 [ makeargs="<replaceable>paramètres_make</replaceable>" ]&gt;

  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/after&gt;

&lt;/perl&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-defs-waf">
        <title>waf</title>

        <para>L'élément <sgmltag class="element">waf</sgmltag> permet de définir un module construit à l'aide du système de construction Waf.</para>

        <para>L'attribut <sgmltag class="attribute">waf-command</sgmltag> permet de définir le script de commande waf à utiliser ; la valeur par défaut est <command>waf</command>.</para>

<programlisting>
&lt;waf id="<replaceable>nom_module</replaceable>"&gt;
	 [ waf-command="<replaceable>commande_waf</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/waf&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-defs-testmodule">
        <title>testmodule</title>

        <para>L'élément <sgmltag class="element">testmodule</sgmltag> permet de créer un module qui exécute une suite de tests en utilisant LDTP ou Dogtail.</para>

<programlisting>
&lt;testmodule id="<replaceable>id</replaceable>"
	       type="<replaceable>type</replaceable>"&gt;

  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/after&gt;

  &lt;testedmodules&gt;
    &lt;tested package="<replaceable>paquet</replaceable>" /&gt;
  &lt;/testedmodules&gt;

&lt;/testmodule&gt;
</programlisting>

        <para>L'attribut <sgmltag class="attribute">type</sgmltag> indique le type de tests à exécuter dans le module. « dogtail » utilise Python pour appeler tous les fichiers .py. « ldtp » fait appel à « ldtprunner run.xml ».</para>

        <para>Tant que l'option de configuration noxvfb n'est pas définie, un serveur Xvfb est démarré pour y lancer les tests.</para>
      </section>

      <section id="moduleset-syntax-defs-metamodule">
        <title>metamodule</title>

        <para>L'élément <sgmltag class="element">metamodule</sgmltag> permet de définir un module qui ne fait vraiment rien. Le seul but d'un tel module est de définir des dépendances.</para>

        <para>Par exemple, meta-gnome-desktop dépend de tous les éléments clés du bureau GNOME. En conséquence, demander à JHBuild de l'installer revient à installer le bureau complet.</para>

<programlisting>
&lt;metamodule id="<replaceable>nom_module</replaceable>"&gt;
  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;suggests&gt;
    &lt;dep package="<replaceable>nom_module</replaceable>"/&gt;
    ...
  &lt;/suggests&gt;
&lt;/metamodule&gt;
</programlisting>

        <para>L'attribut <sgmltag class="attribute">id</sgmltag> donne le nom du module. Les éléments enfants sont traités de la même manière que <link linkend="moduleset-syntax-defs-autotools"><sgmltag class="element">autotools</sgmltag></link>.</para>
      </section>
    </section>

    <section id="moduleset-deprecated-elements">
      <title>Éléments désapprouvés</title>

      <section id="moduleset-deprecated-elements-syntax-sources">
        <title>Sources de module</title>

        <section id="moduleset-syntax-sources-cvsroot">
          <title>cvsroot</title>

          <para>L'élément <sgmltag class="element">cvsroot</sgmltag> est maintenant désapprouvé. Il faut utiliser l'élément <sgmltag class="element">repository</sgmltag> à la place.</para>

          <para>L'élément <sgmltag class="element">cvsroot</sgmltag> permet de décrire un dépôt CVS.</para>

<programlisting>
  &lt;cvsroot name="<replaceable>nom_racine</replaceable>"
           [ default="<replaceable>yes|no</replaceable>" ]
           root="<replaceable>cvsroot_anon</replaceable>"
           password="<replaceable>mot_de_passe_anon</replaceable>"/&gt;
</programlisting>

          <para>L'attribut <sgmltag class="attribute">name</sgmltag> doit être un identifiant unique pour le dépôt CVS.</para>

          <para>L'attribut <sgmltag class="attribute">default</sgmltag> indique si cette source de module est la source par défaut pour ce fichier de jeu de modules.</para>

          <para>L'attribut <sgmltag class="attribute">root</sgmltag> contient la racine CVS utilisée pour l'accès anonyme à ce dépôt, et l'attribut <sgmltag class="attribute">password</sgmltag> précise le mot de passe utilisé pour l'accès anonyme.</para>
        </section>

        <section id="moduleset-syntax-sources-svnroot">
          <title>svnroot</title>

          <para>L'élément <sgmltag class="element">svnroot</sgmltag> est maintenant désapprouvé. Il faut utiliser l'élément <sgmltag class="element">repository</sgmltag> à la place.</para>

          <para>L'élément <sgmltag class="element">svnroot</sgmltag> permet de décrire un dépôt Subversion.</para>

<programlisting>
  &lt;svnroot name="<replaceable>nom_racine</replaceable>"
           [ default="<replaceable>yes|no</replaceable>" ]
           href="<replaceable>svnroot_anonyme</replaceable>"/&gt;
</programlisting>

          <para>L'attribut <sgmltag class="attribute">name</sgmltag> doit être un identifiant unique pour le dépôt Subversion.</para>

          <para>L'attribut <sgmltag class="attribute">default</sgmltag> indique si cette source de module est la source par défaut pour ce fichier de jeu de modules.</para>

          <para>L'attribut <sgmltag class="attribute">href</sgmltag> contient l'URL de base du dépôt. En général, c'est un URL <literal>http</literal>, <literal>https</literal> ou <literal>svn</literal>.</para>
        </section>
      </section>

<!-- end of deprecated module sources -->

      <section>
        <title>Types de modules désapprouvés</title>

        <warning>
          <para>Cette section présente des éléments désapprouvés. Il se peut qu'ils soient encore utilisés dans des jeux de modules existants, mais il est conseillé de ne plus les utiliser.</para>
        </warning>

        <section id="moduleset-syntax-defs-tarball">
          <title>tarball</title>

          <important>
            <para>Cet élément désapprouvé est une simple couche fine autour du type de module <sgmltag class="element">autotools</sgmltag> et du type de dépôt <sgmltag class="element">tarball</sgmltag>.</para>
          </important>

          <para>L'élément <sgmltag class="element">tarball</sgmltag> permet de définir un module à construire à partir d'une archive tar.</para>

<programlisting>
  &lt;tarball id="<replaceable>nom_de_module</replaceable>"
              [ version="<replaceable>version</replaceable>" ]
              [ checkourdir="<replaceable>répertoire_extraction</replaceable>" ]
              [ autogenargs="<replaceable>paramètres_autogen</replaceable>" ]
              [ makeargs="<replaceable>paramètres_make</replaceable>" ]
              [ autogen-sh="<replaceable>autogen-sh</replaceable>" ]
              [ supports-non-srcdir-builds="<replaceable>yes|no</replaceable>" ]&gt;
    &lt;source href="<replaceable>url_source</replaceable>"
            [ size="<replaceable>taille_source</replaceable>" ]
            [ hash="<replaceable>algorithme_source:hash_source</replaceable>" ]
            [ md5sum="<replaceable>somme_md5_source</replaceable>" ]/&gt;
    &lt;patches&gt;
      &lt;patch file="<replaceable>nom_de_fichier</replaceable>" strip="<replaceable>niveau</replaceable>"/&gt;
      ...
    &lt;/patches&gt;
    &lt;dependencies&gt;
      &lt;dep package="<replaceable>nom_de_module</replaceable>"/&gt;
      ...
    &lt;/dependencies&gt;
    &lt;suggests&gt;
      &lt;dep package="<replaceable>nom_de_module</replaceable>"/&gt;
      ...
    &lt;/suggests&gt;
  &lt;/tarball&gt;
</programlisting>

          <para>Les attributs <sgmltag class="attribute">id</sgmltag> et <sgmltag class="attribute">version</sgmltag> sont utilisés pour identifier le module.</para>

          <para>L'élément <sgmltag class="element">source</sgmltag> indique le fichier à télécharger et compiler. L'attribut <sgmltag class="attribute">href</sgmltag> est obligatoire, alors que les attributs <sgmltag class="attribute">size</sgmltag> et <sgmltag class="attribute">hash</sgmltag>, comme l'attribut obsolète <sgmltag class="attribute">md5sum</sgmltag>, sont facultatifs. Si ces deux derniers attributs sont présents, ils sont utilisés pour vérifier que le paquet source a été correctement téléchargé.</para>

          <para>L'élément <sgmltag class="element">patches</sgmltag> sert à indiquer un ou plusieurs correctifs à appliquer à l'arborescence source après décompression. L'attribut <sgmltag class="attribute">file</sgmltag> indique le nom de fichier du correctif et l'attribut <sgmltag class="attribute">strip</sgmltag> précise le nombre de niveaux de répertoires à retirer dans les chemins en appliquant le correctif.</para>

          <para>Pour les jeux de modules livrés avec JHBuild, les fichiers de correctifs sont situés dans le répertoire <filename>jhbuild/patches/</filename> ; pour les jeux de modules référencés par URI, les fichiers de correctifs doivent se trouver dans le même répertoire que le jeu de modules ou dans le sous-répertoire <filename>patches/</filename>. Il est aussi possible que l'attribut <sgmltag class="attribute">file</sgmltag> indique un URI, auquel cas il sera téléchargé à cet emplacement.</para>

          <para>Les autres attributs et les éléments <sgmltag class="element">dependencies</sgmltag>, <sgmltag class="element">suggests</sgmltag> et <sgmltag class="element">after</sgmltag> sont traités de la même manière que pour <link linkend="moduleset-syntax-defs-autotools">autotools</link>.</para>
        </section>
      </section>

<!-- end of deprecated module types -->
    </section>

<!-- end of deprecated elements -->
  </section>
</article>
