# Manual de JHBuild

## Introducción

JHBuild es una herramienta diseñada para construir fácilmente colecciones de paquetes fuente (también conocidos como módulos). JHBuild Usa archivos de conjuntos de módulos para describir los módulos disponibles para construir. El conjuntos de módulos incluye información de las dependencias que permite a JHBuild averigüar qué módulos debe construir y en qué orden.

Originalmente JHBuild se escribió para construir GNOME, pero se ha extendido para hacerlo usable con otros proyectos. Se puede almacenar un conjunto de módulos en un servidor web, para permitir reglas de construcción independientes de JHBuild.

JHBuild puede construir módulos desde varias fuentes, incluyendo los repositorios de CVS, Subversion, Bazaar, Darcs, Git y Mercurial, así como archivos Zip y Tar almacenados en una web o un sitio FTP. JHBuild puede construir módulos usando varios sistemas de construcción, incluyendo Autotools, CMake, Meson, WAF, Python Distutils y Perl Makefiles.

JHBuild no está pensado para sustituir al sistema de mantenimiento de paquetes de la distribución. En cambio, facilita la construcción de software con un prefijo de instalación diferente, sin interferir con el resto del sistema.

## Inicio

JHBuild requiere unos pocos pasos para configurarlo antes de construir software. JHBuild requiere algunos prerrequisitos software, y es necesario instalar las herramientas de prerrequisitos necesarias para obtener y construir los módulos de software.

### Instalar JHBuild

JHBuild requiere una rutina de Python. Verifique que Python >= 2.3 está instalado.

La forma recomendada de descargar JHBuild es a través del sistema de control de versiones, `git`. Esto puede hacerlo con el siguiente comando. Se recomienda ejecutarlo en una carpeta nueva donde se instalará todo el código fuente, por ejemplo, `~/jhbuild/checkout`.

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

Esto descargará JHBuild en una nueva carpeta llamada `jhbuild` en la carpeta actual. Ahora, para construir e instalar JBuild:

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

Si gnome-common, yelp-tools y autotools está disponibles, `autogen.sh` configurará JHBuild para instalarlos mediante autotools. Si gnome-common, yelp-tools y autotools no está disponibles, `autogen.sh` configurará JHBuild para instalarlos mediante un Makefile. Para usar siempre el método del Makefile, pase `--simple-install` a `autogen.sh`.

Si estos pasos se completan correctamente se instalará una pequeña línea de comandos en `~/.local/bin` para iniciar JHBuild. Añada `~/.local/bin` a la variable `PATH`:

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

Para añadir permanentemente `~/.local/bin` a la variable `PATH`, ejecute el siguiente comando:

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

### Configurar JHBuild

Se puede configurar JHBuild mediante el archivo de configuración. su ubicación predeterminada es `~/.config/jhbuildrc`. Si no existe un archivo de configuración, se usarán los valores predeterminados. El archivo de configuración usa la sintaxis de Python. Se proporciona un ejemplo en `examples/sample.jhbuildrc`. Copie `examples/sample.jhbuildrc` a `~/.config/jhbuildrc` y personalícelo como necesite.

La configuración de ejemplo hará que JHBuild construya los módulos meta-gnome-core y meta-gnome-apps-tested y sus dependencias desde el conjunto de módulos `gnome-apps`. JHBuild descomprimirá los árboles de fuentes en `~/jhbuild/checkout/` e instalará todos los archivos en subcarpetas de `'~/jhbuild/install/'`. Las dos carpetas deben ser escribibles.

Las variables de configuración están documentadas en config-reference. Las variables más comúnmente usadas son:

`repos`

- Un diccionario que puede usarse para especificar la ubicación de un repositorio alternativo para uno en particular. Esta variable de configuración es útil para un desarrollador de módulos. De manera predeterminada, JHBuild descargará código de los repositorios usando una ubicación de repositorio anónima. Las claves del diccionario son nombres cortos de repositorios y los valores son las cadenas de ubicación de los repositorios alternativos. Por ejemplo:

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

`moduleset`

- Una cadena o una lista de cadenas que contiene los nombres de los conjuntos de módulos que se usarán. También puede ser el nombre de archivo de un conjunto de módulos incluido en JHBuild (excluyendo la ruta y la extensión), o un URL completo a un conjunto de módulos administrado externamente. Los URL se almacenan localmente en la caché. si un módulo con el mismo nombre aparece en más de un conjunto de módulos, tendrá prioridad la última lista configurada. Los conjuntos de módulos proporcionados con JHBuild se actualizan para que coincididan con la versión liberada de desarrollo de GNOME.

`modules`

- Una lista de cadenas especificando los módulos que construir. La lista de los módulos actualmente construidos se expandirá recursivamente para incluir todas las dependencias, salvo que se use el comando `buildone`. Su valor predeterminado es `['meta-gnome-desktop']`.

`checkoutroot`

- Una cadena que especifica la carpeta donde descomprimir los árboles de fuentes. Si `buildroot` se establece a `None`, las construcciones se harán también en esta carpeta. El valor predeterminado es `~/jhbuild/checkout`.

`prefix`

- Una cadena que indica el prefijo donde instalar módulos.`prefix` debe ser una ruta absoluta. Esta carpeta debe ser escribible. La carpeta predeterminada es `'~/jhbuild/install/'`.

`autogenargs`

- Una cadena que contiene los argumentos pasados al script `autogen.sh` de todos los módulos. Se pueden omitir para algunos módulos concretos usando el diccionario `module_autogenargs`.

`cmakeargs`

- Una cadena que contiene los argumentos pasados a la invocación de `cmake` de todos los módulos. Se pueden omitir para algunos módulos concretos usando el diccionario `module_cmakeargs` dictionary.

`makeargs`

- Una cadena que lista argumentos adicionales para pasarlos a `make`. JHBuild añadirá automáticamente la opción de ejecución en paralelo (`-j`) basándose en la disponibilidad de los núcleos de la CPU. Lo predeterminado es `''`.

`mesonargs`

- Una cadena que contiene los argumentos pasados a la invocación de `meson` de todos los módulos. Se pueden omitir para algunos módulos concretos usando el diccionario `module_mesonargs`

`ninjaargs`

- Una cadena que lista los argumentos que pasar a `ninja`. El valor predeterminado es `''`.

### Prerrequisitos para la construcción

Antes de poder construir cualquier módulo es necesario tener ciertas herramientas de construcción instaladas. Las herramientas habituales incluyen las GNU Autotools (autoconf, automake, libtool y gettext), Las GNU Toolchain (binutils, gcc, g++), make, pkg-config y Python, dependiendo de qué módulos se construirán.

JHBuild puede comprobarlas herramientas están instaladas usando el comando `sanitycheck`:

    $ jhbuild sanitycheck

