Archivo de sintaxis del conjunto de módulos

JHBuild usa archivos XML para describir las dependencias entre módulos. En JHBuild se incluyen esquemas RELAX-NG y Definición de Tipo de Documento en la carpeta modulesets/. El esquema RELAX-NG se puede usar para editar los archivos del conjunto de módulos usando nxml-mode en Emacs.

El elemento superior del archivo de un conjunto de módulos es el elemento moduleset. No se usa ningún nombre de espacio XML. El elemento a continuación del superior tiene tres tipos: fuentes de módulos, sentencias «include» y definiciones de módulos.

El contenido el en archivo de conjuntos de módulos se puede incluir de manera condicional usando la etiqueta <if> para rodear el contenido condicional. Actualmente esto sólo es posible si una determinada condición se cumple o no, usando <if condition-set='cond'> or <if condition-unset='cond'>. Las condiciones se establecen de manera predeterminada en función del sistema operativo, pero se pueden ver afectadas por la variable conditions del archivo jhbuildrc o por el argumento de línea de comandos --conditions=.

7.1. Repositorios de módulos

En lugar de listar la ubicación completa de todos los módulos, se muestra un número de «fuentes del módulo» en el conjunto de módulos, y se referencian por nombre en las definiciones de módulos. Aparte de reducir la cantidad de información redundante en el conjunto de módulos, hace más fácil para el usuario el especificar una fuente alternativa para esos módulos (para CVS y Subversion, es frecuente que desarrolladores y usuarios usen diferentes métodos de acceso al repositorio).

El elemento repositorio se usa para describir todos los tipos de repositorios. El elemento rama se usa dentro de la definición del módulo para indicar configuraciones adicionales.

<repository name="nombre"
  type="tipo"
  [ default="predeterminado" ]
  [ password="contraseña" ]
  [ cvsroot="cvsroot" ]
  [ archive="archivo" ]
  [ href="href" ]
  [ server="servidor" ]
  [ database="base de datos" ]
  [ defbranch="rama predeterminada" ]
  [ trunk-template="principal-plantilla" ]
  [ branches-template="ramas-plantilla" ]
  [ tags-template="etiquetas-plantilla" ]
  [ developer-href-example="ejemplo-href-desarrollador" ] />

El atributo nombre es un identificador único del repositorio.

El atributo predeterminado especifica si este repositorio es el predeterminado para este conjunto de módulos.

El atributo type especifica el tipo de repositorio. Puede ser uno de estos: bzr, cvs, darcs, fossil, git, hg, mnt, svn, tarball. Otros atributos dependen de type, así como de branch usados dentro de las definiciones de los módulos. Se describen a continuación en las subsecciones de tipo de repositorios.

El atributo developer-href-example se usa para especificar el formato del URL del repositorio usado por los desarrolladores. Esto es sólo informativo.

El elemento rama se usa dentro de las definiciones del módulo.

<branch
  [ repo="repositorio" ]
  [ module="nombre del módulo" ]
  [ checkoutdir="carpeta de descarga" ]
  [ revision="revisión" ]
  [ tag="etiqueta" ]
  [ update-new-dirs="actualizar carpetas nuevas" ]
  [ override-checkoutdir="omitir carpeta de descarga" ]
  [ subdir="subcarpeta" ]
  [ branch="rama" ]
  [ version="versión" ]
  [ size="tamaño" ]
  [ source-subdir="subcarpeta de fuentes" ]
  [ hash="hash" ]/>

Todos los atributos tienen valores predeterminados correctos y dependen del módulo y de las definiciones del repositorio. Aquí se describen los atributos comunes.

El atributo repo se usa para especificar un nombre de repositorio no predeterminado.

El atributo module se usa para especificar el nombre del módulo que descargar del repositorio. Su valor predeterminado es el identificador del módulo.

El atributo checkoutdir se usa para especificar la carpeta de descarga que usar. Su valor predeterminado es el identificador del módulo.

A continuación se describen otros atributos

7.1.1. Bazaar

