# Manuel de JHBuild

James
Henstridge
C.J.
Adams-Collier
Frederic
Peters
David
Turner
2004, 2008
James Henstridge
JHBuild Manual v0.5
January 2008
JHBuild Manual v0.1
August 2007

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.

## Introduction

JHBuild est un outil conçu pour faciliter la compilation d'ensembles de paquets source, appelés modules. 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.

JHBuild a été d'abord créé pour compiler GNOME, 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.

JHBuild can build modules from a variety of sources, including CVS, Subversion, Bazaar, Darcs, Git and Mercurial 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, Meson, WAF, Python Distutils and Perl Makefiles.

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.

## Premiers pas

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.

### Installation de JHBuild

JHBuild requires a Python runtime. Verify Python >= 3.5 is installed.

The recommended way to download JHBuild is via the version control system, `git`. This can be achieved with the following command. It is recommended to run the command from a new directory where all source code will be installed, for example, `~/jhbuild/checkout`.

    $ git clone https://gitlab.gnome.org/GNOME/jhbuild.git
    ...
    $

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

    $ cd jhbuild
    $ ./autogen.sh
    ...
    $ make
    ...
    $ make install
    ...
    $

If gnome-common, yelp-tools and autotools are available, `autogen.sh` will configure JHBuild to install via autotools. If gnome-common, yelp-tools and autotools are not available, `autogen.sh` will configure JHBuild to install via a plain Makefile. To always use the plain Makefile method pass `--simple-install` to `autogen.sh`.

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

    $ PATH=$PATH:~/.local/bin
    $

Pour ajouter `~/.local/bin` de façon permanente à la variable `PATH`, exécutez la commande suivante :

    $ echo 'PATH=$PATH:~/.local/bin' >> ~/.bashrc
    $

### Configuration de JHBuild

JHBuild can be configured via a configuration file. The default location is `~/.config/jhbuildrc`. If a configuration file does not exist, the defaults are used. The configuration file uses Python syntax. An example is provided, see `examples/sample.jhbuildrc`. Copy `examples/sample.jhbuildrc` to `~/.config/jhbuildrc` and customize as required.

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

Les variables de configuration sont documentées dans . En voici quelques-unes parmi les plus utilisées :

`repos`

  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 :

      repos['git.gnome.org'] = 'ssh://nom_utilisateur@git.gnome.org/git/'

`moduleset`

  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.

`modules`

  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 `buildone` command is used. Defaults to `['meta-gnome-desktop']`.

`checkoutroot`

  A string specifying the directory to unpack source trees to. If `buildroot` is set to `None`, builds will occur in this directory too. Defaults to `~/jhbuild/checkout`.

`prefix`

  A string specifying the prefix to install modules to. `prefix` must be an absolute path. This directory must be writable. Defaults to `'~/jhbuild/install/'`.

`autogenargs`

  A string containing arguments passed to the `autogen.sh` script of all modules. Can be overridden for particular modules using the `module_autogenargs` dictionary.

`cmakeargs`

  A string containing arguments passed to the `cmake` invocation of all modules. Can be overridden for particular modules using the `module_cmakeargs` dictionary.

`makeargs`

  A string listing additional arguments to be passed to `make`. JHBuild will automatically append the parallel execution option (`-j`) based upon available CPU cores. Defaults to `''`.

`mesonargs`

  A string containing arguments passed to the `meson` invocation of all modules. Can be overridden for particular modules using the `module_mesonargs` dictionary.

`ninjaargs`

  A string listing additional arguments to be passed to `ninja`. Defaults to `''`.

### Prérequis pour la construction

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

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

    $ jhbuild sanitycheck

If this command displays any messages, please install the required package from your distribution's repository. A list of package names for different distributions is maintained on the GNOME wiki. Run the `sanitycheck` command again after installing the distribution's packages to ensure the required tools are present.

### Utilisation de JHBuild

After set up is complete, JHBuild can be used to build software. To build all the modules selected in the `~/.config/jhbuildrc` file, run the following command:

    $ jhbuild build

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.

L'abandon d'un module provoque l'échec de construction de tout module dépendant de ce module.