Si el comando muestra algún mensaje, instale el paquete requerido del repositorio de su distribución. El wiki de GNOME mantiene una lista de nombres de paquetes para diferentes distribuciones. Ejecute otra vez el comando `sanitycheck` depsués de instalar los paquetes para asegurarse de que las herramientas necesarias están instaladas.

### Usar JHBuild

Después de que todo esté configurado, se puede usar JHBuild para construir software. Para construir los todos módulos seleccionados en el archivo `~/.config/jhbuildrc`., ejecute el siguiente comando:

    $ jhbuild build

JHBuild descargará, configurará, compilará e instalará cada uno de los módulos. Si ocurre un error en cualquier fase, JHBuild mostrará un menú preguntando qué hacer. Estas opciones incluyen salir a una consola para reparar el error, volver a ejecutar la construcción desde varias fases, abandonar el módulo, o ignorar el error y continuar.

Desistir de cargar un módulo causará que todos los módulos que dependan de él fallen.

Debajo hay un ejemplo con el menú mostrado:

      [1] Volver a ejecutar la fase de construcción
      [2] Ignorar error y continuar la instalación
      [3] Desistir de cargar el módulo
      [4] Iniciar consola
      [5] Recargar configuración
      [6] Ir a la fase «limpiar carpeta y empezar»
      [7] Ir a la fase «configurar»
      [8] Ir a la fase «limpiar»
      [9] Ir a la fase «distclean»
    choice:

También es posible construir un conjunto de módulos diferentes y sus dependencias pasando los nombres de módulos como argumentos al comando `build`. Por ejemplo, para construir gtk+:

    $ jhbuild build gtk+

Si por cualquier razón sale de JHBuild a mitad de una construcción, es posible recuperar la construcción en un momento particular utilizando la opción `--start-at`:

    $ jhbuild build --start-at=pango

Para construir uno o más módulos, ignorando sus dependencias, JHbuild proporciona el comando `buildone`. Para que el comando `buildone` funcione correctamente, previamente debe construir e instalar todas las dependencias, manualmente o desde los paquetes de la distribución.

    $ jhbuild buildone gtk+

Cuando desarrolla activamente un módulo, generalmente está en una carpeta de trabajo. El comando `make` invocará al sistema de construcción e instalará el módulo. Esto será una parte clave de su ciclo de edición-compilación-instalación-pruebas.

    $ jhbuild make

Para obtener una lista de los módulos y las dependencias que JHBuild construirá, y el orden en que se construirán, use el comando `list`:

    $ jhbuild list

Para obtener información acerca de un módulo en particular, use el comando `info`:

    $ jhbuild info gtk+

Para descargar o actualizar todas las fuentes de software sin construir use el comando `update`. El comando `update` ofrece la oportunidad de modificar las fuentes antes de construir y puede ser útil si el ancho de banda de Internet varía.

    $ jhbuild update

Posteriormente JHBuild puede construir todo sin descargar ni actualizar los fuentes:

    $ jhbuild build --no-network

Para ejecutar un comando concreto con el mismo entorno que usa JHBuild, use el comando `run`:

    $ jhbuild run programa

Para iniciar una consola con el mismo entorno usado por JHBuild use el comando `shell`:

    $ jhbuild shell

## JHBuild y GNOME

Esta sección proporciona directrices para construir, instalar y ejecutar GNOME.

### Construir GNOME

Para construir GNOME se requieren algunos paquetes de desarrollo. Esto incluye:

- DocBook XML DTD y hojas de estilo XSLT. Deben registrarse en el catálogo XML (`/etc/xml/catalog`).

- Bibliotecas de las X.

- `libsmbclient` de Samba (usado para examinar redes Windows).

- `libbz2` de bzip2.

- `libpng`, `libjpeg` y `libtiff` (usada para cargar imágenes).

Si está instalando paquetes de su distribución, y si es aplicable a ésta, instale los paquetes dev o devel correspondientes. En el wiki de GNOME se mantiene una lista de nombres de paquetes para las distintas distribuciones.

### Ejecutar una única aplicación de GNOME

Esta sección detalla como ejecutar una única aplicación de GNOME. La aplicación se ejecutará dentro del actual entorno de escritorio. Para ejecutar la aplicación dentro de GNOME JHBuild completo consulte la running-gnome.

Lanzar una consola de JHBuild. La consola de JHBuild tiene configuradas todas las variables de entorno necesarias.

    $ jhbuild shell

Verificar que se ejecutará la aplicación correcta. Por ejemplo:

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

Ejecutar la aplicación:

    $ gedit &

Alternativamente, ejecute la aplicación usando el comando `run`:

    $ jhbuild run gedit

### Ejecutar el entorno de escritorio GNOME

Cree una cuenta de usuario nueva para ejecutar JHBuild GNOME. Se recomienda ejecutar JHBuild GNOME con un usuario diferente para evitar problemas causados por configuraciones de usuario guardadas en la carpeta del usuario. Este manual se refiere a la cuenta nueva como `gnomedev`.

Configure JHBuild en la cuenta `gnomedev` nueva. Copie o cree un enlace simbólico de `~/.config/jhbuildrc` y `~/.local/bin/jhbuild` a la carpeta del usuario `gnomedev`.

Abrir una terminal como usuario `gnomedev`. Para añadir permanentemente `~/.local/bin` a la variable `PATH`, ejecute el siguiente comando:

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

Probar si JHBuild funciona:

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

#### Configurar GNOME para ejecutarse desde el gestor de ventanas

Construir e instalar JHBuild GNOME

Activar servicios del sistema. JHBuild GNOME usará el demonio D-Bus del sistema `/usr/bin` y los servicios del sistema con `/usr/share/dbus-1/system-services/`. JHBuild GNOME usará el demonio de sesión D-Bus de JHBuild y los servicios con ``~/jhbuild/install/`/share/dbus-1/services/`. Sustituya `~/jhbuild/install`. con el `prefix` de instalación de GNOME en el siguiente comando:

    $ 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

Cree un script de inicio de GNOME en `/usr/bin/gnome-jhbuild-session` con el siguiente contenido, sustituyendo `~/jhbuild/checkout`. por el `prefix` de instalación de GNOME :

    #!/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

Haga ejecutable el archivo `/usr/bin/gnome-jhbuild-session`:

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

Para añadir una entrada de sesión nueva en el gestor de sesiones, cree `/usr/share/xsessions/gnome-jhbuild.desktop` e introduzca:

    [Desktop Entry]
    Name=GNOME (JHBuild)
    Comment=Esta sesión inicia la sesión de pruebas de GNOME
    TryExec=/usr/bin/gnome-jhbuild-session
    Exec=/usr/bin/gnome-jhbuild-session
    Icon=
    Type=Application

Reiniciar `gdm`.

#### Ejecutar GNOME desde el gestor de ventanas