El tipo de repositorio se usa para definir un repositorio Bazaar. Se recomienda tener Bazaar 1.16 o superior.

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

Los atributos adicionales son trunk-template (el predeterminado es «%(module)s»») y branches-template (el predeterminado es «%(module)s/%(branch)s»). Estos atributos se usan para especificar plantillas para construir URL. El elemento branch en la definición del módulo puede especificar los atributos branch y user. Estos valores se sustituirán en las plantillas. Si algún otro está definido se usa branches-template, de lo contrario se usa trunk-template. De este modo puede omitir el repositorio para construir módulos de su rama personal o construir varios módulos desde un repositorio con una disposición no estándar.

Además de un elemento branch acepta atributos revspec para anclarse en una revisión en particular. Se acepta cualquier bzr revspec válido, por ejemplo, date:yesterday, -5, tag:0.1 para obtener la primera revisión desde ayer, 5 commits después de la etiqueta «0.1». Consulte bzr help revisionspec para ver todos los valores posibles.

Ejemplo de repositorio con los atributos template definidos:

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

Ejemplo de elementos de la branch para el anterior repositorio:

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

7.1.2. CVS

El tipo de repositorio se usa para definir un repositorio CVS.

El atributo password se usa para especificar la contraseña del repositorio.

El atributo cvsroot se usa para especificar la raíz del repositorio.

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

Los atributos adicionales son: revision, update-new-dirs y override-checkoutdir.

7.1.3. Darcs

El tipo de repositorio se usa para definir un repositorio Darcs.

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

7.1.4. Git

El tipo de repositorio se usa para definir un repositorio Git.

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

Permite los siguientes atributos en el elemento branch:

El atributo revision se usa para especificar una rama de control local o remota a la que cambiar en la fase de actualización. La predeterminada es «master». Es posible anular este atributo con la variable de configuración branches. El cambio sólo se realizará si la rama actual está controlando una rama remota, para no interferir en su trabajo.

El atributo tag se usa para especificar una revisión que descargar siempre en la fase de actualización. Omite el atributo revision.

<branch repo="git.freedesktop.org" module="swfdec/swfdec"
        checkoutdir="swfdec"
        revision="rama-local-o-remota"
        tag="árbol"/>
        

7.1.5. Mercurial

El tipo de repositorio se usa para definir un repositorio 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"/>

7.1.6. Monotone

El tipo de repositorio se usa para definir un repositorio Monotone.

El atributo server se usa para especificar el servidor del repositorio.

El atributo database se usa para especificar la base de datos que usar por el repositorio.

El atributo defbranch se usa para especificar la rama del repositorio que usar.

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

7.1.7. Subversion

El tipo de repositorio se usa para definir un repositorio Subversion.

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

Permite una revision en el elemento branch. Este atributo define la rama que se descargará o, si es un número, una revisión específica para descargar.

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

Es posible especificar una disposición de svn personalizada usando trunk-template (el predeterminado es «%(module)s/trunk»), branches-template (el predeterminado es «%(module)s/branches/%(branch)s») y tags-template (el predeterminado es «%(module)s/tags/%(tag)s»)

7.1.8. Sistema

Este tipo de repositorio se usa para definir un repositorio del sistema falso. Se necesita crear un repositorio del sistema para crear los systemmodules.

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

7.1.9. Archivos tar

El tipo de repositorio se usa para definir un repositorio de archivos tar.

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

Permite los siguientes atributos en el elemento branch:

El atributo module especifica el archivo que se descargará y compilará; el atributo version especifica la versión del módulo.

Los atributos size y hash, al igual que el obsoleto md5sum, son opcionales. Si estos atributos están presentes, se usan para comprobar que el paquete fuente se ha descargado correctamente.

El atributo rename-tarball se puede usar para renombrar el archivo tar cuando se descargue en el caso de que el nombre original entre en conflicto con otro módulo.

Se puede anidar cualquier número de elementos patch dentro del elemento branch. Estos parches se aplican, en orden, al árbol de fuentes después de descomprimirlo. El atributo file proporciona el nombre de archivo del parche, y el atributo strip dice a cuántos niveles de carpetas se descenderá al aplicar el parche.

