<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!--*- mode: nxml -*-->
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- process to HTML with: xmlto xhtml-nochunks -m ../custom.xsl index.docbook -->
<article id="index" lang="es">
  <articleinfo>
    <title>Manual de JHBuild</title>
    <authorgroup>
      <author role="maintainer"><firstname>James</firstname> <surname>Henstridge</surname></author>
      <author><firstname>C.J.</firstname> <surname>Adams-Collier</surname></author>
      <author><firstname>Frederic</firstname> <surname>Peters</surname></author>
      <author><firstname>David</firstname> <surname>Turner</surname></author>
    </authorgroup>
    <copyright><year>2004, 2008</year> <holder>James Henstridge</holder></copyright>
    <revhistory>
      <revision><revnumber>Manual de JHBuild v0.5</revnumber> <date>Enero 2008</date></revision>
      <revision><revnumber>Manual de JHBuild v0.1</revnumber> <date>Agosto 2007</date></revision>
    </revhistory>
    <abstract role="description">
      <para>JHBuild es una herramienta que se usa para construir completamente el escritorio GNOME desde el sistema de control de veriones. Sin embargo, se puede usar para construir otros proyectos creando para ello un conjunto de módulos.</para>
    </abstract>
  
    <othercredit class="translator">
      <personname>
        <firstname>Daniel Mustieles</firstname>
      </personname>
      <email>daniel.mustieles@gmail.com</email>
    </othercredit>
    <copyright>
      
        <year>2008-2017</year>
      
      <holder>Daniel Mustieles</holder>
    </copyright>
  </articleinfo>

  <section id="introduction">
    <title>Introducción</title>

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

    <para>Originalmente JHBuild se escribió para construir <ulink url="http://www.gnome.org">GNOME</ulink>, pero se ha extendido para hacerlo usable con otros proyectos. Se puede almacenar un <quote>conjunto de módulos</quote> en un servidor web, para permitir reglas de construcción independientes de JHBuild.</para>

    <para>JHBuild puede construir módulos desde varias fuentes, incluyendo los repositorios de <ulink url="http://www.cvshome.org/">CVS</ulink>, <ulink url="http://subversion.tigris.org/">Subversion</ulink>, <ulink url="http://www.bazaar-vcs.org/">Bazaar</ulink>, <ulink url="http://darcs.net/">Darcs</ulink>, <ulink url="http://git.or.cz/">Git</ulink> y <ulink url="http://www.selenic.com/mercurial/">Mercurial</ulink>, 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.</para>

    <para>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.</para>
  </section>

  <section id="getting-started">
    <title>Inicio</title>

    <para>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.</para>

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

      <para>JHBuild requiere una rutina de Python. Verifique que Python &gt;= 2.3 está instalado.</para>

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

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

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

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

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

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

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

      <para>Para añadir permanentemente <filename>~/.local/bin</filename> a la variable <envar>PATH</envar>, ejecute el siguiente comando:</para>

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

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

      <para>Se puede configurar JHBuild mediante el archivo de configuración. su ubicación predeterminada es <filename>~/.config/jhbuildrc</filename>. 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 <filename>examples/sample.jhbuildrc</filename>. Copie <filename>examples/sample.jhbuildrc</filename> a <filename>~/.config/jhbuildrc</filename> y personalícelo como necesite.</para>

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

      <para>Las variables de configuración están documentadas en <xref linkend="config-reference"/>. Las variables más comúnmente usadas son:</para>

      <variablelist>
<?dbhtml list-presentation="table"?>
        <varlistentry>
          <term><link linkend="cfg-repos"><varname>repos</varname></link></term>
          <listitem>
            <simpara>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:</simpara>

<programlisting>repos['git.gnome.org'] = 'ssh://<replaceable>nombre_de_usuario</replaceable>@git.gnome.org/git/'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-moduleset"><varname>moduleset</varname></link></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-modules"><varname>modules</varname></link></term>
          <listitem>
            <simpara>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 <link linkend="command-reference-buildone"><command>buildone</command></link>. Su valor predeterminado es <literal>['meta-gnome-desktop']</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-checkoutroot"><varname>checkoutroot</varname></link></term>
          <listitem>
            <simpara>Una cadena que especifica la carpeta donde descomprimir los árboles de fuentes. Si <link linkend="cfg-buildroot"><varname>buildroot</varname></link> se establece a <constant>None</constant>, las construcciones se harán también en esta carpeta. El valor predeterminado es <filename>~/jhbuild/checkout</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-prefix"><varname>prefix</varname></link></term>
          <listitem>
            <simpara>Una cadena que indica el prefijo donde instalar módulos.<varname>prefix</varname> debe ser una ruta absoluta. Esta carpeta debe ser escribible. La carpeta predeterminada es <literal>'~/jhbuild/install/'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-autogenargs"><varname>autogenargs</varname></link></term>
          <listitem>
            <simpara>Una cadena que contiene los argumentos pasados al script <command>autogen.sh</command> de todos los módulos. Se pueden omitir para algunos módulos concretos usando el diccionario <link linkend="cfg-module-autogenargs"><varname>module_autogenargs</varname></link>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-makeargs"><varname>makeargs</varname></link></term>
          <listitem>
            <simpara>Una cadena que lista argumentos adicionales para pasarlos a <command>make</command>. JHBuild añadirá automáticamente la opción de ejecución en paralelo (<option>-j</option>) basándose en la disponibilidad de los núcleos de la CPU. Lo predeterminado es <literal>''</literal>.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="getting-started-bootstrap">
      <title>Prerrequisitos para la construcción</title>

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

      <para>JHBuild puede comprobarlas herramientas están instaladas usando el comando <command>sanitycheck</command>:</para>

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

      <para>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 <ulink url="http://live.gnome.org/JhbuildDependencies">nombres de paquetes</ulink> para diferentes distribuciones. Ejecute otra vez el comando <command>sanitycheck</command> depsués de instalar los paquetes para asegurarse de que las herramientas necesarias están instaladas.</para>
    </section>

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

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

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

      <para>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.</para>

      <note>
        <simpara>Desistir de cargar un módulo causará que todos los módulos que dependan de él fallen.</simpara>
      </note>

      <para>Debajo hay un ejemplo con el menú mostrado:</para>