Para ejecutar JHBuild GNOME seleccione la sesión GNOME (JHBuild) en el gestor de ventanas antes de introducir las credenciales de inicio de sesión de `gnomedev`. Si es correcto, se mostrará JHBuild GNOME. Si es incorrecto, compruebe el archivo de registro que se encuentra en `~gnomedev/.cache/gdm/session.log` o en `~gnomedev/.xsession-errors`.

### Análisis de estadísticas

JHBuild soporta ejecutar herramientas de análisis de estadísticas en el código de los módulos a medida que se construyen. Para activa esto, establezca la variable de configuración `static_analyzer` a `True` en el archivo de configuración `.jhbuildrc`.

Si está activada, cada vez que se construya un módulo usando JHBuild, el proceso de construcción se incluirá en un analizador estático que generará un informe de cuaqlquier problema encontrado en el código. Estos informes se guardan en HTML, en subcarpetas de `/tmp/jhbuild_static_analyzer` (de manera predeterminada; la ruta se puede cambiar en la variable de configuración `static_analyzer_outputdir`).

Actualmente, el análisis estático sólo funciona con módulos que usen autotools como sistema de construcción. Requiere que el programa `scan-build` esté instalado, aunque el comando que usa se puede cambiar modificando la variable de configuración `static_analyzer_template`.

## Integración con buildbot

Junto al proyecto Buildbot, JHBuild puede funcionar también como una herramienta de integración. El proyecto GNOME usa la configuración de Buildbot en build.gnome.org.

### Configurar un Buildbot esclavo

Un Buildbot esclavo es una variación de una instalación normal de JHBuild que sirve las peticiones a un Buildbot maestro. Se recomienda configurar JHBuild y completar una ejecución con la mayoría de los módulos construyéndose bien antes de añadir las configuraciones personalizadas de Buildbot.

Los comandos de Buildbot son opciones del comando `bot`. Para descargar e instalar el software adicional requerido ejecute el siguiente comando:

    $ jhbuild bot --setup

Una vez que este paso ha terminado correctamente, hay tres nuevas variables de configuración para definir en `~/.config/jhbuildrc`.

No se puede usar un archivo alternativo de configuración. La opción `--file` no tendrá los efectos deseados.

    jhbuildbot_master = 'build.gnome.org:9070'
    jhbuildbot_slavename = 'nombredelesclavo'
    jhbuildbot_password = 'contraseña'

`jhbuildbot_master` es una cadena que especifica el servidor Buildbot maestro; el predeterminado es `'build.gnome.org:9070'`. `jhbuildbot_slavename` y `jhbuildbot_password` identifican al esclavo en el servidor maestro; contacte con los administradores del servidor Buildbot maestro para obtenerlos.

Se puede contactar con los administradores de build.gnome.org en la lista de correo de Build Brigade.

## Referencia de comandos

JHBuild usa una sintaxis de línea de comandos similar a la de herramientas como CVS:

    jhbuild opciones globales comando argumentos del comando

Las opciones globales de JHBuild son:

`-f`, `--file` `configuración`

- Use un archivo de configuración alternativo, en lugar del predeterminado, `~/.config/jhbuildrc`.

`-m`, `--moduleset` `conjunto de módulos`

- Usar un conjunto de módulos diferente del que aparece listado en el archivo de configuración. Esta opción puede ser una ruta relativa si el conjunto de módulos está ubicado en la carpeta de módulos de JHBuild, o una ruta absoluta si está ubicado en otro sitio.

`--no-interact`

- No solicitar al usuario ninguna entrada. Esta opción es útil cuando se deja una construcción sin atender, para asegurarse de que no se interrumpe.

`--exit-on-error`

- Salir inmediatamente si un módulo falla al construirlo. Esta opción se usa principalmente en el modo no interactivo, para asegurar que JHBuild no sigue construyendo módulos adicionales.

`--conditions`

- Modificar las opciones de condiciones para que sean diferentes de las determinadas basándose en el sistema operativo y de las especificadas en el jhbuildrc. Las modificaciones se indican como `-wayland` o `+docs` para quitar o añadir condiciones. Si hay varias modificaciones se pueden separar por comas, como `--conditions=+docs,-wayland` o puede dividirlas en varios argumentos `--conditions`.

De manera adicional, JHBuild comprueba que existan y el valor de las siguientes variables de entorno:

`JHBUILD_RUN_AS_ROOT`

- De manera predeterminada, JHBuild no se ejecuta con usuario root, para evitar operaciones destructivas que puedan afectar al sistema completo. Sin embargo, en ciertos casos es aceptable ejecutar JHBuild como root; por ejemplo, dentro de un contenedor o en un entorno de integración continua. Al exportar la variable `JHBUILD_RUN_AS_ROOT` se desactivará la comprobación del ID del usuario al inicio.

A continuación se listan las opciones específicas de los comandos.

### autobuild

El comando `autobuild` construye automáticamente los módulos tal y como se especifica en el archivo de configuración, y sube los resultados a JhAutobuild.

    jhbuild autobuild --autogen --clean --distcheck --skip=módulo --start-at=módulo --report-url=URL --verbose

Las opciones `--autogen`, `--clean`, `--distcheck`, `--skip` y `--start-at` se procesan de la misma manera que para el comando `build`.

`--report-url=`reporturl``, `-r `reporturl``

- Esta opción especifica el URL de JhAutobuild a la que se debe informar

`--verbose`, `-v`

- Si está especificado, la salida de JHBuild será más detallada.

### bootstrap

El comando `bootstrap` instala un conjunto de herramientas de construcción. Estas herramientas incluyen autoconf, automake y herramientas similares. El método recomendado para instalar las herramientas de construcción es mediante el sistema de gestión de paquetes de su distribución. `bootstrap` sólo se debe usar si el sistema de gestión de paquetes de su distribución no proporciona las herramientas de construcción, como pasa por ejemplo en `Mac OS`.

    jhbuild bootstrap

El comando, `bootstrap` construye módulos usando el mismo método que el comando `build`, pero usa el conjunto de módulos `bootstrap.modules`.

Consulte la documentación del comando `build` para ver las opciones disponibles.

### build

El comando `build` construye uno o más paquetes, incluyendo sus dependencias.

    jhbuild build --autogen --clean --check --dist --distcheck --distclean --ignore-suggests --no-network --skip=módulo --start-at=módulo --tags=etiquetas -D fecha --no-xvfb --try-checkout --no-poison --force --build-optional-modules --min-age=hora --nodeps módulo

Si no se indican nombres de módulos en la línea de comandos, se usará la lista de módulos del archivo de configuración.

`-a`, `--autogen`

- Ejecute `autogen.sh` antes de construir los módulos.

`-c`, `--clean`

- Ejecute `make clean` antes de construir los módulos.

`--check`

- Ejecute `make check` después de construir los módulos.