Para conjuntos de módulos empaquetados con JHBuild, los archivos de parches se buscan en la carpeta jhbuild/patches/; para conjuntos de módulos referidos por el URI, los archivos de parches se buscan en la misma carpeta que el archivo del conjunto de módulos, o en su subcarpeta patches/. También es posible que el atributo file especifique un URI, en cuyo caso se descargará de esa ubicación.

<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 archivo tar del elemento branch puede contener también elementos quilt que especifiquen elementos branch que importar.

7.2. Incluir otros conjuntos de módulos

JHBuild permite un conjunto de módulos para incluir los contenidos referidos por otro usando el elemento include.

<include href="uri"/>

El atributo href es una referencia al URI del conjunto de módulos que se incluirá, relativa al archivo que contiene el elemento include.

Desde el conjunto de módulos referenciado sólo se importan definiciones de módulos; no fuentes de módulos. Se permiten múltiples niveles de inclusión, pero no bucles (en este momento no hay ningún código para manejar bucles).

7.3. Definiciones de módulos

Hay varios tipos de definiciones de módulos que se pueden usar en un archivo de conjunto de módulos, y la lista se puede extender fácilmente. Aquí sólo se mencionan los más comunes.

Todos ellos están compuestos básicamente de un elemento branch que describe cómo obtener el módulo y unos elementos dependencies, suggests y after para declarar las dependencias del módulo.

jhbuild build añadirá a la lista de módulos todos los módulos listados en el elemento dependencies, si no están ya incluidos, y se asegurará que los módulos dependientes se construyen primero.

Después de generar la lista de módulos, los módulos listados en el elemento suggests se usarán para ordenar la futura lista de módulos (aunque no añadirá módulos adicionales). Esto se hace para casos en que un módulo tiene dependencias opcionales en otro módulo.

7.3.1. autotools

El elemento autotools se usa para definir un módulo que se compila usando el sistema de construcción 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>

Los atributos autogenargs, makeargs y makeinstallargs se usan para especificar argumentos adicionales para pasarlos a autogen.sh, make y make install respectivamente.

El atributo autogen-sh especifica el nombre del script autogen.sh que ejecutar. Se puede usar el valor autoreconf si su módulo no tiene un script autogen.sh equivalente. En este caso, JHBuild ejecutará autoreconf -fi, seguido del configure apropiado. skip-autogen decide si se ejecuta autogen.sh o no, es un valor booleano con un valor never adicional para indicar a JHBuild que nunca omita la ejecución de autogen.sh. skip-install es un valor booleano que especifica si se debe omitir el comando make install en el módulo. makefile especifica el nombre del archivo makefile que usar.

uninstall-before-install especifica que cualquier archivo antiguo instalado desde el módulo se eliminará antes de ejecutar el paso de instalación. Esto se puede usar para solventar un problema cuando libtool intenta enlazar con una biblioteca que está instalando con otra que se está instalando, pero que debido al uso de DESDIR por parte de JhBuild, encuentra instalada la biblioteca antigua en su lugar. El problema de especificar esto es que puede causar problemas si el usuario está ejecutando actualmente código que depende de los archivos instalados del módulo.

El atributo supports-non-srcdir-builds se usa para marcar módulos que no se pueden construir limpiamente usando una carpeta de fuentes por separado.

El atributo force-non-srcdir-builds se usa para marcar módulos que no se pueden construir limpiamente desde la carpeta de fuentes, pero que sí se pueden construir fuera de ella.

El atributo autogen-template se puede usar si necesita mayor control sobre el comando autogen. Es una cadena en formato Python que se sustituirá con las siguientes variables: srcdir, autogen-sh, prefix, libdir y autogenargs. Por ejemplo, esta es la plantilla predeterminada de autogen:

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

El atributo check-target se debe especificar (con un valor «false») para aquellos módulos que no tienen un objetivo make check.