<screen>  [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»
<prompt>choice:</prompt> </screen>

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

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

      <para>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 <option>--start-at</option>:</para>

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

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

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

      <para>Cuando desarrolla activamente un módulo, generalmente está en una carpeta de trabajo. El comando <command>make</command> 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.</para>

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

      <para>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 <command>list</command>:</para>

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

      <para>Para obtener información acerca de un módulo en particular, use el comando <command>info</command>:</para>

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

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

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

      <para>Posteriormente JHBuild puede construir todo sin descargar ni actualizar los fuentes:</para>

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

      <para>Para ejecutar un comando concreto con el mismo entorno que usa JHBuild, use el comando <command>run</command>:</para>

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

      <para>Para iniciar una consola con el mismo entorno usado por JHBuild use el comando <command>shell</command>:</para>

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

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

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

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

      <para>Para construir GNOME se requieren algunos paquetes de desarrollo. Esto incluye:</para>

      <itemizedlist>
        <listitem>
          <simpara>DocBook XML DTD y hojas de estilo XSLT. Deben registrarse en el catálogo XML (<filename>/etc/xml/catalog</filename>).</simpara>
        </listitem>
        <listitem>
          <simpara>Bibliotecas de las X.</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libsmbclient</filename> de Samba (usado para examinar redes Windows).</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libbz2</filename> de bzip2.</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libpng</filename>, <filename>libjpeg</filename> y <filename>libtiff</filename> (usada para cargar imágenes).</simpara>
        </listitem>
      </itemizedlist>

      <para>Si está instalando paquetes de su distribución, y si es aplicable a ésta, instale los paquetes <quote>dev</quote> o <quote>devel</quote> correspondientes. En el wiki de GNOME se mantiene una lista de <ulink url="http://live.gnome.org/JhbuildDependencies">nombres de paquetes</ulink> para las distintas distribuciones.</para>
    </section>

    <section id="running-single-application">
      <title>Ejecutar una única aplicación de GNOME</title>

      <para>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 <xref linkend="running-gnome"/>.</para>

      <para>Lanzar una consola de JHBuild. La consola de JHBuild tiene configuradas todas las variables de entorno necesarias.</para>

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

      <para>Verificar que se ejecutará la aplicación correcta. Por ejemplo:</para>

<screen><prompt>$ </prompt><userinput>which gedit</userinput>
/home/wanda/jhbuild/install/bin/gedit</screen>

      <para>Ejecutar la aplicación:</para>

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

      <para>Alternativamente, ejecute la aplicación usando el comando <command>run</command>:</para>

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

    <section id="running-gnome">
      <title>Ejecutar el entorno de escritorio GNOME</title>

      <para>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 <systemitem class="username">gnomedev</systemitem>.</para>

      <para>Configure JHBuild en la cuenta <systemitem class="username">gnomedev</systemitem> nueva. Copie o cree un enlace simbólico de <filename>~/.config/jhbuildrc</filename> y <filename>~/.local/bin/jhbuild</filename> a la carpeta del usuario <systemitem class="username">gnomedev</systemitem>.</para>

      <para>Abrir una terminal como usuario <systemitem class="username">gnomedev</systemitem>. Para añadir permanentemente <filename>~/.local/bin</filename> a la variable <envar>PATH</envar>, ejecute el siguiente comando:</para>

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

      <para>Probar si JHBuild funciona:</para>

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

      <section>
        <title>Configurar GNOME para ejecutarse desde el gestor de ventanas</title>

        <para>Construir e instalar JHBuild GNOME</para>

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

<screen><prompt>$ </prompt><userinput>rm -rf <replaceable>~/jhbuild/install</replaceable>/var/run/dbus</userinput>
<prompt>$ </prompt><userinput>ln -s /var/run/dbus <replaceable>~/jhbuild/install</replaceable>/var/run/dbus</userinput>
<prompt>$ </prompt><userinput>rm -rf <replaceable>~/jhbuild/install</replaceable>/var/lib/dbus/machine-id</userinput>
<prompt>$ </prompt><userinput>ln -s /var/lib/dbus/machine-id <replaceable>~/jhbuild/install</replaceable>/var/lib/dbus/machine-id</userinput></screen>

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

<programlisting>#!/bin/sh

GNOME=<replaceable>~/jhbuild/install</replaceable>

GDK_USE_XFT=1
XDG_DATA_DIRS=$XDG_DATA_DIRS:$GNOME/share
XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:$GNOME/etc/xdg

jhbuild run gnome-session
</programlisting>

        <para>Haga ejecutable el archivo <filename>/usr/bin/gnome-jhbuild-session</filename>:</para>

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

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

<programlisting>[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</programlisting>

        <para>Reiniciar <command>gdm</command>.</para>

        <para/>
      </section>

      <section>
        <title>Ejecutar GNOME desde el gestor de ventanas</title>

        <para>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 <systemitem class="username">gnomedev</systemitem>. Si es correcto, se mostrará JHBuild GNOME. Si es incorrecto, compruebe el archivo de registro que se encuentra en <filename>~gnomedev/.cache/gdm/session.log</filename> o en <filename>~gnomedev/.xsession-errors</filename>.</para>
      </section>
    </section>

    <section id="static-analysis">
      <title>Análisis de estadísticas</title>

      <para>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 <varname>static_analyzer</varname> a <constant>True</constant> en el archivo de configuración <filename>.jhbuildrc</filename>.</para>

      <para>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 <filename>/tmp/jhbuild_static_analyzer</filename> (de manera predeterminada; la ruta se puede cambiar en la variable de configuración <varname>static_analyzer_outputdir</varname>).</para>

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

  <section id="buildbot-integration">
    <title>Integración con buildbot</title>

    <para>Junto al proyecto <ulink url="http://buildbot.net">Buildbot</ulink>, JHBuild puede funcionar también como una herramienta de integración. El proyecto GNOME usa la configuración de Buildbot en <ulink url="http://build.gnome.org">build.gnome.org</ulink>.</para>

    <section id="buildbot-slave">
      <title>Configurar un Buildbot esclavo</title>

      <para>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.</para>

      <para>Los comandos de Buildbot son opciones del comando <command>bot</command>. Para descargar e instalar el software adicional requerido ejecute el siguiente comando:</para>

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

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

      <note>
        <para>No se puede usar un archivo alternativo de configuración. La opción <link linkend="option-file"><option>--file</option></link> no tendrá los efectos deseados.</para>
      </note>

<programlisting>
jhbuildbot_master = 'build.gnome.org:9070'
jhbuildbot_slavename = 'nombredelesclavo'
jhbuildbot_password = 'contraseña'
</programlisting>

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

      <note>
        <para>Se puede contactar con los administradores de <ulink url="http://build.gnome.org">build.gnome.org</ulink> en la <ulink url="mailto:build-brigade-list@gnome.org">lista de correo de Build Brigade</ulink>.</para>
      </note>
    </section>

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

  <section id="command-reference">
    <title>Referencia de comandos</title>

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

    <cmdsynopsis><command>jhbuild</command> <arg><replaceable>opciones globales</replaceable></arg> <arg choice="plain"><replaceable>comando</replaceable></arg> <arg><replaceable>argumentos del comando</replaceable></arg></cmdsynopsis>

    <para>Las opciones globales de JHBuild son:</para>

    <variablelist>
      <varlistentry id="option-file">
        <term><option>-f</option>, <option>--file</option> <replaceable>configuración</replaceable></term>
        <listitem>
          <simpara>Use un archivo de configuración alternativo, en lugar del predeterminado, <filename>~/.config/jhbuildrc</filename>.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-m</option>, <option>--moduleset</option> <replaceable>conjunto de módulos</replaceable></term>
        <listitem>
          <simpara>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.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--no-interact</option></term>
        <listitem>
          <simpara>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.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--exit-on-error</option></term>
        <listitem>
          <simpara>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.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--conditions</option></term>
        <listitem>
          <simpara>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 <literal>-wayland</literal> o <literal>+docs</literal> para quitar o añadir condiciones. Si hay varias modificaciones se pueden separar por comas, como <command>--conditions=+docs,-wayland</command> o puede dividirlas en varios argumentos <command>--conditions</command>.</simpara>
        </listitem>
      </varlistentry>
    </variablelist>

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

    <variablelist>
      <varlistentry>
        <term><envar>JHBUILD_RUN_AS_ROOT</envar></term>
        <listitem>
          <simpara>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 <envar>JHBUILD_RUN_AS_ROOT</envar> se desactivará la comprobación del ID del usuario al inicio.</simpara>
        </listitem>
      </varlistentry>
    </variablelist>

    <para>A continuación se listan las opciones específicas de los comandos.</para>

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

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

      <cmdsynopsis><command>jhbuild autobuild</command> <arg>--autogen</arg> <arg>--clean</arg> <arg>--distcheck</arg> <arg rep="repeat">--skip=<replaceable>módulo</replaceable></arg> <arg>--start-at=<replaceable>módulo</replaceable></arg> <arg>--report-url=<replaceable>URL</replaceable></arg> <arg>--verbose</arg></cmdsynopsis>

      <para>Las opciones <option>--autogen</option>, <option>--clean</option>, <option>--distcheck</option>, <option>--skip</option> y <option>--start-at</option> se procesan de la misma manera que para el comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>--report-url=<replaceable>reporturl</replaceable></option>, <option>-r <replaceable>reporturl</replaceable></option></term>
          <listitem>
            <simpara>Esta opción especifica el URL de JhAutobuild a la que se  debe informar</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--verbose</option>, <option>-v</option></term>
          <listitem>
            <simpara>Si está especificado, la salida de JHBuild será más detallada.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>El comando <command>bootstrap</command> instala un conjunto de herramientas de construcción. Estas herramientas incluyen <application>autoconf</application>, <application>automake</application> 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. <command>bootstrap</command> 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 <systemitem class="osname">Mac OS</systemitem>.</para>

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

      <para>El comando, <command>bootstrap</command> construye módulos usando el mismo método que el comando <command>build</command>, pero usa el conjunto de módulos <filename>bootstrap.modules</filename>.</para>

      <para>Consulte la documentación del comando <link linkend="command-reference-build"><command>build</command></link> para ver las opciones disponibles.</para>
    </section>

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

      <para>El comando <command>build</command> construye uno o más paquetes, incluyendo sus dependencias.</para>

      <cmdsynopsis><command>jhbuild build</command> <arg>--autogen</arg> <arg>--clean</arg> <arg>--check</arg> <arg>--dist</arg> <arg>--distcheck</arg> <arg>--distclean</arg> <arg>--ignore-suggests</arg> <arg>--no-network</arg> <arg rep="repeat">--skip=<replaceable>módulo</replaceable></arg> <arg>--start-at=<replaceable>módulo</replaceable></arg> <arg>--tags=<replaceable>etiquetas</replaceable></arg> <arg>-D <replaceable>fecha</replaceable></arg> <arg>--no-xvfb</arg> <arg>--try-checkout</arg> <arg>--no-poison</arg> <arg>--force</arg> <arg>--build-optional-modules</arg> <arg>--min-age=<replaceable>hora</replaceable></arg> <arg>--nodeps</arg> <arg rep="repeat">módulo</arg></cmdsynopsis>

      <para>Si no se indican nombres de módulos en la línea de comandos, se usará la lista de <link linkend="cfg-modules">módulos</link> del archivo de configuración.</para>

      <variablelist>
        <varlistentry>
          <term><option>-a</option>, <option>--autogen</option></term>
          <listitem>
            <simpara>Ejecute <command>autogen.sh</command> antes de construir los módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-c</option>, <option>--clean</option></term>
          <listitem>
            <simpara>Ejecute <command>make clean</command> antes de construir los módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--check</option></term>
          <listitem>
            <simpara>Ejecute <command>make check</command> después de construir los módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-d</option>, <option>--dist</option></term>
          <listitem>
            <simpara>Ejecute <command>make dist</command> después de construir los módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--distcheck</option></term>
          <listitem>
            <simpara>Ejecute <command>make distcheck</command> después de construir los módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--distclean</option></term>
          <listitem>
            <simpara>Para módulos de git, ejecute <command>git clean -dfx</command> antes de construir los módulos. para otros módulos, ejecute <command>make distclean</command> antes de construir los módulos.</simpara>

            <note>
              <simpara>Esta opción eliminará todos los cambios no efectuados.</simpara>
            </note>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--ignore-suggests</option></term>
          <listitem>
            <simpara>No construir las dependencias suaves</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-n</option>, <option>--no-network</option></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-s</option>, <option>--skip</option>=<replaceable>módulo,...</replaceable></term>
          <listitem>
            <simpara>No construir los módulos listados. Usado para omitir la construcción de determinadas dependencias.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--tags</option>=<replaceable>etiqueta,...</replaceable></term>
          <listitem>
            <simpara>Ignorar los módulos que no coinciden con <replaceable>etiqueta</replaceable>. Los módulos se asignan automáticamente a una etiqueta que coincide con el nombre del conjunto de módulos del módulo.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-t</option>, <option>--start-at</option>=<replaceable>módulo</replaceable></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-D</option> <replaceable>fecha</replaceable></term>
          <listitem>
            <simpara>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 <literal>«2009-09-18 02:32Z»</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-x</option>, <option>--no-xvfb</option></term>
          <listitem>
            <simpara>Ejecutar comprobaciones gráficas en el servidor X actual en lugar de en un Xvfb simulado.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-C</option>, <option>--try-checkout</option></term>
          <listitem>
            <simpara>Si falla la construcción, y el sistema de control de versiones lo soporta, fuerce una descarga y ejecute <command>autogen.sh</command> antes de reintentar la construcción.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-N</option>, <option>--no-poison</option></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-f</option>, <option>--force</option></term>
          <listitem>
            <simpara>Construir los módulos aunque la política diga que no es necesario.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--build-optional-modules</option></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--min-age</option>=<replaceable>tiempo</replaceable></term>
          <listitem>
            <simpara>Omitir módulos instalados más recientemente que la fecha relativa dada; el formato de la cadena <replaceable>time</replaceable> 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, <option>--min-time=2h</option> omitirá los módulos construidos hace menos de dos horas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--nodeps</option></term>
          <listitem>
            <simpara>Ignorar las dependencias que falten. para ignorar una única dependencia del sistema, añada el módulo a <link linkend="cfg-skip"><varname>skip</varname></link>.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

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

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

      <para>Las opciones son las mismas que las disponibles para el comando <link linkend="command-reference-build"><command>buildone</command></link>.</para>
    </section>

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

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

      <cmdsynopsis><command>jhbuild buildone</command> <arg>--autogen</arg> <arg>--clean</arg> <arg>--check</arg> <arg>--distcheck</arg> <arg>--distclean</arg> <arg>--no-network</arg> <arg>-D <replaceable>date</replaceable></arg> <arg>--no-xvfb</arg> <arg>--force</arg> <arg>--min-age=<replaceable>hora</replaceable></arg> <arg>--nodeps</arg> <arg choice="plain" rep="repeat">módulo</arg></cmdsynopsis>

      <para>Las opciones <option>--autogen</option>, <option>--check</option>, <option>--clean</option>, <option>-d</option>, <option>--distcheck</option>, <option>--distclean</option>, <option>--no-network</option>, <option>-D</option>, <option>-x</option> y <option>--nodeps</option> se procesan de la misma manera que para el comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <para>Se debe listar al menos un módulo en la línea de comandos.</para>
    </section>

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

      <para>El comando <command>checkbranches</command> 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.</para>

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

      <variablelist>
        <varlistentry>
          <term><option>--branch</option>=<replaceable>rama</replaceable>, <option>-b</option> <replaceable>rama</replaceable></term>
          <listitem>
            <simpara>La rama para comprobar.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

<screen><prompt>$</prompt> <userinput>jhbuild -m gnome-2.20 checkbranches</userinput>
libgnomecanvas es una definición de rama desconocida para gnome-2-20
<prompt>$</prompt></screen>
    </section>

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

      <para>El comando <command>clean</command> limpia las carpetas de construcción de uno o más módulos.</para>

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

      <para>Si no se indican nombres de módulos en la línea de comandos, se usará la lista de <link linkend="cfg-modules">módulos</link> del archivo de configuración.</para>

      <para>Consulte la documentación del comando <link linkend="command-reference-build"><command>build</command></link> para obtener una descripción de las opciones disponibles.</para>
    </section>

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

      <para>El comando <command>dot</command> 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 <ulink url="http://www.graphviz.org/">GraphViz</ulink> para generar un diagrama.</para>

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

      <para>Si no se indican nombres de módulos en la línea de comandos, se usará la lista de <link linkend="cfg-modules">módulos</link> del archivo de configuración.</para>

      <para>La opción <option>--soft-deps</option> añadirá líneas de puntos desde los módulos hasta sus dependencias débiles. La opción <option>--clusters</option> agrupará los módulos de los <link linkend="moduleset-syntax-defs-metamodule">metamódulos</link> juntos.</para>

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

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

      <para>O una imagen PNG:</para>

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

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

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

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

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

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

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

      <para>El comando <command>info</command> muestra información de uno o más módulos.</para>

      <cmdsynopsis><command>jhbuild info</command> <arg choice="opt">--installed</arg> <arg choice="opt" rep="repeat">módulo</arg></cmdsynopsis>

      <para>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.</para>

      <para>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.</para>

      <para>Si es especifica la opción <option>--installed</option>, 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.</para>

      <note>
        <simpara>Si es especifica la opción <option>--installed</option>, 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.</simpara>
      </note>
    </section>

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

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

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

      <para>Si no se indican nombres de módulos en la línea de comandos, se usará la lista de <link linkend="cfg-modules">módulos</link> del archivo de configuración.</para>

      <para>Las opciones <option>--skip</option>, <option>--start-at</option>, <option>--tags</option>, <option>--ignore-suggests</option> y <option>-D</option> se procesan de la misma manera que para el comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>-a</option>, <option>--all-modules</option></term>
          <listitem>
            <simpara>Listar todos los módulos del conjunto de módulos sin importar sus dependencias de construcción.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-r</option>, <option>--show-revision</option></term>
          <listitem>
            <simpara>Si se asigna un módulo a una rama, mostrar el nombre de la rama con el nombre del módulo.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--list-optional-modules</option></term>
          <listitem>
            <simpara>Esta opción fuerza a JHBuild a listar dependencias opcionales</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>El comando <command>rdepends</command> muestra las dependencias inversas de un módulo.</para>

      <cmdsynopsis><command>jhbuild rdepends</command> <arg>módulo</arg></cmdsynopsis>

      <variablelist>
        <varlistentry>
          <term><option>--dependencies</option></term>
          <listitem>
            <simpara>Mostrar las dependencias junto a los módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--direct</option></term>
          <listitem>
            <simpara>Limitar la muestra a los módulos directamente dependientes del módulo dado.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>El comando <command>run</command> ejecuta un comando especificado usando el mismo entorno que usa JHBuild cuando construye los módulos.</para>

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

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

      <variablelist>
        <varlistentry>
          <term><option>--in-builddir</option>=<replaceable>módulo</replaceable></term>
          <listitem>
            <simpara>Ejecute el comando en la carpeta de construcción del módulo especificado.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

      <variablelist>
        <varlistentry>
          <term><option>--in-checkoutdir</option>=<replaceable>módulo</replaceable></term>
          <listitem>
            <simpara>Ejecute el comando en la carpeta de fuentes del módulo especificado.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

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

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

      <para>Algunas de las comprobaciones incluyen:</para>

      <itemizedlist>
        <listitem>
          <simpara>Los prefijos de descarga e instalación son escribibles.</simpara>
        </listitem>
        <listitem>
          <simpara>Las herramientas de construcción requeridas están instaladas.</simpara>
        </listitem>
        <listitem>
          <simpara>Algunas macros usadas habitualmente están disponibles en la rutas de búsqueda de los comandos de <command>aclocal</command>, asociados con varias versiones de <command>automake</command>.</simpara>
        </listitem>
        <listitem>
          <simpara>El catálogo XML contiene la DTD de DocBook y hojas de estilos.</simpara>
        </listitem>
      </itemizedlist>
    </section>

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

      <para>El comando <command>shell</command> inicia una consola de usuario con el mismo entorno que usa JHBuild cuando construye los módulos.</para>

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

      <para>Este comando es equivalente al siguiente:</para>

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

      <para>La variable de entorno <envar>UNDER_JHBUILD</envar> 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 <filename>.bashrc</filename>:</para>

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

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

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

      <para>El comando <command>sysdeps</command> muestra:</para>

      <orderedlist>
        <listitem>
          <simpara>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.</simpara>
        </listitem>
        <listitem>
          <simpara>una lista de paquetes requeridos. Su sistema debe proporcionarla para empezar a construir los paquetes.</simpara>
        </listitem>
        <listitem>
          <simpara>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 <link linkend="cfg-partial-build"><varname>partial_build</varname></link> es <constant>False</constant>.</simpara>
        </listitem>
      </orderedlist>

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

      <variablelist>
        <varlistentry>
          <term><option>--install</option></term>
          <listitem>
            <simpara>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 <application>PackageKit</application>, si está disponible. Para distribuciones que usan <application>APT</application> como <systemitem class="osname">Debian</systemitem> y <systemitem class="osname">Ubuntu</systemitem>, esta opción requiere que <application>apt-file</application> esté instalado.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

      <example>
        <title>ejemplo de <command>sysdeps</command></title>
<screen><prompt>$</prompt> <userinput>jhbuild sysdeps</userinput>
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)
    ...</screen>
      </example>
    </section>

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

      <para>El comando <command>tinderbox</command> es parecido a <command>build</command>, 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.</para>

      <cmdsynopsis><command>jhbuild tinderbox</command> <arg>--autogen</arg> <arg>--clean</arg> <arg>--distclean</arg> <arg>--no-network</arg> <arg>--output=<replaceable>carpeta</replaceable></arg> <arg rep="repeat">--skip=<replaceable>módulo</replaceable></arg> <arg>--start-at=<replaceable>módulo</replaceable></arg> <arg>-D <replaceable>fecha</replaceable></arg> <arg>-C</arg> <arg>-N</arg> <arg>-f</arg> <arg>--nodeps</arg> <arg rep="repeat">módulo</arg></cmdsynopsis>

      <para>Las opciones <option>--autogen</option>, <option>--clean</option>, <option>--distclean</option>, <option>--no-network</option>, <option>--skip</option>, <option>--start-at</option>, <option>-D</option>, <option>-C</option>, <option>-N</option>, <option>-f</option> y <option>--nodeps</option> ose procesan de la misma manera que para el comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>-o</option>, <option>--output</option>=<replaceable>carpeta</replaceable></term>
          <listitem>
            <simpara>La carpeta en la que escribir los archivos HTML. JHBuild creará un índice (<filename>index.html</filename>) y un archivo HTML para cada módulo</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>El comando <command>uninstall</command> desinstala uno o más módulos.</para>

      <cmdsynopsis><command>jhbuild uninstall</command> <arg choice="plain" rep="repeat">módulo</arg></cmdsynopsis>
    </section>

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

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

      <cmdsynopsis><command>jhbuild update</command> <arg rep="repeat">--skip=<replaceable>módulo</replaceable></arg> <arg>--start-at=<replaceable>módulo</replaceable></arg> <arg>--tags=<replaceable>etiquetas</replaceable></arg> <arg>--ignore-suggests</arg> <arg>-D <replaceable>fecha</replaceable></arg> <arg rep="repeat">módulo</arg></cmdsynopsis>

      <para>Las opciones <option>--skip</option>, <option>--start-at</option>, <option>--tags</option>, <option>--ignore-suggests</option> y <option>-D</option> se procesan de la misma manera que para el comando <link linkend="command-reference-build"><command>build</command></link>.</para>
    </section>

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

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

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

      <para>La opción <option>-D</option> se procesa de la misma manera que para el comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <para>Se debe listar al menos un módulo en la línea de comandos.</para>
    </section>
  </section>

  <section id="config-reference">
    <title>Referencia del archivo de configuración</title>

    <para>El archivo <filename>~/.config/jhbuildrc</filename> 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.</para>

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

<programlisting>use_local_modulesets = True</programlisting>

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

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

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

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

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

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

    <section id="config-reference-variables">
      <title>Variables de configuración</title>

      <variablelist>
<?dbhtml list-presentation="table"?>
        <varlistentry id="cfg-alwaysautogen">
          <term><varname>alwaysautogen</varname></term>
          <listitem>
            <simpara>Si se establece un valor booleano a <constant>True</constant>, siempre ejecuta <command>autogen.sh</command>. Esto es equivalente a pasar la opción <option>--autogen</option> a JHBuild. El valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-autogenargs">
          <term><varname>autogenargs</varname></term>
          <listitem>
            <simpara>Una cadena que contiene los argumentos pasados al script <command>autogen.sh</command> de todos los módulos. Se pueden omitir para algunos módulos concretos usando el diccionario <varname>module_autogenargs</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-branches">
          <term><varname>branches</varname></term>
          <listitem>
            <simpara>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.</simpara>

            <simpara>La definición de ramas depende del módulo VCS:</simpara>

            <itemizedlist>
              <listitem>
                <simpara>CV: revisión. Ej. <literal>«RAMA-PROYECTO-0_8»</literal></simpara>
              </listitem>
              <listitem>
                <simpara>Bazaar: URI de la rama del módulo. Ej. <literal>'http://bzr.example.net/project/gnome-2-28'</literal></simpara>
              </listitem>
              <listitem>
                <simpara>Git: tupla, siendo la primera parte un repositorio opcional (o el valor Ninguno) y la segunda parte el nombre de la rama. Ej. <literal>('git://git.example.net/project', 'gnome-2-28')</literal></simpara>

                <example>
                  <title>Ejemplo sencillo</title>
<programlisting>branches['nombremodulo'] = (None, 'nombrerama')</programlisting>
                </example>
              </listitem>
              <listitem>
                <simpara>Subversion: URI de la rama del módulo. Ej. <literal>'svn://svn.example.net/project/gnome-2-28'</literal></simpara>
              </listitem>
            </itemizedlist>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-builddir-pattern">
          <term><varname>builddir_pattern</varname></term>
          <listitem>
            <simpara>Un patrón de formateo al estilo de <function>printf</function> 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 <literal>%s</literal> se reemplazará con <varname>checkoutdir</varname>. De manera predeterminada es <literal>«%s»</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-buildroot">
          <term><varname>buildroot</varname></term>
          <listitem>
            <simpara>Una cadena que especifica la carpeta padre donde colocar los árboles de construcción. El valor predeterminado es <filename>~/.cache/jhbuild/build</filename>. Si se establece a <constant>None</constant> hace que las construcciones se ejecuten dentro de los árboles de fuentes</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-buildscript">
          <term><varname>buildscript</varname></term>
          <listitem>
            <simpara>Una cadena que especifica el script de construcción que usar. El valor recomendado es el predeterminado, <literal>terminal</literal>. En particular, no lo configure como <literal>gtk</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-build-policy">
          <term><varname>build_policy</varname></term>
          <listitem>
            <simpara>Una cadena que especifica los módulos que construir. Las tres opciones son <literal>all</literal>, para construir todos los módulos solicitados, <literal>updated</literal>, para construir solamente los módulos que han cambiado, o <literal>updated-deps</literal> para construir los módulos que han cambiado o que tienen dependencias que han cambiado. El valor predeterminado es <literal>updated-deps</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-checkoutroot">
          <term><varname>checkoutroot</varname></term>
          <listitem>
            <simpara>Una cadena que especifica la carpeta donde descomprimir los árboles de fuentes. A menos que <varname>buildroot</varname> esté configurado, las construcciones se harán también en esta carpeta. El valor predeterminado es <filename>~/checkout/gnome</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-checkout-mode">
          <term><varname>checkout_mode</varname></term>
          <listitem>
            <simpara>Una cadena que especifica cómo se realiza la descarga de carpetas en el control de versiones. El predeterminado es <literal>update</literal>. Esto se puede configurar para cada módulo usando <varname>module_checkout_mode</varname>. Los valores posibles son <literal>update</literal> (actualizar carpeta de descarga), <literal>clobber</literal> (vaciar la carpeta antes de descargar las fuentes), <literal>export</literal> (vaciar la carpeta y crear una copia no versionada de las fuentes) y <literal>copy</literal> (descargar en una carpeta diferente de en la que se construirá).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-copy-dir">
          <term><varname>copy_dir</varname></term>
          <listitem>
            <simpara>Una cadena que especifica la carpeta que copiar, si el modo de copia <link linkend="cfg-checkout-mode"><varname>checkout_mode</varname></link> está en uso. El predeterminado es la carpeta de descarga.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-cvs-program">
          <term><varname>cvs_program</varname></term>
          <listitem>
            <simpara>Una cadena que especifica qué programa usar para soporte de CVS. Éste puede ser <literal>git-cvsimport</literal> o <literal>cvs</literal>. El predeterminado es <literal>cvs</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-disable-Werror">
          <term><varname>disable_Werror</varname></term>
          <listitem>
            <simpara>Un valor booleano (valor predeterminado <literal>True</literal>) que controla si <literal>--disable-Werror</literal> se pasará a las construcciones automáticas. Muchos paquetes usan esta opción como una manera de desactivar advertencias fatales del compilador. El valor <literal>True</literal> 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 <literal>False</literal> tiene sentido para aquellos que usan jhbuild como parte de un sistema de integración continua o en sistemas de pruebas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-dvcs-mirror-dir">
          <term><varname>dvcs_mirror_dir</varname></term>
          <listitem>
            <simpara>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 <command>update</command> y <command>updateone</command> 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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="exit-on-error">
          <term><varname>exit_on_error</varname></term>
          <listitem>
            <simpara>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 <constant>True</constant> es equivalente a pasar la opción <option>--exit-on-errr</option>. El valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-extra-prefixes">
          <term><varname>extra_prefixes</varname></term>
          <listitem>
            <simpara>Una lista de cadenas que especifican, en orden, la lista de prefijos adicionales. JHBuild establece varias variables de entorno (como <envar>LD_LIBRARY_PATH</envar>, <envar>PKG_CONFIG_PATH</envar> y <envar>XDG_DATA_DIRS</envar>) basándose en la variable <varname>prefix</varname>. Añadir carpetas a <varname>extra_prefixes</varname> hará que estos prefijos también se incluyan con una prioridad inferior a la variable <varname>prefix</varname> 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 <filename>/usr/local</filename>, en cuyo caso contiene esta carpeta.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-help-website">
          <term><varname>help_website</varname></term>
          <listitem>
            <simpara>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. <varname>%(module)s</varname> en el URL se reemplazará con el nombre del módulo. Para desactivarlo, establezca <varname>help_website</varname> a <literal>None</literal>. El valor predeterminado es <literal>('Gnome Live!', 'http://live.gnome.org/JhbuildIssues/%(module)s')</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-installprog">
          <term><varname>installprog</varname></term>
          <listitem>
            <simpara>Una cadena que especifica qué programa usar como sustituto de <literal>/usr/bin/install</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-ignore-suggests">
          <term><varname>ignore_suggests</varname></term>
          <listitem>
            <simpara>Valor booleano que indica si se ignorarán las dependencias suaves cuando se calcule el árbol de dependencias. Su valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-interact">
          <term><varname>interact</varname></term>
          <listitem>
            <simpara>Un valor booleano que especifica si se interactúa con el usuario. Establecer este valor a <constant>False</constant> es equivalente a pasar la opción <option>--no-interact</option>. El valor predeterminado es <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makeargs">
          <term><varname>makeargs</varname></term>
          <listitem>
            <simpara>Una cadena que lista argumentos adicionales para pasarlos a <command>make</command>. JHBuild añadirá automáticamente la opción de ejecución en paralelo (<option>-j</option>) basándose en la disponibilidad de los núcleos de la CPU. Lo predeterminado es <literal>''</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makecheck">
          <term><varname>makecheck</varname></term>
          <listitem>
            <simpara>Valor booleano que indica si se ejecuta <command>make check</command> antes de <command>make</command>. De forma predeterminada está a <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makecheck-advistory">
          <term><varname>makecheck_advisory</varname></term>
          <listitem>
            <simpara>Un valor booleano que especifica si los fallos producidos al ejecutar <command>make check</command> deben ser sólo informativos y no provocar un fallo de la construcción. El valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makeclean">
          <term><varname>makeclean</varname></term>
          <listitem>
            <simpara>Valor booleano que indica si se ejecuta <command>make clean</command> después de <command>make</command>. De forma predeterminada está a <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makedist">
          <term><varname>makedist</varname></term>
          <listitem>
            <simpara>Un valor booleano que especifica si se ejecutará <command>make dist</command> antes de <command>make</command>. El valor predeterminado es <constant>False</constant>. Esta configuración es equivalente a pasar la opción <option>--dist</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makedistcheck">
          <term><varname>makedistcheck</varname></term>
          <listitem>
            <simpara>Un valor booleano que especifica si se ejecutará <command>make distcheck</command> antes de <command>make</command>. El valor predeterminado es <constant>False</constant>. Esta configuración es equivalente a pasar la opción <option>--distcheck</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-autogenargs">
          <term><varname>module_autogenargs</varname></term>
          <listitem>
            <simpara>Un diccionario que mapea nombres de módulos en cadenas que contienen argumentos para pasárselos a <command>autogen.sh</command>. La configuración de <varname>module_autogenargs</varname> se usa en lugar de la configuración global de <varname>autogenargs</varname>. Si un módulo en particular no está listado en el diccionario, se usará la variable global <varname>autogenargs</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-checkout-mode">
          <term><varname>module_checkout_mode</varname></term>
          <listitem>
            <simpara>Un diccionario que especifica el modo de descarga a usar para los módulos. Ésto omite la configuración global <varname>checkout_mode</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-makeargs">
          <term><varname>module_makeargs</varname></term>
          <listitem>
            <simpara>Un diccionario que mapea nombres de módulos en cadenas que contienen argumentos para pasárselos a <command>make</command>. El valor de <varname>module_makeargs</varname> reemplaza el valor de <varname>makeargs</varname>. Si un módulo en particular no está listado en el diccionario, se usará la variable global <varname>makeargs</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-makecheck">
          <term><varname>module_makecheck</varname></term>
          <listitem>
            <simpara>Un diccionario que mapea nombres de módulos en valores booleanos especificando si se ejecutará <command>make check</command> después de <command>make</command>. El valor de <varname>module_makecheck</varname> reemplaza el valor de <varname>makecheck</varname>. Si un módulo en particular no está listado en el diccionario, se usará la variable global <varname>makecheck</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-nopoison">
          <term><varname>module_nopoison</varname></term>
          <listitem>
            <simpara>Un diccionario que mapea nombres de módulos en valores booleanos. Si un módulo está establecido a <constant>True</constant>, JHBuild intentará construir los módulos dependientes aunque falle el módulo especificado. La configuración de <varname>module_nopoison</varname> reemplaza el valor de <varname>nopoison</varname>. Si un módulo en particular no está listado en el diccionario, se usará la variable global <varname>nopoison</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-extra-env">
          <term><varname>module_extra_env</varname></term>
          <listitem>
            <simpara>Un diccionario que mapea nombres de módulos a diccionarios con variables de entorno adicionales para pasar cuando se ejecutan comandos del módulo.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-static-analyzer">
          <term><varname>module_static_analyzer</varname></term>
          <listitem>
            <simpara>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 <varname>static_analyzer</varname> se omita.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-modules">
          <term><varname>modules</varname></term>
          <listitem>
            <simpara>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 <link linkend="command-reference-buildone"><command>buildone</command></link>. Su valor predeterminado es <literal>['meta-gnome-desktop']</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-moduleset">
          <term><varname>moduleset</varname></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-modulesets-dir">
          <term><varname>modulesets_dir</varname></term>
          <listitem>
            <simpara>Una cadena que especifica la carpeta que contiene el conjunto de módulos que usar. La predeterminada es la carpeta <filename>modulesets/</filename> en las fuentes de JHBuild.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nice-build">
          <term><varname>nice_build</varname></term>
          <listitem>
            <simpara>Ejecutar la construcción bajo la prioridad <constant>SCHED_IDLE</constant> en Linux, o con <command>nice</command> 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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nobuild">
          <term><varname>nobuild</varname></term>
          <listitem>
            <simpara>Un valor booleano que, si está establecido a <constant>True</constant>, hace que JHBuild no construya los módulos, sino que sólo descargue y descomprima las fuentes. El valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nonetwork">
          <term><varname>nonetwork</varname></term>
          <listitem>
            <simpara>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 <constant>True</constant> es equivalente a pasar la opción <option>--no-network</option>. El valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nonotify">
          <term><varname>nonotify</varname></term>
          <listitem>
            <simpara>Un valor booleano que especifica si se deben emitir notificaciones usando el demonio de notificaciones. Si está establecido a <constant>False</constant>, las notificaciones se emiten. El valor predeterminado es <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nopoison">
          <term><varname>nopoison</varname></term>
          <listitem>
            <simpara>Un valor booleano que, si está establecido a <constant>True</constant>, hace que JHBuild intente construir módulos aunque fallen una o más dependencias del módulo. Esta opción es equivalente al argumento <option>--no-poison</option>. Su valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-notrayicon">
          <term><varname>notrayicon</varname></term>
          <listitem>
            <simpara>Un valor booleano que especifica si se debe mostrar un icono en la bandeja del sistema usando Zenity. Si está establecido a <constant>False</constant>, las notificaciones se emiten. El valor predeterminado es <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-noxvfb">
          <term><varname>noxvfb</varname></term>
          <listitem>
            <simpara>Un valor booleano que, si está establecido a <constant>True</constant>, hace que JHBuild ejecute comprobaciones gráficas en un servidor X real, en lugar de usar <command>Xvfb</command>. Esta opción es equivalente a pasar <option>--no-xvfb</option>. El valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-partial-build">
          <term><varname>partial_build</varname></term>
          <listitem>
            <simpara>Un valor booleano que, si está establecido a <constant>True</constant>, 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 <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-prefix">
          <term><varname>prefix</varname></term>
          <listitem>
            <simpara>Una cadena que indica el prefijo donde instalar módulos.<varname>prefix</varname> debe ser una ruta absoluta. Esta carpeta debe ser escribible. La carpeta predeterminada es <literal>'~/jhbuild/install/'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-pretty-print">
          <term><varname>pretty_print</varname></term>
          <listitem>
            <simpara>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 <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-print-command-pattern">
          <term><varname>print_command_pattern</varname></term>
          <listitem>
            <simpara>Se muestra una cadena antes de que JHBuild ejecute un comando. <varname>%(command)s</varname> se reemplazará en la cadena por el comando que ejecutar. <varname>%(cwd)s</varname> se reemplazará en la cadena por la carpeta de trabajo actual. La predeterminada es <literal>«%(command)s»</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-progress-bar">
          <term><varname>progress_bar</varname></term>
          <listitem>
            <simpara>Un valor booleano que especifica dónde mostrar una barra de progreso durante el <link linkend="cfg-quiet-mode">modo silencioso </link>. El valor predeterminado es <literal>True</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-quiet-mode">
          <term><varname>quiet_mode</varname></term>
          <listitem>
            <simpara>Un valor booleano que si vale <constant>True</constant> desactiva la salida de los comandos en ejecución. Su valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-repos">
          <term><varname>repos</varname></term>
          <listitem>
            <simpara>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:</simpara>

<programlisting>repos['git.gnome.org'] = 'ssh://username@git.gnome.org/git/'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-skip">
          <term><varname>skip</varname></term>
          <listitem>
            <simpara>Una lista de módulos que omitir. Esta opción <option>--skip</option> de la lista de comandos extiende la lista. La lista esta vacía de manera predeterminada. si la lista contiene el valor especial <literal>'*'</literal>, JHBuild omitirá todos los módulos no listados en la variable <varname>modules</varname>. Esto puede se útil si quiere construir módulos sin sus dependencias implícitas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer">
          <term><varname>static_analyzer</varname></term>
          <listitem>
            <simpara>Un valor booleano que, si está establecido a <constant>True</constant>, ejecuta una herramienta de análisis estático en cada módulo que se empieza a construir. El valor predeterminado es <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer-outputdir">
          <term><varname>static_analyzer_outputdir</varname></term>
          <listitem>
            <simpara>Carpeta raíz en la que se guardarán los informes del análisis estático (si <varname>static_analyzer</varname> es <constant>True</constant>). El valor predeterminado es <filename>/tmp/jhbuild_static_analyzer</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer-template">
          <term><varname>static_analyzer_template</varname></term>
          <listitem>
            <simpara>Plantilla de comandos para el analizador estático. Esto tiene un parámetro <varname>outputdir</varname> (el valor de la variable de configuración <varname>static_analyzer_outputdir</varname>) y <varname>module</varname> () el nombre del módulo que se está construyendo actualmente) sustituido en <function>printf</function>-style. El comando resultante se usa como prefijo de <command>make</command> al construir el módulo. El valor predeterminado es <command>scan-build</command>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-sticky-date">
          <term><varname>sticky_date</varname></term>
          <listitem>
            <simpara>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 <literal>«<replaceable>yyyy</replaceable>-<replaceable>mm</replaceable>-<replaceable>dd</replaceable>»</literal>. El valor predeterminado es  <constant>None</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-svn-program">
          <term><varname>svn_program</varname></term>
          <listitem>
            <simpara>Una cadena que especifica qué programa usar para soporte de subversion. Éste puede ser <literal>svn</literal> o <literal>git-svn</literal>. El predeterminado es <literal>svn</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-system-libdirs">
          <term><varname>system_libdirs</varname></term>
          <listitem>
            <simpara>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 <envar>PKG_CONFIG_PATH</envar>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-tarballdir">
          <term><varname>tarballdir</varname></term>
          <listitem>
            <simpara>Una cadena que, si está establecida, indica que los archivos tar se descargarán en la carpeta especificada en lugar de en <varname>checkoutroot</varname>. Esto es útil si tiene múltiples entornos JHBuild o si vacía habitualmente su <varname>checkoutroot</varname> y quiere reducir el uso del ancho de banda. El valor predeterminado es <literal>'~/.cache/jhbuild/downloads'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-tinderbox-outputdir">
          <term><varname>tinderbox_outputdir</varname></term>
          <listitem>
            <simpara>Una cadena que contiene la carpeta para guardar la salida de <command>jhbuild tinderbox</command>. Esta cadena se puede omitir con la opción <option>--output</option>. Su valor predeterminado es <constant>None</constant>, 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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-trycheckout">
          <term><varname>trycheckout</varname></term>
          <listitem>
            <simpara>Un valor booleano que si está establecido a <constant>True</constant> hace que JHBuild intente automáticamente resolver problemas 1) ejecutando <command>autogen.sh</command> 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 <option>--try-checkout</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-use-local-modulesets">
          <term><varname>use_local_modulesets</varname></term>
          <listitem>
            <simpara>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 <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-xvfbargs">
          <term><varname>xvfbargs</varname></term>
          <listitem>
            <simpara>Una cadena que lista los argumentos que pasar a <command>Xvfb</command> si se ejecutan comprobaciones gráficas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-conditions">
          <term><varname>conditions</varname></term>
          <listitem>
            <simpara>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 <literal>conditions.add()</literal> y <literal>conditions.discard()</literal> para modificar la lista si quiere hacer cambios.</simpara>
            <simpara>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 <option>--conditions=</option>. Los cambios hechos por <option>--conditions=</option> serán visibles al usar el archivo jhbuildrc, por lo que puede establecer otras variables basadas en el valor actual del conjunto, pero <option>--conditions=</option> se aplicará de nuevo después de cualquier cambio hecho por el jhbuildrc.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="config-reference-other">
      <title>Otras estructuras de los archivos de configuración</title>

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

      <variablelist>
        <varlistentry id="cfg-os-environ">
          <term><varname>os.environ</varname></term>
          <listitem>
            <para>Un diccionario que representa el entorno. Este entorno se le pasa a los procesos que JHBuild crea.</para>

            <para>Algunas variables de entorno influyentes incluyen <envar>CPPFLAGS</envar>, <envar>CFLAGS</envar>, <envar>INSTALL</envar> y <envar>LDFLAGS</envar>. Por ejemplo:</para>