Voici un exemple de menu qui est affiché :

      [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"
    choice:

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 `build`. Par exemple, pour construire gtk+ :

    $ jhbuild build gtk+

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 `--start-at` :

    $ jhbuild build --start-at=pango

Pour construire un ou plusieurs modules en ignorant leurs dépendances, JHBuild fournit la commande `buildone`. 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.

    $ jhbuild buildone gtk+

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

    $ jhbuild make

Pour obtenir une liste ordonnancée des modules et des dépendances que JHBuild va construire, utilisez la commande `list` :

    $ jhbuild list

Pour obtenir des informations sur un module particulier, utilisez la commande `info` :

    $ jhbuild info gtk+

Pour télécharger ou mettre à jour toutes les sources de logiciels sans rien compiler, utilisez la commande `update`. 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.

    $ jhbuild update

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

    $ jhbuild build --no-network

Pour lancer une commande précise dans le même environnement utilisé par JHBuild, utilisez la commande `run` :

    $ jhbuild run program

Pour lancer un shell avec l'environnement utilisé par JHBuild, utilisez la commande `shell` :

    $ jhbuild shell

## JHBuild et GNOME

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

### Construction de GNOME

Pour compiler GNOME, certains paquets de développement sont nécessaires, notamment :

- La DTD DocBook XML et les feuilles de styles XSLT. Elles doivent être enregistrées dans le catalogue XML (`/etc/xml/catalog`).

- X libraries.

- `libsmbclient` de Samba (utilisé pour parcourir les réseaux Windows).

- `libbz2` de bzip2.

- `libpng`, `libjpeg` et `libtiff` (utilisés pour le chargement d'images).

Si vous installez des paquets de votre distribution et si cela s'applique à votre distribution, installez les paquets dev ou devel correspondants. Une liste de noms de paquets de différentes distributions est disponible sur le wiki de GNOME.

### Lancement d'une application GNOME unique

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 .

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

    $ jhbuild shell

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

    $ which gedit
    /home/wanda/jhbuild/install/bin/gedit

lancez l'application :

    $ gedit &

Il est aussi possible de lancer l'application en utilisant la commande `run` :

    $ jhbuild run gedit

### Lancement de l'environnement de bureau GNOME

Create a new user account to run the JHBuild GNOME. Running JHBuild GNOME using a different user account is recommended to avoid problems caused by user settings stored in the home directory. This manual refers to the new account as gnomedev.

Setup JHBuild on the new gnomedev account. Copy or soft-link `~/.config/jhbuildrc` and `~/.local/bin/jhbuild` to gnomedev home directory.

Ouvrez un terminal en tant qu'utilisateur gnomedev. Ajoutez `~/.local/bin` de façon permanente à la variable `PATH` en exécutant la commande suivante :

    $ echo 'PATH=$PATH:~/.local/bin' >> ~/.bashrc

Testez que JHBuild fonctionne :

    $ jhbuild run pkg-config gtk+-2.0 --modversion
    2.20.1

#### Configuration de GNOME en mode « gestionnaire d'affichage »

Compilez et installez GNOME JHBuild.

Enable system services. JHBuild GNOME will use the `/usr/bin` system D-Bus daemon and the system services within `/usr/share/dbus-1/system-services/`. JHBuild GNOME will use the JHBuild session D-Bus daemon and the services within `~/jhbuild/install//share/dbus-1/services/`. Replace `~/jhbuild/install` with GNOME install `prefix` in the command below:

    $ rm -rf ~/jhbuild/install/var/run/dbus
    $ ln -s /var/run/dbus ~/jhbuild/install/var/run/dbus
    $ rm -rf ~/jhbuild/install/var/lib/dbus/machine-id
    $ ln -s /var/lib/dbus/machine-id ~/jhbuild/install/var/lib/dbus/machine-id

Create a GNOME startup script at `/usr/bin/gnome-jhbuild-session` with the following, replacing `~/jhbuild/install` with GNOME install `prefix`:

    #!/bin/sh

    GNOME=~/jhbuild/install

    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

Rendez exécutable le fichier `/usr/bin/gnome-jhbuild-session` :

    $ chmod a+x /usr/bin/gnome-jhbuild-session

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

    [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

Redémarrez `gdm`.

#### Lancement de GNOME depuis le gestionnaire d'affichage

To run the JHBuild GNOME, select the GNOME (JHBuild) session at the display manager before entering gnomedev login credentials. If successful, JHBuild GNOME will be displayed. If unsuccessful, check the log file. The log file will be located at `~gnomedev/.cache/gdm/session.log` or `~gnomedev/.xsession-errors`.

### Static Analysis

JHBuild supports running static analysis tools on the code in modules as they’re built. To enable this, set the `static_analyzer` configuration variable to `True` in the `.jhbuildrc` configuration file.

If enabled, every time a module is built using JHBuild, the build process will be wrapped in a static analyzer, which will generate a report of any problems it finds with the code. These reports are saved as HTML files in subdirectories of `/tmp/jhbuild_static_analyzer` (by default; the path can be changed using the `static_analyzer_outputdir` configuration variable).

Static analysis currently only works for modules which use autotools as their build system. It requires the `scan-build` program to be installed, although the command it uses can be changed by modifying the `static_analyzer_template` configuration variable.

## Référence des commandes

JHBuild utilise une syntaxe de ligne de commande similaire aux outils du style CVS :

    jhbuild
          global-options
          command
          command-arguments

Les options globales de JHBuild sont :

`-f`, `--file` config

  Use an alternative configuration file instead of the default `~/.config/jhbuildrc`.

`-m`, `--moduleset` moduleset

  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.

`--no-interact`

  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.

`--exit-on-error`

  Exit immediately if a module fails to build. This option is primarily useful in noninteractive mode, in order to ensure jhbuild does not continue to build any additional modules.

`--conditions`

  Modify the condition flags to be different than those determined on the basis of the OS and those specified in jhbuildrc. Modifications are specified like `-wayland` or `+docs` in order to remove or add conditions. Multiple modifications can be separated by a comma like `--conditions=+docs,-wayland` or you can split them across multiple `--conditions` arguments.

Additionally, JHBuild checks the presence, and value, of the following environment variables:

`JHBUILD_RUN_AS_ROOT`

  By default, JHBuild does not run when using the root user, to avoid destructive operations that may affect the whole system. In certain cases, though, it's acceptable to run JHBuild as root; for instance, inside a container, or in a continuous integration environment. Exporting the `JHBUILD_RUN_AS_ROOT` will disable the user id check at startup.

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

### autobuild

La commande `autobuild` construit automatiquement les modules indiqués dans le fichier de configuration, puis envoie les résultats vers JHAutobuild.

    jhbuild autobuild
            --autogen
            --clean
            --distcheck
            --skip=module
            --start-at=module
            --report-url=reporturl
            --verbose

Les options `--autogen`, `--clean`, `--distcheck`, `skip` et `--start-at` sont traitées de la même manière que dans la commande `build`.

`--report-url=url-de-rapport`, `-r url-de-rapport`

  Cette option indique l'URL de JhAutobuild où envoyer le rapport.

`--verbose`, `-v`

  Si indiquée, cette option produit des messages de JHBuild plus verbeux.

### bootstrap

The `bootstrap` command installs a set of build utilities. The build utilities include autoconf, automake and similar utilities. The recommended method to install the build utilities is via your distribution's package management system. The `bootstrap` should only be used if the build utilities are not provided by your distribution's package management system, for example on Mac OS.

    jhbuild bootstrap

La commande `bootstrap` construit les modules avec la même méthode que la commande `build`, mais en utilisant le jeu de modules `bootstrap.modules`.

Consultez la documentation de la commande `build` pour connaître les options disponibles.

### build

La commande `build` construit un ou plusieurs paquets ainsi que leurs dépendances.

    jhbuild build
            --autogen
            --clean
            --check
            --dist
            --distcheck
            --distclean
            --ignore-suggests
            --no-network
            --skip=module
            --start-at=module
            --tags=tags
            -D date
            --no-xvfb
            --try-checkout
            --no-poison
            --force
            --build-optional-modules
            --min-age=time
            --nodeps
            module

Si aucun nom de module n'est indiqué dans la ligne de commande, c'est la liste des modules du fichier de configuration qui est utilisée.

`-a`, `--autogen`

  Always run `autogen.sh` before building modules.

`-c`, `--clean`

  Exécute `make clean` avant de construire les modules.

`--check`

  Exécute `make check` après la construction des modules.

`-d`, `--dist`

  Exécute `make dist` après la construction des modules.

`--distcheck`

  Exécute `make distcheck` après la construction des modules.

`--distclean`

  For git modules, run `git clean -dfx` before building modules. For other modules, run `make distclean` before building modules.

  This option will delete any uncommitted changes.

`--ignore-suggests`

  Ne compile pas les dépendances faibles.

`-n`, `--no-network`

  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.

`-s`, `--skip`=module,...

  Ne compile pas les modules de la liste. Utilisé pour éviter la construction de dépendances spécifiques.

`--tags`=étiquette,...

  Ignore les modules qui ne correspondent pas à étiquette. Une étiquette correspondant au nom du jeu de modules conteneur est automatiquement attribuée à chaque module.

`-t`, `--start-at`=module

  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é.

`-D` date

  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 `"2009-09-18 02:32Z"`.

`-x`, `--no-xvfb`

  Effectue les tests graphiques avec le serveur X réel au lieu d'utiliser une simulation Xvfb.

`-C`, `--try-checkout`

  Si la construction échoue et que le système de gestion de version le prend en charge, force une extraction et exécute `autogen.sh` avant de recommencer la construction.

`-N`, `--no-poison`

  Si l'une ou plusieurs des dépendances du module échouent, cette option force JHBuild à essayer tout de même de construire le module.

`-f`, `--force`

  Construit les modules même si la stratégie habituelle indique que ce n'est pas nécessaire.

`--build-optional-modules`

  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.

`--min-age`=temps

  Ignore les modules installés plus récemment que l'intervalle de temps donné. Le format de la chaîne temps est un nombre suivi d'une unité. Les unités reconnues sont : secondes (s), minutes (m), heures (h) et jours (d). Par exemple, `--min-age=2h` ignore les modules construits il y a moins de deux heures.

`--nodeps`

  Ignore missing system dependencies. To ignore a single system dependency add the module to `skip`.

### make

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

    jhbuild make
            --clean
            --check
            --distcheck
            --quiet

The options are the same as those available for the `buildone` command.

### buildone

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

    jhbuild buildone
            --autogen
            --clean
            --check
            --distcheck
            --distclean
            --no-network
            -D date
            --no-xvfb
            --force
            --min-age=time
            --nodeps
            module

The `--autogen`, `--check`, `--clean`, `-d`, `--distcheck`, `--distclean`, `--no-network`, `-D`, `-x` and `--nodeps` options are processed as per the `build` command.

Cette commande nécessite au minimum un module dans la ligne de commande.

### checkbranches

La commande `checkbranches` 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.

    jhbuild checkbranches
            --branch=branch

`--branch`=branch, `-b` branch

  La branche à vérifier

    $ jhbuild -m gnome-2.20 checkbranches
    libgnomecanvas is missing branch definition for gnome-2-20
    $

### clean

La commande `clean` nettoie les répertoires de compilation d'un ou de plusieurs modules.

    jhbuild clean
            --skip=module
            --start-at=module

Si aucun nom de module n'est indiqué dans la ligne de commande, c'est la liste des modules du fichier de configuration qui est utilisée.

Consultez la documentation de la commande `build` pour une description des options disponibles.

### dot

La commande `dot` 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 GraphViz pour produire un diagramme.

    jhbuild dot
            --soft-deps
            --clusters
            module

Si aucun nom de module n'est indiqué dans la ligne de commande, c'est la liste des modules du fichier de configuration qui est utilisée.

L'option `--soft-deps` ajoute des lignes pointillées depuis les modules vers leurs dépendances faibles. L'option `--clusters` groupe les modules selon les métamodules.

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

    $ jhbuild dot modules | dot -Tps > dependencies.ps

Ou une image PNG :

    $ jhbuild dot modules | dot -Tpng > dependencies.png

#### Exemple de sortie dot de JHBuild

### gui

La commande `gui` lance une interface graphique de JHBuild qui permet de sélectionner des modules à construire et de modifier certaines options.

    jhbuild gui

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

### info

La commande `info` affiche des informations sur un ou plusieurs modules.

    jhbuild info
              --installed
              module

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.

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.

If the `--installed` option is specified, the output will be filtered to include only installed packages. This resulting output only contains modules that were actually built and installed by jhbuild. The output does not include system dependencies.

If the `--installed` option is specified together with one or more module names, then only the installed modules (not including system dependencies) are printed out. If at least one module is not installed, then the command will exit with a return value of 1.

### list

La commande `list` affiche la liste complète des modules que la commande `build` construirait.

    jhbuild list
            -a
            -r
            -s
            --start-at=module
            --tags=tags
            --ignore-suggests
            --list-optional-modules
            module

Si aucun nom de module n'est indiqué dans la ligne de commande, c'est la liste des modules du fichier de configuration qui est utilisée.

Les options `--skip`, `--start-at`, `--tags` et `--ignore-suggests` sont traitées de la même manière que pour la commande `build`.

`-a`, `--all-modules`

  Énumère tous les modules du jeu de modules, sans tenir compte des dépendances de construction.

`-r`, `--show-revision`

  Si un module est défini par une de ses branches, affiche le nom de la branche avec le nom de module.

`--list-optional-modules`

  Cette option force JHBuild à énumérer les dépendances facultatives.

### rdepends

La commande `rdepends` affiche les dépendances inverses d'un module.

    jhbuild rdepends
            module

`--dependencies`

  Affiche le chemin de dépendance à la suite des modules.

`--direct`

  Limite l'affichage aux modules dépendant directement du module indiqué.

### run

La commande `run` exécute la commande indiquée dans le même environnement que JHBuild utilise lors de la construction de modules.

    jhbuild run
            --in-builddir
            --in-checkoutdir
            program
            argument

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

`--in-builddir`=module

  Exécute la commande dans le répertoire de construction du module indiqué.

`--in-checkoutdir`=module

  Exécute la commande dans le répertoire source du module indiqué.

### sanitycheck

La commande `sanitycheck` effectue un certain nombre de contrôles pour vérifier que l'environnement de construction est correct.

    jhbuild sanitycheck

Ces contrôles vérifient notamment que :

- les préfixes d'extraction et d'installation sont accessibles en écriture ;

- les outils de construction indispensables sont installés ;

- certaines macros couramment utilisées sont disponibles dans les chemins de recherche des commandes `aclocal` associées aux différentes versions de `automake` ;

- le catalogue XML contient les DTD et feuilles de style DocBook.

### shell

La commande `shell` lance un shell utilisateur dans le même environnement que JHBuild lorsqu'il construit des modules.

    jhbuild shell

Cette commande est équivalente à ceci :

    $ jhbuild run $SHELL

La variable d'environnement `UNDER_JHBUILD` 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 `.bashrc` :

    	if [ -n "$UNDER_JHBUILD" ]; then
    	    PS1="[jhbuild] $PS1"
    	fi

En conséquence, vous verrez apparaître la séquence `[jhbuild]` 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.

### sysdeps

The `sysdeps` command displays:

1. a list of installed system packages which will be used during the build. JHBuild will not build these modules and opt to use the system package instead.

2. a list of required packages. To begin a build the packages must be provided by your system.

3. a list of optional packages. The corresponding system package was not found or too old. JHBuild will build the module. Optional packages will not be displayed if `partial_build` is `False`.

    jhbuild sysdeps
            --install

`--install`

  This option installs system packages which are dependencies of the moduleset. The installation method depends on your distribution. System packages are installed using PackageKit, if available. For distributions using APT such as Debian and Ubuntu, this option requires apt-file to be installed.

#### Exemple de `sysdeps`

    $ jhbuild sysdeps
    System installed packages which are new enough:
      speex (speex.pc required=1.2rc1, installed=1.2rc1)
      lcms2 (lcms2.pc required=2.2, installed=2.2)
    ...
    Required packages:
      System installed packages which are too old:
        (none)
      No matching system package installed:
        zlib (zlib.pc required=1.2)
    Optional packages: (JHBuild will build the missing packages)
      System installed packages which are too old:
        WebKit (webkitgtk-3.0.pc required=1.5.1, installed=1.4.0)
        ...
      No matching system package installed:
        pulseaudio (libpulse.pc required=2.0)
        ...

### tinderbox

La commande `tinderbox` est semblable à la commande `build`, 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.

    jhbuild tinderbox
            --autogen
            --clean
            --distclean
            --no-network
            --output=directory
            --skip=module
            --start-at=module
            -D date
            -C
            -N
            -f
            --nodeps
            module

The `--autogen`, `--clean`, `--distclean`, `--no-network`, `--skip`, `--start-at`, `-D`, `-C`, `-N`, `-f` and `--nodeps` options are processed as per the `build` command.

`-o`, `--output`=répertoire

  The directory to write the HTML files. JHBuild will create an index (`index.html`) and a HTML file for each module.

### uninstall

La commande `uninstall` désinstalle un ou plusieurs modules.

    jhbuild uninstall
            module

### update

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

    jhbuild update
            --skip=module
            --start-at=module
            --tags=tags
            --ignore-suggests
            -D date
            module

Les options `--skip`, `--start-at`, `--tags`, `--ignore-suggests` et `-D` sont traitées de la même manière que pour la commande `build`.

### updateone

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

    jhbuild updateone
            -D date
            module

L'option `-D` est traitée de la même manière que pour `build`.

Cette commande nécessite au minimum un module dans la ligne de commande.

## Référence du fichier de configuration

The `~/.config/jhbuildrc` file uses standard Python syntax. The file is run, and the resulting variables defined in the namespace are used to control how JHBuild acts. A set of default values are inserted into the namespace before running the user's configuration file.

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

    use_local_modulesets = True

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

    autogenargs = '--disable-static --disable-gtk-doc'

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

    skip = ['mozilla', 'pulseaudio']

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

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

### Variables de configuration

`alwaysautogen`

  A boolean value if set to `True`, always run `autogen.sh`. This is equivalent to passing `--autogen` option to JHBuild. Defaults to `False`.

`autogenargs`

  Une chaîne contenant des paramètres passés au script `autogen.sh` de tous les modules. Peut être surchargée par des modules précis en utilisant le dictionnaire `module_autogenargs`.

`branches`

  Un dictionnaire précisant la branche utilisée pour un module particulier. C'est utile si vous effectuez certaines modifications sur la branche d'un module et que vous souhaitez que JHBuild construise cette branche au lieu de celle qui est indiquée dans le jeu de modules.

  La définition des branches dépend du gestionnaire de version du module :

  - CVS : révision. Par ex. `'BRANCH-PROJECT-0_8'`

  - Bazaar : URI de la branche du module. Par ex. `'http://bzr.example.net/project/gnome-2-28'`

  - 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. `('git://git.example.net/project', 'gnome-2-28')`

    #### Exemple simple

        branches['modulename'] = (None, 'branchname')

  - Subversion: URI of module branch. E.g. `'svn://svn.example.net/project/gnome-2-28'`

`builddir_pattern`

  Un motif de formatage du style `printf` utilisé pour générer les noms des répertoires de construction. Ceci est uniquement valable lors de l'utilisation d'arborescences source et de construction séparées. L'expression `%s` dans la chaîne de formatage est remplacée par `checkoutdir`. La valeur par défaut est `'%s'`.

`buildroot`

  A string specifying the parent directory to place build trees. Defaults to `~/.cache/jhbuild/build`. Setting the value to `None` causes builds to be performed within the source trees.

`buildscript`

  Une chaîne indiquant le script de construction à utiliser. La valeur recommandée est la valeur par défaut, `terminal`. En particulier, n'indiquez pas `gtk`.

`build_policy`

  Une chaîne indiquant les modules à construire. Les trois options possibles sont `all` pour construire tous les modules référencés, `updated` pour ne construire que les modules qui ont subi des modifications ou `updated-deps` pour construire les modules modifiés ou qui ont des dépendances qui ont été modifiées. La valeur par défaut est `updated-deps`.

`checkoutroot`

  Une chaîne indiquant le répertoire dans lequel décompresser les arborescences source. À moins que `buildroot` ne soit défini, la construction s'opère également dans ce répertoire. La valeur par défaut est `~/checkout/gnome`.

`checkout_mode`

  A string specifying how the checkout is performed for directories in version control. Defaults to `update`. This can be set per module using `module_checkout_mode`. Possible values are `update` (update checkout directory), `clobber` (wipe out directory before checking out the sources), `export` (wipe out directory then create a tarball of the sources containing any patches) and `copy` (checkout in a directory different from the one it will build).

`cmakeargs`

  A string containing arguments passed to the `cmake` invocation of all modules. Can be overridden for particular modules using the `module_cmakeargs` dictionary. Defaults to `''`.

`copy_dir`

  A string specifying the directory to copy to, if the copy `checkout_mode` is in use. Defaults to the checkout directory.

`export_dir`

  A string specifying the directory to export to, if the export `checkout_mode` is in use. Defaults to the checkout directory.

`cvs_program`

  Une chaîne indiquant le programme à utiliser pour la prise en charge de CVS. Cela peut être `git-cvsimport` ou `cvs`. La valeur par défaut est `cvs`.

`disable_Werror`

  A boolean value (default `True`) which controls if `--disable-Werror` will be passed to automake builds. Many packages use this flag as a way to disable fatal compiler warnings. The value of `True` is selected as a reasonable default for those using jhbuild as a means to get an up-to-date version of software packages without being side-tracked by build failures in other people's modules. Setting this value to `False` may make sense for those using jhbuild as part of a continuous integration or testing system.

`dvcs_mirror_dir`

  Une chaîne précisant un répertoire de miroir local. JHBuild créera des miroirs locaux des dépôts dans le répertoire précisé. Les miroirs peuvent être partagés par plusieurs groupes de dépôts, économisant ainsi de l'espace et du temps parce que des liens en dur seront utilisés pour les clones locaux. Les commandes `update` et `updateone` créeront les miroirs et récupéreront les nouveaux commits des dépôts en ligne. Cette option n'est prise en charge que pour les dépôts Git et Bazaar.

`exit_on_error`

  A boolean value specifying whether to exit immediately when a module fails to build. This is primarily useful in noninteractive mode, in order to prevent additional modules from building after one fails. Setting this value to `True` is equivalent to passing the `--exit-on-error` option. Defaults to `False`.

`extra_prefixes`

  A list of strings specifying, in precedence order, the list of extra prefixes. JHBuild sets many environment variables (such as `LD_LIBRARY_PATH`, `PKG_CONFIG_PATH` and `XDG_DATA_DIRS`) based on the `prefix` variable. Adding directories to `extra_prefixes` will cause these prefixes to be included as well, at a lower precedence than the JHBuild `prefix`, but at a higher precedence than system directories. This variable is empty by default except on systems that install software in `/usr/local`, in which case it contains this directory.

`help_website`

  A tuple specifying a help website name and URL. The website is displayed in the tinderbox html for failed modules. `%(module)s` in the URL will be replaced with the module name. To disable, set `help_website` to `None`. Defaults to `('Gnome Live!', 'http://live.gnome.org/JhbuildIssues/%(module)s')`.

`installprog`

  A string specifying a program to use as replacement for `/usr/bin/install`.

`ignore_suggests`

  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 `False`.

`interact`

  Une valeur booléenne indiquant si l'interaction avec l'utilisateur est autorisée. La définition de cette valeur à `False` équivaut à passer l'option `--no-interact` à JHBuild. La valeur par défaut est `True`.

`makeargs`

  A string listing additional arguments to be passed to `make`. JHBuild will automatically append the parallel execution option (`-j`) based upon available CPU cores. Defaults to `''`.

`makecheck`

  Une valeur booléenne indiquant s'il faut exécuter `make check` après `make`. La valeur par défaut est `False`.

`makecheck_advisory`

  Une valeur booléenne indiquant si les échecs d'exécution de la commande `make check` doivent être considérés comme des avertissements ou s'ils produisent un échec de la construction. La valeur par défaut est `False`.

`makeclean`

  Une valeur booléenne indiquant s'il faut exécuter `make clean` après `make`. La valeur par défaut est `False`.

`makedist`

  Une valeur booléenne indiquant s'il faut exécuter `make dist` après `make`. La valeur par défaut est `False`. Ce réglage équivaut à passer l'option `--dist` à JHBuild.

`makedistcheck`

  Une valeur booléenne indiquant s'il faut exécuter `make distcheck` après `make`. La valeur par défaut est `False`. Ce réglage équivaut à passer l'option `--distcheck` à JHBuild.

`mesonargs`

  A string containing arguments passed to the `meson` invocation of all modules. Can be overridden for particular modules using the `module_mesonargs` dictionary. Defaults to `''`.

`module_autogenargs`

  Un dictionnaire faisant correspondre les noms de modules à des chaînes donnant des paramètres à passer à `autogen.sh`. Le paramètre dans `module_autogenargs` est utilisé à la place du paramètre global `autogenargs`. Si un module particulier n'est pas dans le dictionnaire, c'est le paramètre global `autogenargs` qui est utilisé.

`module_checkout_mode`

  Un dictionnaire indiquant le mode d'extraction à employer pour les modules. Ce paramètre écrase le paramètre global `checkout_mode`.

`module_cmakeargs`

  A dictionary mapping module names to strings specifying the arguments to be passed to `cmake`. The setting in `module_cmakeargs` is used instead of the global `cmakeargs` setting. If a particular module isn’t listed in the dictionary, the global `cmakeargs` will be used.

`module_makeargs`

  Un dictionnaire faisant correspondre les noms de modules à des chaînes indiquant les paramètres à passer à `make`. Le paramètre dans `module_makeargs` est utilisé à la place du paramètre global `makeargs`. Si un module particulier n'est pas dans le dictionnaire, c'est le paramètre global `makeargs` qui est utilisé.

`module_makecheck`

  Un dictionnaire faisant correspondre les noms de modules à des valeurs booléennes indiquant s'il faut exécuter `make check` après `make`. Le paramètre dans `module_makecheck` remplace la valeur de `makecheck`. Si un module particulier n'est pas dans le dictionnaire, c'est le paramètre global `makecheck` qui est utilisé.

`module_mesonargs`

  A dictionary mapping module names to strings specifying the arguments to be passed to `meson`. The setting in `module_mesonargs` is used instead of the global `mesonargs` setting. If a particular module isn’t listed in the dictionary, the global `mesonargs` will be used.

`module_ninjaargs`

  A dictionary mapping module names to strings specifying the arguments to pass to `ninja`. The setting in `module_ninjaargs` replaces the value of `ninjaargs`. If a particular module isn't listed in the dictionary, the global `ninjaargs` will be used.

`module_nopoison`

  Un dictionnaire faisant correspondre les noms de modules à des valeurs booléennes. Si la valeur pour un module vaut `True`, JHBuild essaye de construire les modules dépendants même si le module indiqué échoue. Le paramètre dans `module_nopoison` remplace la valeur de `nopoison`. Si un module particulier n'est pas dans le dictionnaire, c'est le paramètre global `nopoisons` qui est utilisé.

`module_extra_env`

  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.

`module_static_analyzer`

  Dictionary mapping module names to boolean values indicating whether static analysis should be performed while building that module. This allows the global `static_analyzer` configuration option to be overridden.

`modules`

  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 `buildone` command is used. Defaults to `['meta-gnome-desktop']`.

`moduleset`

  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.

`modulesets_dir`

  Une chaîne indiquant le répertoire contenant les jeux de modules à utiliser. Par défaut, c'est le répertoire `modulesets/` dans les sources de JHBuild.

`nice_build`

  Lance les constructions avec la priorité `SCHED_IDLE` sur Linux, `nice` sur les autres Unix. Cela peut améliorer drastiquement la réactivité du bureau pour les constructions en parallèle tout en ayant un impact négligeable sur la vitesse de construction.

`ninjaargs`

  A string listing additional arguments to be passed to `ninja`. Defaults to `''`.

`nobuild`

  A boolean value, if set to `True` JHBuild will not build modules, but just download and unpack the sources. The default value is `False`.

`nonetwork`

  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 à `True` équivaut à passer l'option `--no-network`. La valeur par défaut est `False`.

`nonotify`

  Une valeur booléenne indiquant s'il faut émettre des notifications au moyen du démon de notification. Si la valeur vaut `False`, les notifications sont émises. La valeur par défaut est `True`.

`nopoison`

  Une valeur booléenne qui, si elle est définie à `True`, 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 `--no-poison`. La valeur par défaut est `False`.

`notrayicon`

  A boolean value specifying whether to show an icon in the system tray using Zenity. If set to `False`, an icon is shown. Defaults to `True`.

`noxvfb`

  A boolean value, if set to `True` JHBuild will run any graphical tests on the real X server, rather than using `Xvfb`. This option is equivalent to passing `--no-xvfb`. The default value is `False`.

`partial_build`

  Une valeur booléenne qui si elle est définie à `True` indique à JHBuild de ne pas construire les modules des dépendances si les paquets systèmes correspondant sont installés. La valeur par défaut est `True`.

`prefix`

  A string specifying the prefix to install modules to. `prefix` must be an absolute path. This directory must be writable. Defaults to `'~/jhbuild/install/'`.

`pretty_print`

  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 `True`.

`print_command_pattern`

  Une chaîne affichée avant que JHBuild n'exécute une commande. `%(command)s` dans la chaîne sera remplacé par la commande à exécuter. `%(cwd)s` dans la chaîne sera remplacé par le répertoire courant. La valeur par défaut est `'%(command)s'`.

`progress_bar`

  Une valeur booléenne indiquant s'il faut afficher une barre de progression lorsque JHBuild fonctionne en mode silencieux. La valeur par défaut est `True`.

`quiet_mode`

  Une valeur booléenne. Si définie à `True`, elle désactive la sortie des commandes qui s'exécutent. La valeur par défaut est `False`.

`repos`

  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 :

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

`shallow_clone`

  A boolean value specifying if JHBuild should prefer smaller version control downloads. Equivalent to `git clone --depth 1` or `bzr co --light`. Defaults to `False`.

`skip`

  A list of modules to skip. This `--skip` command line option extends the list. This list is empty by default. If the list contains the special value `'*'`, JHBuild will skip all modules not explicitly listed in the `modules` variable. This may be useful if you want to build modules without their implicit dependencies.

`static_analyzer`

  A boolean value: if set to `True`, run a static analysis tool on each module as it’s being built. Defaults to `False`.

`static_analyzer_outputdir`

  Root directory below which static analysis reports will be saved (if `static_analyzer` is `True`). Defaults to `/tmp/jhbuild_static_analyzer`.

`static_analyzer_template`

  Command template for the static analyzer. This has the parameters `outputdir` (the value of the `static_analyzer_outputdir` configuration variable) and `module` (the name of the module currently being built) substituted into it `printf`-style. The resulting command is used as a prefix to `make` when building a module. Defaults to `scan-build`.

`sticky_date`

  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. `'aaaa-mm-jj'`. La valeur par défaut est `None`.

`svn_program`

  Une chaîne indiquant le programme à utiliser pour la prise en charge de Subversion. Cela peut être `svn`, `git-svn` ou `bzr`. La valeur par défaut est `svn`.

`system_libdirs`

  A list of strings specifying the system library paths. This is used when setting the default values of some environment variables, such as `PKG_CONFIG_PATH`.

`tarballdir`

  A string if set, tarballs will be downloaded to the specified directory instead of `checkoutroot`. This is useful if you have multiple JHBuild environments or regularly clear out `checkoutroot` and want to reduce bandwidth usage. Defaults to `'~/.cache/jhbuild/downloads'`.

`tinderbox_outputdir`

  Une chaîne indiquant le répertoire de stockage de la sortie de `jhbuild tinderbox`. Cette chaîne peut être remplacée par l'option `--output`. La valeur par défaut est `None`, ce qui signifie qu'il faut obligatoirement définir cette option soit dans la ligne de commande, soit dans le fichier de configuration.

`trycheckout`

  Une option booléenne qui, si elle est définie à `True`, indique à JHBuild d'essayer de résoudre automatiquement les échecs en 1) exécutant une nouvelle fois `autogen.sh` et 2) extrayant une nouvelle version du module à partir du contrôle de version. Ce paramètre équivaut à passer l'option `--try-checkout`.

`use_local_modulesets`

  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 `False`.

`xvfbargs`

  Une chaîne contenant des paramètres à passer à `Xvfb` si des tests graphiques sont effectués.

`conditions`

  A set of condition (strings) that can influence the modules that are built and the options that are used for building them. You should use `conditions.add()` and `conditions.discard()` to modify the list if you want to make changes.

  The original set of conditions is determined on a per-OS basis and can be modified using the `--conditions=` commandline argument. The changes made by `--conditions` are visible at the time that jhbuildrc is sourced, so you can set other variables based on the current value of the set, but `--conditions` will be applied again after any changes made by jhbuildrc.

### Autres structures du fichier de configuration

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

`os.environ`

  Un dictionnaire représentant l'environnement. Cet environnement est transmis aux processus générés par JHBuild.

  Certaines variables d'environnement ont un impact certain, comme `CPPFLAGS`, `CFLAGS`, `INSTALL` et `LDFLAGS`. Par exemple :

      os.environ['CFLAGS'] = '-O0 -g'

`addpath`(`var_env`, `chemin`)

  Cela ajoute un répertoire à la variable d'environnement `PATH` (chemin). `addpath` 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).

`prependpath`(`var_env`, `chemin`)

  Après le traitement du fichier de configuration, JHBuild modifie certains chemins sur la base de variables telles que `prefix` (par ex. en ajoutant `$prefix/bin` au début de la variable `PATH`).

  La fonction `prependpath` fonctionne comme `addpath`, sauf que la variable d'environnement est modifiée après que JHBuild ait modifié l'environnement.

## Syntaxe des fichiers de jeu de modules

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 `modulesets/`. Le schéma RELAX-NG peut être utilisé pour modifier les fichiers de jeux de modules au moyen du mode `nxml-mode` dans Emacs.

L'élément de premier niveau dans un fichier de jeu de modules est l'élément `moduleset`. 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.

Content in the moduleset file can be conditionally included by use of the <if> tag to surround the conditional content. It is currently only possible to predicate the inclusion on whether a particular condition flag is set or not, using <if condition-set='cond'> or <if condition-unset='cond'>. Conditions are set by default on a per-OS basis but can be influenced by way of the `conditions` variable in jhbuildrc or the `--conditions=` commandline argument.

### Sources de module

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).

L'élément `repository` est utilisé pour décrire tout type de dépôt. L'élément `branch` est utilisé dans une définition de module pour préciser des paramètres supplémentaires.

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

L'attribut `name` est un identifiant unique pour le dépôt.

L'attribut `default` indique si ce dépôt est la source par défaut pour ce jeu de modules.

The `type` attribute specifies the type of repository. It can be one of: `bzr`, `cvs`, `darcs`, `fossil`, `git`, `hg`, `mnt`, `svn`, `tarball`. Other attributes depend on the `type`, as well as the `branch` used inside module definitions. Those are described below in the repository type sub-sections.

L'attribut `developer-href-example` sert à indiquer le format de l'URL pour le dépôt tel qu'utilisé par les développeurs, à titre informatif.

L'élément `branch` est employé dans les définitions de modules.

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

All attributes have sensible defaults and depend on the module and repository definitions. Common attributes are described here.

L'attribut `repo` permet d'indiquer un nom de dépôt différent de la valeur par défaut.

L'attribut `module` permet d'indiquer un nom de module pour l'extraction du dépôt. Par défaut, c'est l'identifiant du module.

L'attribut `checkoutdir` permet d'indiquer le nom du dossier d'extraction. Par défaut, c'est l'identifiant du module.

D'autres attributs sont décrits ci-dessous

#### Bazaar

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.

    <repository type="bzr" name="launchpad.net"
          href="lp:"/>

Additional attributes are: `trunk-template` (defaults to `"%(module)s"`) and `branches-template` (defaults to `"%(module)s/%(branch)s`"). These attributes are used to specify templates for constructing URL. A `branch` element in the module definitions can specify `branch` and `user` attributes. These values will be substituted in the templates. If either of those are defined `branches-template` is used, otherwise `trunk-template` is used. This way you can override repository to build modules from your personal branch or build many modules from a repository with non-standard layout.

An addition `branch` element accepts `revspec` attribute to anchor on a particular revision. Any valid `bzr revspec` is accepted, for example `date:yesterday, -5, tag:0.1` to get first revision since yesterday, 5 commits behind the tip or tag "0.1". See `bzr help revisionspec` for all possible values.

Par exemple, un dépôt avec des attributs `template` :

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

Des exemples d'éléments `branch` pour le dépôt ci-dessus :

    <branch repo="launchpad.net"
          module="bzr"
          checkoutdir="bzr-next"/>

    <branch repo="launchpad.net"
          module="bzr"
          branch="2.2"
          checkoutdir="bzr-beta"/>

#### CVS

Ce type de dépôt permet de définir un dépôt CVS.

L'attribut `password` permet d'indiquer le mot de passe pour accéder au dépôt.

L'attribut `cvsroot` permet d'indiquer la racine du dépôt.

    <repository type="cvs" name="tango.freedesktop.org"
        cvsroot=":pserver:anoncvs@anoncvs.freedesktop.org:/cvs/tango"
        password=""/>

Attributs supplémentaires : `revision`, `update-new-dirs` et `override-checkoutdir`.

#### Darcs

Ce type de dépôt permet de définir un dépôt Darcs.

    <repository type="darcs" name="telepathy.freedesktop.org"
          href="http://projects.collabora.co.uk/darcs/telepathy/"/>

#### Git

Ce type de dépôt permet de définir un dépôt Git.

    <repository type="git" name="git.freedesktop.org"
        href="git://anongit.freedesktop.org/git/"/>

Il autorise les attributs suivants sur l'élément `branch` :

L'attribut `revision` 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 `branches`. 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.

L'attribut `tag` indique la révision à extraire absolument durant la phase de mise à jour. Il surcharge l'attribut `revision`.

    <branch repo="git.freedesktop.org" module="swfdec/swfdec"
            checkoutdir="swfdec"
            revision="branche-locale-ou-distante"
            tag="étiquette"/>

#### Mercurial

Ce type de dépôt permet de définir un dépôt Mercurial.

    <repository type="hg" name="hg.gtk-vnc"
        href="http://gtk-vnc.codemonkey.ws/hg/" />

    <branch repo="hg.gtk-vnc" module="outgoing.hg" checkoutdir="gtk-vnc"/>

#### Monotone

Ce type de dépôt permet de définir un dépôt Monotone.

L'attribut `server` permet d'indiquer le serveur du dépôt.

L'attribut `database` permet d'indiquer la base de données à utiliser pour le dépôt.

L'attribut `defbranch` permet d'indiquer la branche à utiliser dans le dépôt.

    <repository type="mtn" name="pidgin.im"
        server="pidgin.im" database="pidgin.im.mtn"
        defbranch="im.pidgin.pidgin"/>

#### Subversion

Ce type de dépôt permet de définir un dépôt Subversion.

    <repository type="svn" name="svn.gnome.org" default="yes"
        href="http://svn.gnome.org/svn/"/>

Il autorise un attribut `revision` sur l'élément `branch`. Cet attribut définit la branche à extraire ou, si c'est un nombre, une révision spécifique à extraire.

    <branch revision="gnome-2-20"/>

Il est possible de définir un agencement `svn` personnalisé en utilisant `trunk-template` (qui vaut par défaut « %(module)s/trunk »), `branches-template` (qui vaut par défaut « %(module)s/branches/%(branch)s ») et `tags-template` (qui vaut par défaut « %(module)s/tags/%(tag)s »).

#### System

This repository type is used to define a fake system repository. A system repository is required to create `systemmodules`.

    <repository type="system" name="system"/>

#### Tarballs (archives tar)

Ce type de dépôt permet de définir un dépôt tarball.

    <repository type="tarball" name="dbus/dbus-python"
        href="http://dbus.freedesktop.org/releases/dbus-python/"/>

Il autorise les attributs suivants sur l'élément `branch` :

L'attribut `module` indique le fichier à télécharger et compiler. L'attribut `version` indique la version du module.

Les attributs `size` et `hash`, ainsi que l'ancien attribut `md5sum` sont facultatifs. Si ces attributs existent, ils sont utilisés pour vérifier que le paquet source a été correctement téléchargé.

The `rename-tarball` can be used to rename the tarball file when downloading, in case the original name conflicts with another module.

On peut imbriquer autant d'éléments `patch` qu'on le désire dans l'élément `branch`. Ces correctifs sont appliqués dans l'ordre à l'arborescence source après décompression. L'attribut `file` indique le nom de fichier du correctif et l'attribut `strip` précise le nombre de niveaux de répertoires à retirer dans les chemins en appliquant le correctif.

Pour les jeux de modules livrés avec JHBuild, les fichiers de correctifs sont situés dans le répertoire `jhbuild/patches/` ; 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 `patches/`. Il est aussi possible que l'attribut `file` indique un URI, auquel cas il sera téléchargé à cet emplacement.

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

Un élément `branch` d'un tarball peut aussi contenir des éléments `quilt` qui précisent des `branch` imbriquées à importer.

### Inclusion d'autres jeux de modules

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 `include`.

    <include href="uri"/>

L'attribut `href` est une référence sous forme d'URI vers le jeu de modules à inclure, relatif au fichier contenant l'élément `include`.

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).

### Définitions de modules

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.

À la base, ils sont tous formés d'un élément `branch` décrivant la manière d'obtenir le module et d'éléments `dependencies`, `suggests` et `after` pour déclarer les dépendances du module.

Tout module mentionné dans l'élément `dependencies` est ajouté à la liste des modules lors de la commande `jhbuild build` (s'il n'y est pas déjà) ; JHBuild s'assure que les modules dépendants soient construits en premier.

Après avoir généré la liste des modules, les modules mentionnés dans l'élément `suggests` 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.

#### autotools

L'élément `autotools` sert à définir un module qui doit être compilé à l'aide du système de construction GNU Autotools.

    <autotools id="id"
    	      [ autogenargs="autogenargs" ]
    	      [ makeargs="makeargs" ]
    	      [ makeinstallargs="makeinstallargs" ]
    	      [ autogen-sh="autogen-sh" ]
    	      [ makefile="makefile" ]
    	      [ skip-autogen="skip-autogen" ]
    	      [ skip-install="skip-install" ]
    	      [ uninstall-before-install="uninstall-before-install" ]
    	      [ autogen-template="autogen-template" ]
    	      [ check-target="check-target" ]
    	      [ supports-non-srcdir-builds="supports-non-srcdir-builds" ]
    	      [ force-non-srcdir-builds="force-non-srcdir-builds" ]
    	      [ supports-unknown-configure-options="supports-unknown-configure-options" ]
    	      [ supports-static-analyzer="supports-static-analyzer" ]>

      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="modulename"/>
        ...
      </dependencies>
      <after>
        <dep package="modulename"/>
        ...
      </after>

    </autotools>

Les attributs `autogenargs`, `makeargs` et `makeinstallargs` servent à indiquer des paramètres supplémentaires à transmettre respectivement à `autogen.sh`, `make` et `make install`.

The `autogen-sh` attribute specifies the name of the autogen.sh script to run. The value `autoreconf` can be used if your module has no `autogen.sh` script equivalent. In that case, JHBuild will run `autoreconf -fi`, followed by the proper `configure`. `skip-autogen` chooses whether or not to run autogen.sh, it is a boolean with an extra `never` value to tell JHBuild to never skip running `autogen.sh`. `skip-install` is a boolean attribute specifying whether to skip `make install` command on the module. `makefile` specifies the filename of the makefile to use.

The `uninstall-before-install` specifies any old installed files from the module should before removed before running the install step. This can be used to work around a problem where libtool tries to link one library it is installing against another library it is installing, but because of jhbuild's use of DESTDIR, finds the old installed library instead. The downside of specifying this is that it could cause problems if the user is currently running code that relies on installed files from the module.

L'attribut `supports-non-srcdir-builds` sert à marquer les modules qui ne peuvent être proprement construits en utilisant un répertoire source séparé.

The `force-non-srcdir-builds` attribute is used to mark modules that can't be cleanly built from the source directory, but can be built from outside it.

L'attribut `autogen-template` 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 : `srcdir`, `autogen-sh`, `prefix`, `libdir`, et `autogenargs`. Par exemple, voici la valeur par défaut de autogen-template :

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

L'attribut `check-target` doit être indiqué (avec la valeur « false ») pour les modules qui n'ont pas de cible `make check`.

The `supports-static-analyzer` attribute must be specified (with false as value) for modules which don’t support being built under a static analysis tool such as `scan-build`.

The `supports-unknown-configure-options` attribute is used to mark modules that will error out if an unknown option is passed to `configure`. Global configure options will not be used for that module.

#### cmake

L'élément `cmake` permet de définir un module construit à l'aide du système de construction CMake.

      <cmake id="modulename"
                [ cmakeargs="cmakeargs" ]
                [ ninjaargs="ninjaargs" ]
                [ makeargs="makeargs" ]
                [ skip-install="skip-install" ]
                [ cmakedir="cmakedir" ]
                [ use-ninja="use-ninja" ]
                [ force-non-srcdir-builds="force-non-srcdir-builds" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="modulename"/>
        ...
      </dependencies>
      <after>
        <dep package="modulename"/>
        ...
      </after>
    </cmake>

The `cmakeargs` attribute is used to specify additional arguments to pass to `cmake`.

The `ninjaargs` attribute is used to specify additional arguments to pass to `ninja`.

L'attribut `makeargs` permet de définir des paramètres supplémentaires à passer à `make`.

The `cmakedir` attribute specifies the subdirectory where cmake will run in relation to srcdir.

The `force-non-srcdir-builds` attribute is used to mark modules that can't be cleanly built from the source directory, but can be built from outside it.

The `use-ninja` attribute is used to mark modules should be built using the Ninja backend for cmake, instead of the Make backend. The default is to use the Ninja backend.

#### Meson

The `meson` element is used to define a module which is configured using the Meson build system and built using the Ninja build tool.

      <meson id="modulename"
                [ mesonargs="mesonargs" ]
                [ ninjaargs="ninjaargs" ]
                [ skip-install="skip-install" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="modulename"/>
        ...
      </dependencies>
      <after>
        <dep package="modulename"/>
        ...
      </after>
    </meson>

The `mesonargs` attribute is used to specify additional arguments to pass to `meson`.

The `ninjaargs` attribute is used to specify additional arguments to pass to `ninja`.

#### distutils

The `distutils` element is used to define a module which is built using python's distutils.

    <distutils id="nom_module"
                [ supports-non-srcdir-builds="yes|no" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="nom_module"/>
        ...
      </dependencies>
      <after>
        <dep package="nom_module"/>
        ...
      </after>
    </distutils>

#### linux

L'élément `linux` 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 `kconfig`.

    <linux id="id"
    	  [ makeargs="paramètres_make" ]>

      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="nom_module"/>
        ...
      </dependencies>
      <after>
        <dep package="nom_module"/>
        ...
      </after>

      <kconfig [ repo="dépôt" ]
    	    version="version"
    	    [ module="module" ]
    	    [ config="config" ] />

    </linux>

#### perl

L'élément `perl` permet de construire des modules Perl.

L'attribut `makeargs` permet de définir des paramètres supplémentaires à passer à `make`.

    <perl id="nom_module"
    	 [ makeargs="paramètres_make" ]>

      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="nom_module"/>
        ...
      </dependencies>
      <after>
        <dep package="nom_module"/>
        ...
      </after>

    </perl>

#### systemmodule

The `systemmodule` element is used to specify modules that must be provided by the system. The module should be installed by your distributions package management system.

    <systemmodule id="modulename">
      <pkg-config>pkg-config.pc</pkg-config>

      <branch repo="system" version="version" />
    </systemmodule>

If the system module does not provide a pkg-config file, `systemdependencies` tag can be used to identify the dependencies. Two values are supported by the `type` attribute of the `dep` tag:

1. `path` value. The path is searched for the matching program name.

2. `c_include` value. The C include path is searched for the matching header name. `name` may include a sub-directory. The C include search path can modified by setting `CPPFLAGS` within the configuration variables `cflags` or `module_autogenargs`.

    <systemmodule id="modulename">
      <branch repo="system" version="version" />
      <systemdependencies>
        <dep type="path" name="executable-name" />
      </systemdependencies>
    </systemmodule>

    <systemmodule id="modulename">
      <branch repo="system" version="version" />
      <systemdependencies>
        <dep type="c_include" name="header-name" />
      </systemdependencies>
    </systemmodule>

If the system module may be installed in different locations or installed with different names by different distributions, `altdep` tag can be used as subelements of `dep` tag to specify alternative locations or names. `altdep` tag support the same attributes as `dep` tag does.

    <systemmodule id="modulename">
      <branch repo="system" version="version" />
      <systemdependencies>
        <dep type="path" name="executable-name">
          <altdep type="path" name="alternative-executable-name-1" />
          <altdep type="path" name="alternative-executable-name-2" />
          ...
        <dep>
      </systemdependencies>
    </systemmodule>

    <systemmodule id="modulename">
      <branch repo="system" version="version" />
      <systemdependencies>
        <dep type="c_include" name="header-name">
          <altdep type="c_include" name="alternative-header-name-1" />
          <altdep type="c_include" name="alternative-header-name-2" />
          ...
        <dep>
      </systemdependencies>
    </systemmodule>

#### waf

L'élément `waf` permet de définir un module construit à l'aide du système de construction Waf.

L'attribut `waf-command` permet de définir le script de commande waf à utiliser ; la valeur par défaut est `waf`.

The `python-command` attribute is used to specify the Python executable to use; it defaults to `python`. This is useful to build modules against version 3 of Python.

    <waf id="modulename">
    	 [ python-command="python-command" ]
    	 [ waf-command="waf-command" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="modulename"/>
        ...
      </dependencies>
      <after>
        <dep package="modulename"/>
        ...
      </after>
    </waf>

#### testmodule

L'élément `testmodule` permet de créer un module qui exécute une suite de tests en utilisant LDTP ou Dogtail.

    <testmodule id="id"
    	       type="type">

      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="nom_module"/>
        ...
      </dependencies>
      <after>
        <dep package="nom_module"/>
        ...
      </after>

      <testedmodules>
        <tested package="paquet" />
      </testedmodules>

    </testmodule>

L'attribut `type` 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 ».

Unless the noxvfb configuration option is set, an Xvfb server is started to run the tests in.

#### metamodule

L'élément `metamodule` 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.

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.

    <metamodule id="nom_module">
      <dependencies>
        <dep package="nom_module"/>
        ...
      </dependencies>
      <suggests>
        <dep package="nom_module"/>
        ...
      </suggests>
    </metamodule>

L'attribut `id` donne le nom du module. Les éléments enfants sont traités de la même manière que `autotools`.

### Éléments désapprouvés

#### Sources de module

##### cvsroot

L'élément `cvsroot` est maintenant désapprouvé. Il faut utiliser l'élément `repository` à la place.

L'élément `cvsroot` permet de décrire un dépôt CVS.

      <cvsroot name="nom_racine"
               [ default="yes|no" ]
               root="cvsroot_anon"
               password="mot_de_passe_anon"/>

L'attribut `name` doit être un identifiant unique pour le dépôt CVS.

L'attribut `default` indique si cette source de module est la source par défaut pour ce fichier de jeu de modules.

L'attribut `root` contient la racine CVS utilisée pour l'accès anonyme à ce dépôt, et l'attribut `password` précise le mot de passe utilisé pour l'accès anonyme.

##### svnroot

L'élément `svnroot` est maintenant désapprouvé. Il faut utiliser l'élément `repository` à la place.

L'élément `svnroot` permet de décrire un dépôt Subversion.

      <svnroot name="nom_racine"
               [ default="yes|no" ]
               href="svnroot_anonyme"/>

L'attribut `name` doit être un identifiant unique pour le dépôt Subversion.

L'attribut `default` indique si cette source de module est la source par défaut pour ce fichier de jeu de modules.

L'attribut `href` contient l'URL de base du dépôt. En général, c'est un URL `http`, `https` ou `svn`.

#### Types de modules désapprouvés

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.

##### tarball

Cet élément désapprouvé est une simple couche fine autour du type de module `autotools` et du type de dépôt `tarball`.

L'élément `tarball` permet de définir un module à construire à partir d'une archive tar.

      <tarball id="modulename"
                  [ version="version" ]
                  [ checkoutdir="checkoutdir" ]
                  [ autogenargs="autogenargs" ]
                  [ makeargs="makeargs" ]
                  [ autogen-sh="autogen-sh" ]
                  [ supports-non-srcdir-builds="yes|no" ]>
        <source href="source-url"
                [ size="source-size" ]
                [ hash="source-algo:source-hash" ]
                [ md5sum="source-md5sum" ]/>
        <patches>
          <patch file="filename" strip="level"/>
          ...
        </patches>
        <dependencies>
          <dep package="modulename"/>
          ...
        </dependencies>
        <suggests>
          <dep package="modulename"/>
          ...
        </suggests>
      </tarball>

Les attributs `id` et `version` sont utilisés pour identifier le module.

L'élément `source` indique le fichier à télécharger et compiler. L'attribut `href` est obligatoire, alors que les attributs `size` et `hash`, comme l'attribut obsolète `md5sum`, 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é.

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

Pour les jeux de modules livrés avec JHBuild, les fichiers de correctifs sont situés dans le répertoire `jhbuild/patches/` ; 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 `patches/`. Il est aussi possible que l'attribut `file` indique un URI, auquel cas il sera téléchargé à cet emplacement.

Les autres attributs et les éléments `dependencies`, `suggests` et `after` sont traités de la même manière que pour autotools.