El atributo supports-static-analyzer se debe especificar (con un valor «false») para aquellos módulos que no soportan la construcción bajo una herramienta de análisis estático, como puede ser scan-build.

El atributo supports-unknown-configure-options se usa para marcar módulos que no se devolverán un error si se les pasa una opción desconocida en configure. Las opciones globales de construcción no se usarán para ese módulo.

7.3.2. cmake

El elemento cmake se usa para definir un módulo que se construirá usando el sistema de construcción CMake.

  <cmake id="nombre del módulo"
            [ cmakeargs="argumentos de cmake" ]
            [ ninjaargs="argumentos de ninja" ]
            [ makeargs="argumentos de make" ]
            [ skip-install="omitir instalación" ]
            [ cmakedir="argumentos de cmake" ]
            [ use-ninja="usar ninja" ]
            [ force-non-srcdir-builds="force-non-srcdir-builds" ]>
  <branch [ ... ] >
    [...]
  </branch>

  <dependencies>
    <dep package="nombre del módulo"/>
    ...
  </dependencies>
  <after>
    <dep package="nombre del módulo"/>
    ...
  </after>
</cmake>

El atributo cmakeargs se usa para especificar argumentos adicionales para pasárselos a cmake.

El atributo nijaargs se usa para especificar argumentos adicionales para pasárselos a ninja.

El atributo makeargs se usa para especificar argumentos adicionales para pasárselos a make.

El atributo cmakedir se usa para especificar la subcarpeta en la que se ejecutará cmake en relación a la carpeta de fuentes.

El atributo force-non-srcdir-builds se usa para marcar módulos que no se pueden construir limpiamente desde la carpeta de fuentes, pero que sí se pueden construir fuera de ella.

El atributo use-ninja se usa para marcar módulos que no se deben construir usando el «backend» Ninja para cmake en lugar de Make. Lo predeterminado es usar Ninja.

7.3.3. Meson

El elemento meson se usa para definir un módulo que configurado usando el sistema de construcción Meson y construido con Ninja

  <meson id="nombre del módulo"
            [ mesonargs="argumentos de meson" ]
            [ ninjaargs="argumentos de ninja" ]
            [ skip-install="omitir instalación" ]>
  <branch [ ... ] >
    [...]
  </branch>

  <dependencies>
    <dep package="nombre del módulo"/>
    ...
  </dependencies>
  <after>
    <dep package="nombre del módulo"/>
    ...
  </after>
</meson>

El atributo mesonargs se usa para especificar argumentos adicionales para pasárselos a meson.

El atributo nijaargs se usa para especificar argumentos adicionales para pasárselos a ninja.

7.3.4. distutils

El elemento distutils se usa para definir un módulo que se construirá usando las distutils de python.

<distutils id="nombre del módulo"
            [ supports-non-srcdir-builds="sí|no" ]>
  <branch [ ... ] >
    [...]
  </branch>

  <dependencies>
    <dep package="nombre del módulo"/>
    ...
  </dependencies>
  <after>
    <dep package="nombre del módulo"/>
    ...
  </after>
</distutils>

7.3.5. linux

El elemento linux define un módulo usado para construir un kernel linux. Además, se puede seleccionar una configuración del kernel aparte usando el subelemento kconfig.

<linux id="id"
	  [ makeargs="argumentos de make" ]>

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

  <dependencies>
    <dep package="nombre del módulo"/>
    ...
  </dependencies>
  <after>
    <dep package="nombre del módulo"/>
    ...
  </after>

  <kconfig [ repo="repositorio" ]
	    version="versión"
	    [ module="módulo" ]
	    [ config="configuración" ] />

</linux>

7.3.6. perl

El elemento perl se usa para construir módulos perl.

El atributo makeargs se usa para especificar argumentos adicionales para pasárselos a make.

<perl id="nombre del módulo"
	 [ makeargs="makeargs" ]>

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

  <dependencies>
    <dep package="nombre del módulo"/>
    ...
  </dependencies>
  <after>
    <dep package="nombre del módulo"/>
    ...
  </after>

</perl>

7.3.7. systemmodule