<programlisting>os.environ['CFLAGS'] = '-O0'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><function>addpath</function>(<parameter>envvar</parameter>, <parameter>pathname</parameter>)</term>
          <listitem>
            <para>Esto añadirá una carpeta a la variable de entorno <envar>PATH</envar>. <function>addpath</function> 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).</para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><function>prependpath</function>(<parameter>envvar</parameter>, <parameter>pathname</parameter>)</term>
          <listitem>
            <para>Después de procesar el archivo de configuración, JHBuild alterará algunas rutas basadas en variables, tales como <varname>prefix</varname> (ej. añadiendo <literal>$prefix/bin</literal> al principio de <envar>PATH</envar>).</para>

            <para>La función <function>prependpath</function> trabaja igual que <function>addpath</function>, excepto que la variable de entorno se modifica después de que JHBuild haya hecho sus cambios al entorno.</para>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>
  </section>

  <section id="moduleset-syntax">
    <title>Archivo de sintaxis del conjunto de módulos</title>

    <para>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 <filename>modulesets/</filename>. El esquema RELAX-NG se puede usar para editar los archivos del conjunto de módulos usando <literal>nxml-mode</literal> en Emacs.</para>

    <para>El elemento superior del archivo de un conjunto de módulos es el elemento <sgmltag class="element">moduleset</sgmltag>. 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.</para>

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

    <section id="moduleset-syntax-sources">
      <title>Repositorios de módulos</title>

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

      <para>El elemento <sgmltag class="element">repositorio</sgmltag> se usa para describir todos los tipos de repositorios. El elemento <sgmltag class="element">rama</sgmltag> se usa dentro de la definición del módulo para indicar configuraciones adicionales.</para>

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

      <para>El atributo <sgmltag class="attribute">nombre</sgmltag> es un identificador único del repositorio.</para>

      <para>El atributo <sgmltag class="attribute">predeterminado</sgmltag> especifica si este repositorio es el predeterminado para este conjunto de módulos.</para>

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

      <para>El atributo <sgmltag class="attribute">developer-href-example</sgmltag> se usa para especificar el formato del URL del repositorio usado por los desarrolladores. Esto es sólo informativo.</para>

      <para>El elemento <sgmltag class="element">rama</sgmltag> se usa dentro de las definiciones del módulo.</para>

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

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

      <para>El atributo <sgmltag class="attribute">repo</sgmltag> se usa para especificar un nombre de repositorio no predeterminado.</para>

      <para>El atributo <sgmltag class="attribute">module</sgmltag> se usa para especificar el nombre del módulo que descargar del repositorio. Su valor predeterminado es el identificador del módulo.</para>

      <para>El atributo <sgmltag class="attribute">checkoutdir</sgmltag> se usa para especificar la carpeta de descarga que usar. Su valor predeterminado es el identificador del módulo.</para>

      <para>A continuación se describen otros atributos</para>

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

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

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

        <para>Los atributos adicionales son <sgmltag class="attribute">trunk-template</sgmltag> (el predeterminado es <literal>«%(module)s»</literal>») y <sgmltag class="attribute">branches-template</sgmltag> (el predeterminado es <literal>«%(module)s/%(branch)s»</literal>). Estos atributos se usan para especificar plantillas para construir URL. El elemento <sgmltag class="element">branch</sgmltag> en la definición del módulo puede especificar los atributos <sgmltag class="attribute">branch</sgmltag> y <sgmltag class="attribute">user</sgmltag>. Estos valores se sustituirán en las plantillas. Si algún otro está definido se usa <sgmltag class="attribute">branches-template</sgmltag>, de lo contrario se usa <sgmltag class="attribute">trunk-template</sgmltag>. 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.</para>

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

        <para>Ejemplo de repositorio con los atributos <sgmltag class="attribute">template</sgmltag> definidos:</para>

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

        <para>Ejemplo de elementos de la <sgmltag class="element">branch</sgmltag> para el anterior repositorio:</para>

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

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

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

        <para>El tipo de repositorio se usa para definir un repositorio CVS.</para>

        <para>El atributo <sgmltag class="attribute">password</sgmltag> se usa para especificar la contraseña del repositorio.</para>

        <para>El atributo <sgmltag class="attribute">cvsroot</sgmltag> se usa para especificar la raíz del repositorio.</para>

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