`-d`, `--dist`

- Ejecute `make dist` después de construir los módulos.

`--distcheck`

- Ejecute `make distcheck` después de construir los módulos.

`--distclean`

- Para módulos de git, ejecute `git clean -dfx` antes de construir los módulos. para otros módulos, ejecute `make distclean` antes de construir los módulos.

  Esta opción eliminará todos los cambios no efectuados.

`--ignore-suggests`

- No construir las dependencias suaves

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

- No acceda a la red mientras esté construyendo módulos. Esto omitiría la descarga o etapas de la actualización en una construcción. Si no se puede construir un módulo sin acceso a la red, dará un error.

`-s`, `--skip`=`módulo,...`

- No construir los módulos listados. Usado para omitir la construcción de determinadas dependencias.

`--tags`=`etiqueta,...`

- Ignorar los módulos que no coinciden con `etiqueta`. Los módulos se asignan automáticamente a una etiqueta que coincide con el nombre del conjunto de módulos del módulo.

`-t`, `--start-at`=`módulo`

- Comenzar en el módulo nombrado en lugar de por el principio de la lista. Esto es útil si se interrumpió la construcción por algún motivo.

`-D` `fecha`

- Si la versión del sistema de control de versiones subyacente lo soporta, actualice el árbol de repositorios a su estado en la fecha dada antes de la construcción. La fecha debe estar en formato ISO, ej `«2009-09-18 02:32Z»`.

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

- Ejecutar comprobaciones gráficas en el servidor X actual en lugar de en un Xvfb simulado.

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

- Si falla la construcción, y el sistema de control de versiones lo soporta, fuerce una descarga y ejecute `autogen.sh` antes de reintentar la construcción.

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

- Si falla una o más dependencias de un conjunto de módulos, esta opción fuerza a JHBuild a intentar construir el módulo de todas formas.

`-f`, `--force`

- Construir los módulos aunque la política diga que no es necesario.

`--build-optional-modules`

- Los módulos, listados como dependencias opcionales, pueden no ser necesarios para construir el módulo. Esta opción fuerza a JHBuild a construir las dependencias opcionales.

`--min-age`=`tiempo`

- Omitir módulos instalados más recientemente que la fecha relativa dada; el formato de la cadena `time` es un número seguido de una unidad. Se soportan las siguientes unidades: segundos (s), minutos (m), horas (h) y días (d). Por ejemplo, `--min-time=2h` omitirá los módulos construidos hace menos de dos horas.

`--nodeps`

- Ignorar las dependencias que falten. para ignorar una única dependencia del sistema, añada el módulo a `skip`.

### make

El `make` es para desarrollar activamente en un módulo en particular. Requiere que la carpeta actual sea una descargar de fuentes y es equivalente a `buildone -nf $(basename $(pwd))`.

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

Las opciones son las mismas que las disponibles para el comando `buildone`.

### buildone

El comando `buildone` es similar a `build`, pero no construye los módulos dependientes. Es útil para reconstruir uno o más módulos.

    jhbuild buildone --autogen --clean --check --distcheck --distclean --no-network -D date --no-xvfb --force --min-age=hora --nodeps módulo

Las opciones `--autogen`, `--check`, `--clean`, `-d`, `--distcheck`, `--distclean`, `--no-network`, `-D`, `-x` y `--nodeps` se procesan de la misma manera que para el comando `build`.

Se debe listar al menos un módulo en la línea de comandos.

### checkbranches

El comando `checkbranches` comprueba que las ramas de módulos están definidas correctamente en sistema de control de versiones, y que las ramas son consistentes con el conjunto de módulos.

    jhbuild checkbranches --branch=rama

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

- La rama para comprobar.

    $ jhbuild -m gnome-2.20 checkbranches
    libgnomecanvas es una definición de rama desconocida para gnome-2-20
    $

### clean

El comando `clean` limpia las carpetas de construcción de uno o más módulos.

    jhbuild clean --skip=módulo --start-at=módulo

Si no se indican nombres de módulos en la línea de comandos, se usará la lista de módulos del archivo de configuración.

Consulte la documentación del comando `build` para obtener una descripción de las opciones disponibles.

### dot

El comando `dot` genera un archivo que describe el grafo dirigido formado por las dependencias entre un conjunto de módulos. Se puede procesar este archivo usando el software GraphViz para generar un diagrama.

    jhbuild dot --soft-deps --clusters módulo

Si no se indican nombres de módulos en la línea de comandos, se usará la lista de módulos del archivo de configuración.

La opción `--soft-deps` añadirá líneas de puntos desde los módulos hasta sus dependencias débiles. La opción `--clusters` agrupará los módulos de los metamódulos juntos.

La salida del comando «dot» se puede redirigir a la utilidad «dot» para generar un archivo PostScript:

    $ jhbuild dot módulos | dot -Tps > dependencies.ps

O una imagen PNG:

    $ jhbuild dot módulos | dot -Tpng > dependencies.png

#### Ejemplo de salida de JHBuild dot

### gui

El comando `gui` inicia una interfaz gráfica de JHBuild que se puede usar para seleccionar los módulos que construir y cambiar algunas opciones.

    jhbuild gui

La interfaz gŕafica se renderiza usando GTK, por lo que se necesitarán algunas bibliotecas de soporte adicionales.

### info

El comando `info` muestra información de uno o más módulos.

    jhbuild info --installed módulo

El comando muestra el nombre del módulo, el tipo, sus dependencias, paquetes dependientes, la carpeta origen y la hora en que fue instalado con JHBuild. Si está disponible, también mostrará información específica del tipo de módulo, tal como el repositorio CVS o el URL de descarga.

Si no se especifica ningún módulo el comando mostrará información acerca de todos los módulos definidos en el conjunto de módulos.

Si es especifica la opción `--installed`, se filtrará la salida para incluir sólo los paquetes instalados. La salida resultante solo contendrá módulos que actualmente se han construído e instalado con JHBuild. La salida no incluye dependencias del sistema.

Si es especifica la opción `--installed`, junto con uno o más nombres de módulos, sólo se mostrarán los módulos instalados (sin incluir las dependencias del sistema). Si al menos uno de los módulos no está instalado, el comando devolverá 1.

### list

El comando `list` se usa para mostrar una lista expandida de los módulos que el comando `build` construiría.

    jhbuild list -a -r -s --start-at=módulo --tags=etiquetas --ignore-suggests --list-optional-modules módulo

Si no se indican nombres de módulos en la línea de comandos, se usará la lista de módulos del archivo de configuración.

Las opciones `--skip`, `--start-at`, `--tags`, `--ignore-suggests` y `-D` se procesan de la misma manera que para el comando `build`.

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

- Listar todos los módulos del conjunto de módulos sin importar sus dependencias de construcción.

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