El elemento systemmodule se usa para especificar módulo que debe proporcionar el sistema. El módulo debe estar instalado por el sistema de gestión de paquetes de su sistema.

<systemmodule id="nombre del módulo">
  <pkg-config>pkg-config.pc</pkg-config>

  <branch repo="sistema" version="versión" />
</systemmodule>

Si el módulo del sistema no proporciona un archivo pkg-config, se puede usar la etiqueta systemdependencies para identificar las dependencias. El atributo type de la etiqueta dep soporta dos valores:

  1. Valor path. La ruta se busca para especificar el nombre del programa.

  2. Valor c_include. Se busca en la ruta de inclusión de C el nombre de la cabecera que coincida. name puede incluir una subcarpeta. La carpeta de búsqueda de inclusiones de C se puede modificar estableciendo CPPFLAGS con las variables de configuración cflags o module_autogenargs.

<systemmodule id="nombre del módulo">
  <branch repo="sistema" version="versión" />
  <systemdependencies>
    <dep type="path" name="nombre del ejecutable" />
  </systemdependencies>
</systemmodule>

<systemmodule id="nombre del módulo">
  <branch repo="sistema" version="versión" />
  <systemdependencies>
    <dep type="c_include" name="nombre de la cabecera" />
  </systemdependencies>
</systemmodule>

Si el módulo se puede instalar en diferentes ubicaciones o con nombres diferentes por distintas distribuciones, se puede usar la etiqueta altdep como subelementos de la etiqueta dep para especificar ubicaciones o nombres alternativos. La etiqueta altdep soporta los mismos atributos que la etiqueta dep.

<systemmodule id="nombre del módulo">
  <branch repo="sistema" version="versión" />
  <systemdependencies>
    <dep type="path" name="nombre del ejecutable">
      <altdep type="path" name="alternativa 1 al nombre del ejecutable" />
      <altdep type="path" name="alternativa 2 al nombre del ejecutable" />
      ...
    <dep>
  </systemdependencies>
</systemmodule>

<systemmodule id="nombre del módulo">
  <branch repo="sistema" version="versión" />
  <systemdependencies>
    <dep type="c_include" name="nombre de la cabecera">
      <altdep type="c_include" name="alternativa 1 al nombre de la cabecera" />
      <altdep type="c_include" name="alternativa 2 al nombre de la cabecera" />
      ...
    <dep>
  </systemdependencies>
</systemmodule>

7.3.8. waf

El elemento waf se usa para definir un módulo que se construirá con el sistema de construcción Waf.

El atributo waf-command se usa para especificar el script del comando waf a usar; el predeterminado es waf.

El atributo python-command se usa para especificar el ejecutable de Python que usar; el predeterminado es python. Esto es útil para construir módulos con la versión 3 de Python.

<waf id="nombre del módulo">
	 [ python-command="comando python" ]
	 [ waf-command="comando waf" ]>
  <branch [ ... ] >
    [...]
  </branch>

  <dependencies>
    <dep package="nombre del módulo"/>
    ...
  </dependencies>
  <after>
    <dep package="nombre del módulo"/>
    ...
  </after>
</waf>

7.3.9. testmodule

El elemento testmodule se usa para crear un módulo que ejecute un conjunto de pruebas usado LDTP o Dogtail.

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

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

  <dependencies>
    <dep package="nombre del módulo"/>
    ...
  </dependencies>
  <after>
    <dep package="nombre del módulo"/>
    ...
  </after>

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

</testmodule>

El atributo type contiene el tipo de pruebas que ejecutar en el módulo. «dogtail» usa Python para invocar a todos los archivos .py. «ldtp» invoca «ldtprunner run.xml».

A menos que la opción de configuración «noxvfb» esté establecida, se inicia un servidor Xvfb para ejecutar las pruebas en él.

7.3.10. metamodule

El elemento metamodule define un módulo que actualmente no hace nada. El único propósito de un módulo de este tipo son sus dependencias.

Por ejemplo, meta-gnome-desktop depende de todos los elementos clave del escritorio GNOME, por lo que actualmente, decirle a JHBuild que lo instale, instala el escritorio completo.