<!-- TODO describe these attributes -->

        <para>Los atributos adicionales son: <sgmltag class="attribute">revision</sgmltag>, <sgmltag class="attribute">update-new-dirs</sgmltag> y <sgmltag class="attribute">override-checkoutdir</sgmltag>.</para>
      </section>

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

        <para>El tipo de repositorio se usa para definir un repositorio Darcs.</para>

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

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

        <para>El tipo de repositorio se usa para definir un repositorio Git.</para>

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

        <para>Permite los siguientes atributos en el elemento <sgmltag class="element">branch</sgmltag>:</para>

        <para>El atributo <sgmltag class="attribute">revision</sgmltag> 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 <varname>branches</varname>. El cambio sólo se realizará si la rama actual está controlando una rama remota, para no interferir en su trabajo.</para>

        <para>El atributo <sgmltag class="attribute">tag</sgmltag> se usa para especificar una revisión que descargar siempre en la fase de actualización. Omite el atributo <sgmltag class="attribute">revision</sgmltag>.</para>

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

<programlisting>
&lt;branch repo="git.freedesktop.org" module="swfdec/swfdec"
        checkoutdir="swfdec"
        revision="<replaceable>rama-local-o-remota</replaceable>"
        tag="<replaceable>árbol</replaceable>"/&gt;
        </programlisting>
      </section>

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

        <para>El tipo de repositorio se usa para definir un repositorio Mercurial.</para>

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

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

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

        <para>El tipo de repositorio se usa para definir un repositorio Monotone.</para>

        <para>El atributo <sgmltag class="attribute">server</sgmltag> se usa para especificar el servidor del repositorio.</para>

        <para>El atributo <sgmltag class="attribute">database</sgmltag> se usa para especificar la base de datos que usar por el repositorio.</para>

        <para>El atributo <sgmltag class="attribute">defbranch</sgmltag> se usa para especificar la rama del repositorio que usar.</para>

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

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

        <para>El tipo de repositorio se usa para definir un repositorio Subversion.</para>

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

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

        <para>Permite una <sgmltag class="attribute">revision</sgmltag> en el elemento <sgmltag class="element">branch</sgmltag>. Este atributo define la rama que se descargará o, si es un número, una revisión específica para descargar.</para>

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

        <para>Es posible especificar una disposición de <literal>svn</literal> personalizada usando <sgmltag class="attribute">trunk-template</sgmltag> (el predeterminado es «%(module)s/trunk»), <sgmltag class="attribute">branches-template</sgmltag> (el predeterminado es «%(module)s/branches/%(branch)s») y <sgmltag class="attribute">tags-template</sgmltag> (el predeterminado es «%(module)s/tags/%(tag)s»)</para>
      </section>

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

        <para>Este tipo de repositorio se usa para definir un repositorio del sistema falso. Se necesita crear un repositorio del sistema para crear los <link linkend="moduleset-syntax-defs-systemmodule"><sgmltag class="element">systemmodules</sgmltag></link>.</para>