- Si se asigna un módulo a una rama, mostrar el nombre de la rama con el nombre del módulo.

`--list-optional-modules`

- Esta opción fuerza a JHBuild a listar dependencias opcionales

### rdepends

El comando `rdepends` muestra las dependencias inversas de un módulo.

    jhbuild rdepends módulo

`--dependencies`

- Mostrar las dependencias junto a los módulos.

`--direct`

- Limitar la muestra a los módulos directamente dependientes del módulo dado.

### run

El comando `run` ejecuta un comando especificado usando el mismo entorno que usa JHBuild cuando construye los módulos.

    jhbuild run --in-builddir --in-checkoutdir programa argumento

Si usa JHBuild para construir GNOME este comando puede ser útil en los scripts de inicio de las X.

`--in-builddir`=`módulo`

- Ejecute el comando en la carpeta de construcción del módulo especificado.

`--in-checkoutdir`=`módulo`

- Ejecute el comando en la carpeta de fuentes del módulo especificado.

### sanitycheck

El comando `sanitycheck` lleva a cabo una serie de comprobaciones para ver si el entorno de construcción es correcto.

    jhbuild sanitycheck

Algunas de las comprobaciones incluyen:

- Los prefijos de descarga e instalación son escribibles.

- Las herramientas de construcción requeridas están instaladas.

- Algunas macros usadas habitualmente están disponibles en la rutas de búsqueda de los comandos de `aclocal`, asociados con varias versiones de `automake`.

- El catálogo XML contiene la DTD de DocBook y hojas de estilos.

### shell

El comando `shell` inicia una consola de usuario con el mismo entorno que usa JHBuild cuando construye los módulos.

    jhbuild shell

Este comando es equivalente al siguiente:

    $ jhbuild run $SHELL

La variable de entorno `UNDER_JHBUILD` se establecerá a «true» cuando esta consola esté activa. Puede usar la presencia de esta variable para personalizar el «prompt» de su consola para indicar que, efectivamente, se encuentra en una consola controlada por jhbuild. Por ejemplo, puede querer incluir esto en su `.bashrc`:

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

Esto hará que su consola bash muestre `[jhbuild]` antes de su «prompt» normal, haciendo más fácil ver que consolas están bajo un entorno jhbuild.

### sysdeps

El comando `sysdeps` muestra:

1. una lista de los paquetes del sistema isntalados que se usarán durante la construcción. JHBuild no construirá estos módulos, sino que usará el paquete del sistema instalado en su lugar.

2. una lista de paquetes requeridos. Su sistema debe proporcionarla para empezar a construir los paquetes.

3. una lista de paquetes opcionales. No se ha encontrado el paquete del sistema correspondiente o es demasiado antiguo. JHBuild construirá el módulo. Los paquetes opcionales no se mostrarán si `partial_build` es `False`.

    jhbuild sysdeps --install

`--install`

- Esta opción instala paquetes del sistema que son dependencias del conjunto de módulos. El método de instalación depente de su distribución. Los paquetes del sistema se instalan usando PackageKit, si está disponible. Para distribuciones que usan APT como `Debian` y `Ubuntu`, esta opción requiere que apt-file esté instalado.

#### ejemplo de `sysdeps`

    $ jhbuild sysdeps
    Paquetes del sistema instalados suficientemente nuevos:
      speex (speex.pc required=1.2rc1, installed=1.2rc1)
      lcms2 (lcms2.pc required=2.2, installed=2.2)
    ...
    Paquetes requeridos:
      Paquetes del sistema instalados demasiado antiguos:
        (ninguno)
    No coincide con ningún paquete del sistema instalado:
        zlib (zlib.pc required=1.2)
    Paquetes opcionales: (JHBuild construirá los paquetes que falten)
      Paquetes del sistema instalados demasiado antiguos:
        WebKit (webkitgtk-3.0.pc required=1.5.1, installed=1.4.0)
        ...
      No coincide con ningún paquete del sistema instalado:
        pulseaudio (libpulse.pc required=2.0)
        ...

### tinderbox

El comando `tinderbox` es parecido a `build`, pero guarda toda la salida del terminal en archivos HTML aptos para publicarlos en un sitio web. Se puede usar para configurar sistemas parecidos a Tinderbox de Mozilla o o Buildd de Debian.

    jhbuild tinderbox --autogen --clean --distclean --no-network --output=carpeta --skip=módulo --start-at=módulo -D fecha -C -N -f --nodeps módulo

Las opciones `--autogen`, `--clean`, `--distclean`, `--no-network`, `--skip`, `--start-at`, `-D`, `-C`, `-N`, `-f` y `--nodeps` ose procesan de la misma manera que para el comando `build`.

`-o`, `--output`=`carpeta`

- La carpeta en la que escribir los archivos HTML. JHBuild creará un índice (`index.html`) y un archivo HTML para cada módulo

### uninstall

El comando `uninstall` desinstala uno o más módulos.

    jhbuild uninstall módulo

### update

El comando `update` es similar a `build`, pero sólo realiza la fase de descarga o actualización de los módulos sin construirlos.

    jhbuild update --skip=módulo --start-at=módulo --tags=etiquetas --ignore-suggests -D fecha módulo

Las opciones `--skip`, `--start-at`, `--tags`, `--ignore-suggests` y `-D` se procesan de la misma manera que para el comando `build`.

### updateone

El comando `updateone` es similar a `update`, pero no actualiza los módulos dependientes. Es útil para actualizar uno o varios módulos.

    jhbuild updateone -D date module

La opción `-D` se procesa de la misma manera que para el comando `build`.

Se debe listar al menos un módulo en la línea de comandos.

## Referencia del archivo de configuración

El archivo `~/.config/jhbuildrc` usa la sintaxis estándar de Python. Se ejecuta el archivo, y las variables resultantes, definidas en el espacio de nombres, se usan para controlar como actúa JHBuild. Se inserta un conjunto de valores predeterminados en el espacio de nombres antes de ejecutar el archivo de configuración del usuario.

Las variables de configuración booleanas se establecen usando una sintaxis como se demuestra en el siguiente ejemplo:

    use_local_modulesets = True

Las variables de configuración de tipo cadena se establecen usando una sintaxis como se demuestra en el siguiente ejemplo:

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

Las variables de configuración de tipo lista se establecen usando una sintaxis como se demuestra en el siguiente ejemplo:

    skip = ['mozilla', 'pulseaudio']

Las variables de configuración de tipo diccionario se establecen usando una sintaxis como se demuestra en el siguiente ejemplo:

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

### Variables de configuración

`alwaysautogen`

- Si se establece un valor booleano a `True`, siempre ejecuta `autogen.sh`. Esto es equivalente a pasar la opción `--autogen` a JHBuild. El valor predeterminado es `False`.

`autogenargs`