<metamodule id="nombre del módulo">
  <dependencies>
    <dep package="nombre del módulo"/>
    ...
  </dependencies>
  <suggests>
    <dep package="nombre del módulo"/>
    ...
  </suggests>
</metamodule>

El atributo id proporciona el nombre del módulo. Los elementos hijos se manejan igual que para autotools.

7.4. Elementos obsotelos

7.4.1. Repositorios de módulos

7.4.1.1. cvsroot

El elemento cvsroot está obsoleto; en su lugar, se debe usar el elemento repository.

El elemento cvsroot se usa para describir un repositorio CVS.

  <cvsroot name="nombre del raíz"
           [ default="sí|no" ]
           root="cvsroot-anónimo"
           password="contraseña-anónima"/>

El atributo name debe ser un identificador único para el repositorio CVS.

El atributo default indica si es el repositorio de módulos predeterminados para ese archivo de conjuntos de módulos.

El atributo root lista la raíz de CVS usada para acceso anónimo a este repositorio, y el atributo password da la contraseña usada para el acceso anónimo.

7.4.1.2. svnroot

El elemento svnroot está obsoleto; en su lugar se debe usar el elemento repository.

El elemento svnroot se usa para describir un repositorio de Subversion.

  <svnroot name="nombre del raíz"
           [ default="sí|no" ]
           href="svnroot-anónimo"/>

El atributo name debe ser un identificador único para el repositorio de Subversion.

El atributo default indica si es el repositorio de módulos predeterminados para ese archivo de conjuntos de módulos.

El atributo href lista el URL base del repositorio. Probablemente será un URL http, https o svn.

7.4.2. Tipos de módulos obsoletos

Esta sección describe elementos obsoletos, aún se deben usar en conjuntos de módulos existentes, pero se recomienda que no se usen más.

7.4.2.1. archivo tar

El elemento obsoleto es sólo una fina envoltura alrededor del tipo de módulo autotools y del tipo de repositorio tarball.

El elemento tarball se usa para definir un módulo que se construirá a partir de un archivo tar.

  <tarball id="nombre del módulo"
              [ version="versión" ]
              [ checkoutdir="carpeta de descarga" ]
              [ autogenargs="argumentos de autogen" ]
              [ makeargs="argumentos de make" ]
              [ autogen-sh="autogen-sh" ]
              [ supports-non-srcdir-builds="sí|no" ]>
    <source href="URL de la fuente"
            [ size="tamaño de la fuente" ]
            [ hash="algoritmo-fuente:hash-fuente" ]
            [ md5sum="md5sum de la fuente" ]/>
    <patches>
      <patch file="nombre de archivo" strip="nivel"/>
      ...
    </patches>
    <dependencies>
      <dep package="nombre del módulo"/>
      ...
    </dependencies>
    <suggests>
      <dep package="nombre del módulo"/>
      ...
    </suggests>
  </tarball>

Los atributos id y version se usan para identificar el módulo.

El elemento source especifica el archivo que se descargará y compilará. El atributo href es obligatorio mientras que los atributos size y hash, al igual que el obsoleto md5sum, son opcionales. Si los dos últimos están presentes, se usan para comprobar que el paquete fuente se ha descargado correctamente.

El elemento patches se utiliza para especificar uno o más parches para aplicarlos al árbol de fuentes después de descomprimirlo. El atributo file contiene el nombre el nombre de archivo del parche y el atributo strip dice a cuántos niveles de carpetas se descenderá al aplicar el parche.

Para conjuntos de módulos empaquetados con JHBuild, los archivos de parches se buscan en la carpeta jhbuild/patches/; para conjuntos de módulos referidos por el URI, los archivos de parches se buscan en la misma carpeta que el archivo del conjunto de módulos, o en su subcarpeta patches/. También es posible que el atributo file especifique un URI, en cuyo caso se descargará de esa ubicación.

Los otros atributos y los elementos dependencies, suggests y after se procesan de la misma manera que para el comando autotools.