<programlisting>
&lt;repository type="system" name="system"/&gt;
</programlisting>
      </section>

      <section id="moduleset-syntax-sources-tarball">
        <title>Archivos tar</title>

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

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

        <para>Permite los siguientes atributos en el elemento <sgmltag class="element">branch</sgmltag>:</para>

        <para>El atributo <sgmltag class="attribute">module</sgmltag> especifica el archivo que se descargará y compilará; el atributo <sgmltag class="attribute">version</sgmltag> especifica la versión del módulo.</para>

        <para>Los atributos <sgmltag class="attribute">size</sgmltag> y <sgmltag class="attribute">hash</sgmltag>, al igual que el obsoleto <sgmltag class="attribute">md5sum</sgmltag>, son opcionales. Si estos atributos están presentes, se usan para comprobar que el paquete fuente se ha descargado correctamente.</para>

        <para>The <sgmltag class="attribute">rename-tarball</sgmltag> can be
          used to rename the tarball file when downloading, in case the original
          name conflicts with another module.</para>

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

        <para>Para conjuntos de módulos empaquetados con JHBuild, los archivos de parches se buscan en la carpeta <filename>jhbuild/patches/</filename>; 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 <filename>patches/</filename>. También es posible que el atributo <sgmltag class="attribute">file</sgmltag> especifique un URI, en cuyo caso se descargará de esa ubicación.</para>

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

        <para>Un archivo tar del elemento <sgmltag class="element">branch</sgmltag> puede contener también elementos <sgmltag class="element">quilt</sgmltag> que especifiquen elementos <sgmltag class="element">branch</sgmltag> que importar.</para>
      </section>
    </section>

    <section id="moduleset-syntax-includes">
      <title>Incluir otros conjuntos de módulos</title>

      <para>JHBuild permite un conjunto de módulos para incluir los contenidos referidos por otro usando el elemento <sgmltag class="element">include</sgmltag>.</para>

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

      <para>El atributo <sgmltag class="attribute">href</sgmltag> es una referencia al URI del conjunto de módulos que se incluirá, relativa al archivo que contiene el elemento <sgmltag class="element">include</sgmltag>.</para>

      <para>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).</para>
    </section>

    <section id="moduleset-syntax-defs">
      <title>Definiciones de módulos</title>

      <para>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.</para>

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

      <para><command>jhbuild build</command> añadirá a la lista de módulos todos los módulos listados en el elemento <sgmltag class="element">dependencies</sgmltag>, si no están ya incluidos, y se asegurará que los módulos dependientes se construyen primero.</para>

      <para>Después de generar la lista de módulos, los módulos listados en el elemento <sgmltag class="element">suggests</sgmltag> 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.</para>

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

        <para>El elemento <sgmltag class="element">autotools</sgmltag> se usa para definir un módulo que se compila usando el sistema de construcción GNU Autotools.</para>

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

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

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

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

        <para>Los atributos <sgmltag class="attribute">autogenargs</sgmltag>, <sgmltag class="attribute">makeargs</sgmltag> y <sgmltag class="attribute">makeinstallargs</sgmltag> se usan para especificar argumentos adicionales para pasarlos a <command>autogen.sh</command>, <command>make</command> y <command>make install</command> respectivamente.</para>

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

	<para><sgmltag class="attribute">uninstall-before-install</sgmltag> 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.</para>

        <para>El atributo <sgmltag class="attribute">supports-non-srcdir-builds</sgmltag> se usa para marcar módulos que no se pueden construir limpiamente usando una carpeta de fuentes por separado.</para>

        <para>El atributo <sgmltag class="attribute">force-non-srcdir-builds</sgmltag> 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.</para>

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

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

        <para>El atributo <sgmltag class="attribute">check-target</sgmltag> se debe especificar (con un valor «false») para aquellos módulos que no tienen un objetivo <command>make check</command>.</para>

        <para>El atributo <sgmltag class="attribute">supports-static-analyzer</sgmltag> 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 <command>scan-build</command>.</para>

        <para>El atributo <sgmltag class="attribute">supports-unknown-configure-options</sgmltag> se usa para marcar módulos que no se devolverán un error si se les pasa una opción desconocida en <filename>configure</filename>. Las opciones globales de construcción no se usarán para ese módulo.</para>
      </section>

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

        <para>El elemento <sgmltag class="element">cmake</sgmltag> se usa para definir un módulo que se construirá usando el sistema de construcción CMake.</para>