- Una cadena que contiene los argumentos pasados al script `autogen.sh` de todos los módulos. Se pueden omitir para algunos módulos concretos usando el diccionario `module_autogenargs`.

`branches`

- Un diccionario que especifica qué rama usar para módulos concretos. Esto es útil si hace algunos cambios en la rama de un módulo y quiere que JHBuild construya esa rama en lugar de la listada en el conjunto de módulos.

  La definición de ramas depende del módulo VCS:

  - CV: revisión. Ej. `«RAMA-PROYECTO-0_8»`

  - Bazaar: URI de la rama del módulo. Ej. `'http://bzr.example.net/project/gnome-2-28'`

  - Git: tupla, siendo la primera parte un repositorio opcional (o el valor Ninguno) y la segunda parte el nombre de la rama. Ej. `('git://git.example.net/project', 'gnome-2-28')`

    #### Ejemplo sencillo

        branches['nombremodulo'] = (None, 'nombrerama')

  - Subversion: URI de la rama del módulo. Ej. `'svn://svn.example.net/project/gnome-2-28'`

`builddir_pattern`

- Un patrón de formateo al estilo de `printf` usado para generar nombres de carpetas de construcción. Esto se usa solamente cuando se usan repositorios y árboles de construcción por separado. En la cadena de formato, el `%s` se reemplazará con `checkoutdir`. De manera predeterminada es `«%s»`.

`buildroot`

- Una cadena que especifica la carpeta padre donde colocar los árboles de construcción. El valor predeterminado es `~/.cache/jhbuild/build`. Si se establece a `None` hace que las construcciones se ejecuten dentro de los árboles de fuentes

`buildscript`

- Una cadena que especifica el script de construcción que usar. El valor recomendado es el predeterminado, `terminal`. En particular, no lo configure como `gtk`.

`build_policy`

- Una cadena que especifica los módulos que construir. Las tres opciones son `all`, para construir todos los módulos solicitados, `updated`, para construir solamente los módulos que han cambiado, o `updated-deps` para construir los módulos que han cambiado o que tienen dependencias que han cambiado. El valor predeterminado es `updated-deps`.

`checkoutroot`

- Una cadena que especifica la carpeta donde descomprimir los árboles de fuentes. A menos que `buildroot` esté configurado, las construcciones se harán también en esta carpeta. El valor predeterminado es `~/checkout/gnome`.

`checkout_mode`

- Una cadena que especifica cómo se realiza la descarga de carpetas en el control de versiones. El predeterminado es `update`. Esto se puede configurar para cada módulo usando `module_checkout_mode`. Los valores posibles son `update` (actualizar carpeta de descarga), `clobber` (vaciar la carpeta antes de descargar las fuentes), `export` (vaciar la carpeta y crear una copia no versionada de las fuentes que contenga todos los parches) y `copy` (descargar en una carpeta diferente de en la que se construirá).

`cmakeargs`

- Una cadena que contiene los argumentos pasados a la invocación de `cmake` de todos los módulos. Se pueden omitir para algunos módulos concretos usando el diccionario `module_cmakeargs`. El predeterminado es `''`.

`copy_dir`

- Una cadena que especifica la carpeta que copiar, si el modo de copia `checkout_mode` está en uso. El predeterminado es la carpeta de descarga.

`export_dir`

- Una cadena que especifica la carpeta a la que exportar, si el modo de exportación `checkout_mode` está en uso. El predeterminado es la carpeta de descarga.

`cvs_program`

- Una cadena que especifica qué programa usar para soporte de CVS. Éste puede ser `git-cvsimport` o `cvs`. El predeterminado es `cvs`.

`disable_Werror`

- Un valor booleano (valor predeterminado `True`) que controla si `--disable-Werror` se pasará a las construcciones automáticas. Muchos paquetes usan esta opción como una manera de desactivar advertencias fatales del compilador. El valor `True` se selecciona como un valor predeterminado razonable para aquellos que usan jhbuild como una manera de obtener una versión actualizada de los paquetes de software sin ser rastreado por errores de construcción en módulos de otras personas. Establecer este valor a `False` tiene sentido para aquellos que usan jhbuild como parte de un sistema de integración continua o en sistemas de pruebas.

`dvcs_mirror_dir`

- Una cadena que especifica la carpeta espejo local. JHBuild creará carpetas espejo locales para los repositorios en la carpeta especificada. Los espejos se pueden compartir por varios grupos de repositorios, ahorrando espacio y tiempo ya que los enlaces duros se usarán para clones locales. Los comandos `update` y `updateone` crearán los espejos y recuperarán los nuevos commits de los repositorios en línea. Esta opción sólo está soportada por los repositorios Git y Bazaar.

`exit_on_error`

- Un valor booleano que especifica si se debe salir inmediatamente cuando un módulo falla al construir. Generalmente esto es útil en el modo no intearctivo, para evitar que se construyan módulos adicionales cuando uno falla. Establecerlo a `True` es equivalente a pasar la opción `--exit-on-errr`. El valor predeterminado es `False`.

`extra_prefixes`

- Una lista de cadenas que especifican, en orden, la lista de prefijos adicionales. JHBuild establece varias variables de entorno (como `LD_LIBRARY_PATH`, `PKG_CONFIG_PATH` y `XDG_DATA_DIRS`) basándose en la variable `prefix`. Añadir carpetas a `extra_prefixes` hará que estos prefijos también se incluyan con una prioridad inferior a la variable `prefix` de JHBuild, pero con prioridad superior a las carpetas del sistema. De manera predeterminada, esta variable está vacía, excepto en lo sistemas que instalan software en `/usr/local`, en cuyo caso contiene esta carpeta.

`help_website`

- Una tupla que especifica una página web de ayuda y un URL. La página de ayuda se muestra en HTML tinderbox para los módulos que han fallado. `%(module)s` en el URL se reemplazará con el nombre del módulo. Para desactivarlo, establezca `help_website` a `None`. El valor predeterminado es `('Gnome Live!', 'http://live.gnome.org/JhbuildIssues/%(module)s')`.

`installprog`

- Una cadena que especifica qué programa usar como sustituto de `/usr/bin/install`.

`ignore_suggests`

- Valor booleano que indica si se ignorarán las dependencias suaves cuando se calcule el árbol de dependencias. Su valor predeterminado es `False`.

`interact`

- Un valor booleano que especifica si se interactúa con el usuario. Establecer este valor a `False` es equivalente a pasar la opción `--no-interact`. El valor predeterminado es `True`.

`makeargs`

- Una cadena que lista argumentos adicionales para pasarlos a `make`. JHBuild añadirá automáticamente la opción de ejecución en paralelo (`-j`) basándose en la disponibilidad de los núcleos de la CPU. Lo predeterminado es `''`.

`makecheck`

- Valor booleano que indica si se ejecuta `make check` antes de `make`. De forma predeterminada está a `False`.

