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.

VI.I. 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

VI.I.I. 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"/>
        

VI.I.II. 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.

VI.I.III. 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/"/>

VI.I.IV. 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"/>
        

VI.I.V. 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"/>

VI.I.VI. 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"/>

VI.I.VII. 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 »).

VI.I.VIII. 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"/>

VI.I.IX. 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.

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

VI.III. 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.

VI.III.I. 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.

VI.III.II. 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.

VI.III.III. 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.

VI.III.IV. 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>

VI.III.V. 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>

VI.III.VI. 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>

VI.III.VII. 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>

VI.III.VIII. 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>

VI.III.IX. 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.

VI.III.X. 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.

VI.IV. Éléments désapprouvés

VI.IV.I. Sources de module

VI.IV.I.I. 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.

VI.IV.I.II. 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.

VI.IV.II. 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.

VI.IV.II.I. 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.