<programlisting>
  &lt;cmake id="<replaceable>nombre del módulo</replaceable>"
            [ skip-install="<replaceable>skip-install</replaceable>" ]
            [ cmakedir="<replaceable>cmakedir</replaceable>" ]
            [ force-non-srcdir-builds="<replaceable>force-non-srcdir-builds</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/cmake&gt;
</programlisting>

        <para>El atributo <sgmltag class="attribute">cmakedir</sgmltag> se usa para especificar la subcarpeta en la que se ejecutará cmake en relación a la carpeta de fuentes.</para>

        <para>El atributo <sgmltag class="attribute">force-non-srcdir-builds</sgmltag> 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.</para>
      </section>

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

        <para>El elemento <sgmltag class="element">meson</sgmltag> se usa para definir un módulo que se construirá usando el sistema de construcción Meson.</para>

<programlisting>
  &lt;meson id="<replaceable>modulename</replaceable>"
            [ skip-install="<replaceable>skip-install</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

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

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

        <para>El elemento <sgmltag class="element">distutils</sgmltag> se usa para definir un módulo que se construirá usando las distutils de python.</para>

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

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/distutils&gt;
</programlisting>
      </section>


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

        <para>El elemento <sgmltag class="element">distutils</sgmltag> se usa para definir un módulo que se construirá usando las distutils de python.</para>

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

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/distutils&gt;
</programlisting>
      </section>

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

        <para>El elemento <sgmltag class="element">linux</sgmltag> define un módulo usado para construir un kernel linux. Además, se puede seleccionar una configuración del kernel aparte usando el subelemento <sgmltag class="element">kconfig</sgmltag>.</para>

<programlisting>
&lt;linux id="<replaceable>id</replaceable>"
	  [ makeargs="<replaceable>argumentos de make</replaceable>" ]&gt;

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

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;

  &lt;kconfig [ repo="<replaceable>repositorio</replaceable>" ]
	    version="<replaceable>versión</replaceable>"
	    [ module="<replaceable>módulo</replaceable>" ]
	    [ config="<replaceable>configuración</replaceable>" ] /&gt;

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

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

        <para>El elemento <sgmltag class="element">perl</sgmltag> se usa para construir módulos perl.</para>

        <para>El atributo <sgmltag class="attribute">makeargs</sgmltag> se usa para especificar argumentos adicionales para pasárselos a <command>make</command>.</para>

<programlisting>
&lt;perl id="<replaceable>nombre del módulo</replaceable>"
	 [ makeargs="<replaceable>makeargs</replaceable>" ]&gt;

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

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;

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

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

        <para>El elemento <sgmltag class="element">systemmodule</sgmltag> 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.</para>

<programlisting>
&lt;systemmodule id="<replaceable>nombre del módulo</replaceable>"&gt;
  &lt;pkg-config&gt;<replaceable>pkg-config</replaceable>.pc&lt;/pkg-config&gt;

  &lt;branch repo="<replaceable>sistema</replaceable>" version="<replaceable>versión</replaceable>" /&gt;
&lt;/systemmodule&gt;
</programlisting>

        <para>Si el módulo del sistema no proporciona un archivo pkg-config, se puede usar la etiqueta <sgmltag class="element">systemdependencies</sgmltag> para identificar las dependencias. El atributo <sgmltag class="attribute">type</sgmltag> de la etiqueta <sgmltag class="element">dep</sgmltag> soporta dos valores:</para>

        <orderedlist>
          <listitem>
            <simpara>Valor <sgmltag class="attvalue">path</sgmltag>. La ruta se busca para especificar el nombre del programa.</simpara>
          </listitem>
          <listitem>
            <simpara>Valor <sgmltag class="attvalue">c_include</sgmltag>. Se busca en la ruta de inclusión de C el nombre de la cabecera que coincida. <sgmltag class="attribute">name</sgmltag> puede incluir una subcarpeta. La carpeta de búsqueda de inclusiones de C se puede modificar estableciendo <varname>CPPFLAGS</varname> con las variables de configuración <varname>cflags</varname> o <link linkend="cfg-module-autogenargs"><varname>module_autogenargs</varname></link>.</simpara>
          </listitem>
        </orderedlist>

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

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

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

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

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

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

        <para>El elemento <sgmltag class="element">waf</sgmltag> se usa para definir un módulo que se construirá con el sistema de construcción Waf.</para>

        <para>El atributo <sgmltag class="attribute">waf-command</sgmltag> se usa para especificar el script del comando waf a usar; el predeterminado es <command>waf</command>.</para>

        <para>El atributo <sgmltag class="attribute">python-command</sgmltag> se usa para especificar el ejecutable de Python que usar; el predeterminado es <command>python</command>. Esto es útil para construir módulos con la versión 3 de Python.</para>

<programlisting>
&lt;waf id="<replaceable>nombre del módulo</replaceable>"&gt;
	 [ python-command="<replaceable>comando python</replaceable>" ]
	 [ waf-command="<replaceable>comando waf</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/waf&gt;
</programlisting>
      </section>

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

        <para>El elemento <sgmltag class="element">testmodule</sgmltag> se usa para crear un módulo que ejecute un conjunto de pruebas usado LDTP o Dogtail.</para>

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

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

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;

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

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

        <para>El atributo <sgmltag class="attribute">type</sgmltag> 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».</para>

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

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

        <para>El elemento <sgmltag class="element">metamodule</sgmltag> define un módulo que actualmente no hace nada. El único propósito de un módulo de este tipo son sus dependencias.</para>

        <para>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.</para>

<programlisting>
&lt;metamodule id="<replaceable>nombre del módulo</replaceable>"&gt;
  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;suggests&gt;
    &lt;dep package="<replaceable>nombre del módulo</replaceable>"/&gt;
    ...
  &lt;/suggests&gt;
&lt;/metamodule&gt;
</programlisting>

        <para>El atributo <sgmltag class="attribute">id</sgmltag> proporciona el nombre del módulo. Los elementos hijos se manejan igual que para <link linkend="moduleset-syntax-defs-autotools"><sgmltag class="element">autotools</sgmltag></link>.</para>
      </section>
    </section>

    <section id="moduleset-deprecated-elements">
      <title>Elementos obsotelos</title>

      <section id="moduleset-deprecated-elements-syntax-sources">
        <title>Repositorios de módulos</title>

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

          <para>El elemento <sgmltag class="element">cvsroot</sgmltag> está obsoleto; en su lugar, se debe usar el elemento <sgmltag class="element">repository</sgmltag>.</para>

          <para>El elemento <sgmltag class="element">cvsroot</sgmltag> se usa para describir un repositorio CVS.</para>

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

          <para>El atributo <sgmltag class="attribute">name</sgmltag> debe ser un identificador único para el repositorio CVS.</para>

          <para>El atributo <sgmltag class="attribute">default</sgmltag> indica si es el repositorio de módulos predeterminados para ese archivo de conjuntos de módulos.</para>

          <para>El atributo <sgmltag class="attribute">root</sgmltag> lista la raíz de CVS usada para acceso anónimo a este repositorio, y el atributo <sgmltag class="attribute">password</sgmltag> da la contraseña usada para el acceso anónimo.</para>
        </section>

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

          <para>El elemento <sgmltag class="element">svnroot</sgmltag> está obsoleto; en su lugar se debe usar el elemento <sgmltag class="element">repository</sgmltag>.</para>

          <para>El elemento <sgmltag class="element">svnroot</sgmltag> se usa para describir un repositorio de Subversion.</para>

<programlisting>
  &lt;svnroot name="<replaceable>nombre del raíz</replaceable>"
           [ default="<replaceable>sí|no</replaceable>" ]
           href="<replaceable>svnroot-anónimo</replaceable>"/&gt;
</programlisting>

          <para>El atributo <sgmltag class="attribute">name</sgmltag> debe ser un identificador único para el repositorio de Subversion.</para>

          <para>El atributo <sgmltag class="attribute">default</sgmltag> indica si es el repositorio de módulos predeterminados para ese archivo de conjuntos de módulos.</para>

          <para>El atributo <sgmltag class="attribute">href</sgmltag> lista el URL base del repositorio. Probablemente será un URL <literal>http</literal>, <literal>https</literal> o <literal>svn</literal>.</para>
        </section>
      </section>

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

      <section>
        <title>Tipos de módulos obsoletos</title>

        <warning>
          <para>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.</para>
        </warning>

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

          <important>
            <para>El elemento obsoleto es sólo una fina envoltura alrededor del tipo de módulo <sgmltag class="element">autotools</sgmltag> y del tipo de repositorio <sgmltag class="element">tarball</sgmltag>.</para>
          </important>

          <para>El elemento <sgmltag class="element">tarball</sgmltag> se usa para definir un módulo que se construirá a partir de un archivo tar.</para>

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

          <para>Los atributos <sgmltag class="attribute">id</sgmltag> y <sgmltag class="attribute">version</sgmltag> se usan para identificar el módulo.</para>

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

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

          <para>Para conjuntos de módulos empaquetados con JHBuild, los archivos de parches se buscan en la carpeta <filename>jhbuild/patches/</filename>; 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 <filename>patches/</filename>. También es posible que el atributo <sgmltag class="attribute">file</sgmltag> especifique un URI, en cuyo caso se descargará de esa ubicación.</para>

          <para>Los otros atributos y los elementos <sgmltag class="element">dependencies</sgmltag>, <sgmltag class="element">suggests</sgmltag> y <sgmltag class="element">after</sgmltag> se procesan de la misma manera que para el comando <link linkend="moduleset-syntax-defs-autotools">autotools</link>.</para>
        </section>
      </section>

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

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