`makecheck_advisory`

- Un valor booleano que especifica si los fallos producidos al ejecutar `make check` deben ser sólo informativos y no provocar un fallo de la construcción. El valor predeterminado es `False`.

`makeclean`

- Valor booleano que indica si se ejecuta `make clean` después de `make`. De forma predeterminada está a `False`.

`makedist`

- Un valor booleano que especifica si se ejecutará `make dist` antes de `make`. El valor predeterminado es `False`. Esta configuración es equivalente a pasar la opción `--dist`.

`makedistcheck`

- Un valor booleano que especifica si se ejecutará `make distcheck` antes de `make`. El valor predeterminado es `False`. Esta configuración es equivalente a pasar la opción `--distcheck`.

`mesonargs`

- Una cadena que contiene los argumentos pasados a la invocación de `meson` de todos los módulos. Se pueden omitir para algunos módulos concretos usando el diccionario `module_mesonargs`. EL predeterminado es `''`.

`module_autogenargs`

- Un diccionario que mapea nombres de módulos en cadenas que contienen argumentos para pasárselos a `autogen.sh`. La configuración de `module_autogenargs` se usa en lugar de la configuración global de `autogenargs`. Si un módulo en particular no está listado en el diccionario, se usará la variable global `autogenargs`.

`module_checkout_mode`

- Un diccionario que especifica el modo de descarga a usar para los módulos. Ésto omite la configuración global `checkout_mode`.

`module_cmakeargs`

- Un diccionario que mapea nombres de módulos en cadenas que contienen argumentos para pasárselos a `cmake`. La configuración de `module_cmakeargs` se usa en lugar de la configuración global de `cmakeargs`. Si un módulo en particular no está listado en el diccionario, se usará la variable global `cmakeargs`.

`module_makeargs`

- Un diccionario que mapea nombres de módulos en cadenas que contienen argumentos para pasárselos a `make`. El valor de `module_makeargs` reemplaza el valor de `makeargs`. Si un módulo en particular no está listado en el diccionario, se usará la variable global `makeargs`.

`module_makecheck`

- Un diccionario que mapea nombres de módulos en valores booleanos especificando si se ejecutará `make check` después de `make`. El valor de `module_makecheck` reemplaza el valor de `makecheck`. Si un módulo en particular no está listado en el diccionario, se usará la variable global `makecheck`.

`module_mesonargs`

- Un diccionario que mapea nombres de módulos en cadenas que contienen argumentos para pasárselos a `meson`. La configuración de `module_mesonargs` se usa en lugar de la configuración global de `mesonargs`. Si un módulo en particular no está listado en el diccionario, se usará la variable global `mesonargs`.

`module_ninjaargs`

- Un diccionario que mapea nombres de módulos en cadenas que contienen argumentos para pasárselos a `ninja`. El valor de `module_ninjaargs` reemplaza el valor de `ninjaargs`. Si un módulo en particular no está listado en el diccionario, se usará la variable global `ninjaargs`.

`module_nopoison`

- Un diccionario que mapea nombres de módulos en valores booleanos. Si un módulo está establecido a `True`, JHBuild intentará construir los módulos dependientes aunque falle el módulo especificado. La configuración de `module_nopoison` reemplaza el valor de `nopoison`. Si un módulo en particular no está listado en el diccionario, se usará la variable global `nopoison`.

`module_extra_env`

- Un diccionario que mapea nombres de módulos a diccionarios con variables de entorno adicionales para pasar cuando se ejecutan comandos del módulo.

`module_static_analyzer`

- El modulo de diccionario de mapeado de nombres de módulos a valores booleanos que indica si se debe realizar el análisis estático al construir ese módulo. Esto permite que la opción de configuración global `static_analyzer` se omita.

`modules`

- Una lista de cadenas especificando los módulos que construir. La lista de los módulos actualmente construidos se expandirá recursivamente para incluir todas las dependencias, salvo que se use el comando `buildone`. Su valor predeterminado es `['meta-gnome-desktop']`.

`moduleset`

- Una cadena o una lista de cadenas que contiene los nombres de los conjuntos de módulos que se usarán. También puede ser el nombre de archivo de un conjunto de módulos incluido en JHBuild (excluyendo la ruta y la extensión), o un URL completo a un conjunto de módulos administrado externamente. Los URL se almacenan localmente en la caché. si un módulo con el mismo nombre aparece en más de un conjunto de módulos, tendrá prioridad la última lista configurada. Los conjuntos de módulos proporcionados con JHBuild se actualizan para que coincididan con la versión liberada de desarrollo de GNOME.

`modulesets_dir`

- Una cadena que especifica la carpeta que contiene el conjunto de módulos que usar. La predeterminada es la carpeta `modulesets/` en las fuentes de JHBuild.

`nice_build`

- Ejecutar la construcción bajo la prioridad `SCHED_IDLE` en Linux, o con `nice` en otros Unix. Esto puede mejorar drásticamente la interactividad de escritorio para construcciones en paralelo, mientras que sólo tiene un impacto insignificante en el rendimiento de la construcción.

`ninjaargs`

- Una cadena que lista los argumentos que pasar a `ninja`. El valor predeterminado es `''`.

`nobuild`

- Un valor booleano que, si está establecido a `True`, hace que JHBuild no construya los módulos, sino que sólo descargue y descomprima las fuentes. El valor predeterminado es `False`.

`nonetwork`

- Un valor booleano que especifica si se accede a la red o no. Esto afecta a la descarga o actualización de módulos del CVS, descargando archivos tar y actualizando los conjuntos de módulos. Establecerlo a `True` es equivalente a pasar la opción `--no-network`. El valor predeterminado es `False`.

`nonotify`

- Un valor booleano que especifica si se deben emitir notificaciones usando el demonio de notificaciones. Si está establecido a `False`, las notificaciones se emiten. El valor predeterminado es `True`.

`nopoison`

- Un valor booleano que, si está establecido a `True`, hace que JHBuild intente construir módulos aunque fallen una o más dependencias del módulo. Esta opción es equivalente al argumento `--no-poison`. Su valor predeterminado es `False`.

`notrayicon`

- Un valor booleano que especifica si se debe mostrar un icono en la bandeja del sistema usando Zenity. Si está establecido a `False`, las notificaciones se emiten. El valor predeterminado es `True`.

`noxvfb`

- Un valor booleano que, si está establecido a `True`, hace que JHBuild ejecute comprobaciones gráficas en un servidor X real, en lugar de usar `Xvfb`. Esta opción es equivalente a pasar `--no-xvfb`. El valor predeterminado es `False`.

`partial_build`

- Un valor booleano que, si está establecido a `True`, hace que JHBuild no construya las dependencias de los módulos si los correspondientes paquetes del sistema están instalados y su versión es suficiente. El valor predeterminado es `True`.

`prefix`

- Una cadena que indica el prefijo donde instalar módulos.`prefix` debe ser una ruta absoluta. Esta carpeta debe ser escribible. La carpeta predeterminada es `'~/jhbuild/install/'`.

`pretty_print`

- Un valor booleano que especifica si activar el formateado de la salida de los subprocesos. Sólo hay soporte para la salida de CVS. Desactívelo si el formateado causa problemas. El valor predeterminado es `True`.

`print_command_pattern`

- Se muestra una cadena antes de que JHBuild ejecute un comando. `%(command)s` se reemplazará en la cadena por el comando que ejecutar. `%(cwd)s` se reemplazará en la cadena por la carpeta de trabajo actual. La predeterminada es `«%(command)s»`.

`progress_bar`

- Un valor booleano que especifica dónde mostrar una barra de progreso durante el modo silencioso . El valor predeterminado es `True`.

`quiet_mode`

- Un valor booleano que si vale `True` desactiva la salida de los comandos en ejecución. Su valor predeterminado es `False`.

`repos`

- Un diccionario que especifica la ubicación de un repositorio alternativo para uno en particular. Esta variable de configuración es útil para un desarrollador de módulos. De manera predeterminada, JHBuild descargará código de los repositorios usando una ubicación de repositorio anónima. Las claves del diccionario son nombres cortos de repositorios y los valores son las cadenas de ubicación de los repositorios alternativos. Por ejemplo:

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

`skip`

- Una lista de módulos que omitir. Esta opción `--skip` de la lista de comandos extiende la lista. La lista esta vacía de manera predeterminada. si la lista contiene el valor especial `'*'`, JHBuild omitirá todos los módulos no listados en la variable `modules`. Esto puede se útil si quiere construir módulos sin sus dependencias implícitas.

`static_analyzer`

- Un valor booleano que, si está establecido a `True`, ejecuta una herramienta de análisis estático en cada módulo que se empieza a construir. El valor predeterminado es `False`.

`static_analyzer_outputdir`

- Carpeta raíz en la que se guardarán los informes del análisis estático (si `static_analyzer` es `True`). El valor predeterminado es `/tmp/jhbuild_static_analyzer`.

`static_analyzer_template`

- Plantilla de comandos para el analizador estático. Esto tiene un parámetro `outputdir` (el valor de la variable de configuración `static_analyzer_outputdir`) y `module` () el nombre del módulo que se está construyendo actualmente) sustituido en `printf`-style. El comando resultante se usa como prefijo de `make` al construir el módulo. El valor predeterminado es `scan-build`.

`sticky_date`

- Una cadena que si está establecida y está soportado por el sistema de control de versiones subyaciente, JHBuild actualizará el árbol de fuentes a la fecha indicada antes de la construcción. La fecha debe darse en formato ISO, ej `«`yyyy`-`mm`-`dd`»`. El valor predeterminado es `None`.

`svn_program`

- Una cadena que especifica qué programa usar para soporte de subversion. Éste puede ser `svn` o `git-svn`. El predeterminado es `svn`.

`system_libdirs`

- Una lista de cadenas que especifican las rutas a las bibliotecas del sistema. Esto se usa al configurar los valores predeterminados de algunas variables del entorno, como `PKG_CONFIG_PATH`.

`tarballdir`

- Una cadena que, si está establecida, indica que los archivos tar se descargarán en la carpeta especificada en lugar de en `checkoutroot`. Esto es útil si tiene múltiples entornos JHBuild o si vacía habitualmente su `checkoutroot` y quiere reducir el uso del ancho de banda. El valor predeterminado es `'~/.cache/jhbuild/downloads'`.

`tinderbox_outputdir`

- Una cadena que contiene la carpeta para guardar la salida de `jhbuild tinderbox`. Esta cadena se puede omitir con la opción `--output`. Su valor predeterminado es `None`, por lo que se debe usar la opción de la línea de comandos o se debe configurar esta variable en el archivo de configuración.

`trycheckout`

- Un valor booleano que si está establecido a `True` hace que JHBuild intente automáticamente resolver problemas 1) ejecutando `autogen.sh` de nuevo, y 2) comprobando en el control de versiones si hay una nueva versión del módulo. Esta opción es equivalente a pasarle `--try-checkout`.

`use_local_modulesets`

- Un valor booleano que especifica que se usen los conjuntos de módulos que se descargaron junto al código fuente de JHBuild, en lugar de descargarlos manualmente del sistema de control de versiones de GNOME. Su valor predeterminado es `False`.

`xvfbargs`

- Una cadena que lista los argumentos que pasar a `Xvfb` si se ejecutan comprobaciones gráficas.

`conditions`

- Un conjunto de condiciones (cadenas) que pueden influir en los módulos que se construyen y en las opciones que se usan para construirlos. Debe usar `conditions.add()` y `conditions.discard()` para modificar la lista si quiere hacer cambios.

  El conjunto original de condiciones se determina basándose en el sistema operativo y se puede modificar usando el argumento de línea de comandos `--conditions=`. Los cambios hechos por `--conditions=` serán visibles al usar el archivo jhbuildrc, por lo que puede establecer otras variables basadas en el valor actual del conjunto, pero `--conditions=` se aplicará de nuevo después de cualquier cambio hecho por el jhbuildrc.

### Otras estructuras de los archivos de configuración

Aparte de las variables anteriores, hay algunas otras cosas que se pueden configurar en el archivo de configuración.

`os.environ`

- Un diccionario que representa el entorno. Este entorno se le pasa a los procesos que JHBuild crea.

  Algunas variables de entorno influyentes incluyen `CPPFLAGS`, `CFLAGS`, `INSTALL` y `LDFLAGS`. Por ejemplo:

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

`addpath`(`envvar`, `pathname`)

- Esto añadirá una carpeta a la variable de entorno `PATH`. `addpath` manejará correctamente el caso en que la variable de entorno está vacía inicialmente (tener una comilla al principio o al final de una variable de entorno puede tener consecuencias inesperadas).

`prependpath`(`envvar`, `pathname`)

- Después de procesar el archivo de configuración, JHBuild alterará algunas rutas basadas en variables, tales como `prefix` (ej. añadiendo `$prefix/bin` al principio de `PATH`).

  La función `prependpath` trabaja igual que `addpath`, excepto que la variable de entorno se modifica después de que JHBuild haya hecho sus cambios al entorno.

## 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=`.

### 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

#### 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"/>

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

#### 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/"/>

#### 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"/>

#### 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"/>

#### 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"/>

#### 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»)

#### 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"/>

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

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

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

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

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

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

#### 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>

#### 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>

#### 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>

#### 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>

#### 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>

#### 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>

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

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

### Elementos obsotelos

#### Repositorios de módulos

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

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

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

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