<?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="pt-BR">
  <articleinfo>
    <title>Manual do 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 do JHBuild v0.5</revnumber> <date>Janeiro de 2008</date></revision>
      <revision><revnumber>Manual do JHBuild v0.1</revnumber> <date>Agosto de 2007</date></revision>
    </revhistory>
    <abstract role="description">
      <para>JHBuild é uma ferramenta usada para compilar todo o ambiente do GNOME do sistema de controle de versão. JHBuild também pode ser personalizado para compilar outros projetos.</para>
    </abstract>
  
    <othercredit class="translator">
      <personname>
        <firstname>Rafael Fontenelle</firstname>
      </personname>
      <email>rafaelff@gnome.org</email>
    </othercredit>
    <copyright>
      
        <year>2013-2017</year>
      
      <holder>Rafael Fontenelle</holder>
    </copyright>
  </articleinfo>

  <section id="introduction">
    <title>Introdução</title>

    <para>JHBuild é uma ferramenta projetada para facilitar a compilação de coleções de pacotes fontes, chamados de <quote>módulos</quote>. JHBuild usa arquivos de <quote>coleção de módulos</quote>, ou module sets, para descrever os módulos disponíveis para compilação. Os arquivos de <quote>coleção de módulos</quote> incluem informações de dependências que permite ao JHBuild descobrir que módulos são necessários para compilar e em que ordem.</para>

    <para>JHBuild foi escrito originalmente para compilar o <ulink url="http://www.gnome.org">GNOME</ulink>, mas ele tem sido estendido para ser usável com outros projetos. Um arquivo de <quote>coleção de módulos</quote> pode ser hospedado em um servidor web, permitindo regras de compilação independente do projeto do JHBuild.</para>

    <para>JHBuild pode compilar módulos de uma variedade de fontes, incluindo repositórios <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> e <ulink url="http://www.selenic.com/mercurial/">Mercurial</ulink>, assim como arquivos Tar e Zip hospedados em sites web ou FTP. JHBuild pode compilar módulos usando uma variedade de sistemas de compilação, incluindo Makefiles de Autotools, CMake, Meson, WAF, Python Distutils e Perl.</para>

    <para>JHBuild não tem a intenção de ser uma substituição dos sistemas de gerenciamento de pacotes das distribuições. Em vez disso, ele torna mais fácil compilar software em um prefixo de instalação separado sem interferir no resto do sistema.</para>
  </section>

  <section id="getting-started">
    <title>Primeiros passos</title>

    <para>JHBuild exige algumas etapas de configurações para ser executado antes de compilar softwares. JHBuild tem como pré-requisito alguns softwares e também algumas ferramenta, para obter e compilar os módulos de softwares.</para>

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

      <para>JHBuild requer um Python. Verifique se &gt;= 2.3 está instalado.</para>

      <para>Uma forma recomendada para baixar JHBuild é por meio do sistema de controle de versão, <command>git</command>. Isso pode ser alcançado com o seguinte comando. É recomendado executar o comando de um novo diretório onde todo código fonte será instalado, por exemplo, <filename>~/jhbuild/checkout</filename>.</para>

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

      <para>Isso vai baixar o JHBuild em uma pasta chamada <filename>jhbuild</filename> dentro do diretório atual. Agora, para compilar e instalar o JHBuild:</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>Se <application>gnome-common</application>, <application>yelp-tools</application> e <application>autotools</application> estiverem disponíveis, <filename>autogen.sh</filename> vai configurar o JHBuild para instalar via <application>autotools</application>. Se <application>gnome-common</application>, <application>yelp-tools</application> e <application>autotools</application> não estiverem disponíveis, <filename>autogen.sh</filename> vai configurar JHBuild para instalar por meio de um Makefile simples. Para sempre usar o método Makefile simples passe <option>--simple-install</option> para o <filename>autogen.sh</filename>.</para>

      <para>Se os passos acima concluírem com sucesso, um pequeno script de shell será instalado em <filename>~/.local/bin</filename> para executar JHBuild. Adicione <filename>~/.local/bin</filename> no <envar>PATH</envar>:</para>

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

      <para>Para adicionar permanentemente <filename>~/.local/bin</filename> à variável <envar>PATH</envar>, execute o seguinte 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>Configurando JHBuild</title>

      <para>JHBuild pode ser configurado por um arquivo de configuração. A localização padrão é <filename>~/.config/jhbuildrc</filename>. Se um arquivo de configuração não existir, o padrão. O arquivo de configuração usa uma sintaxe Python. Um exemplo é fornecido em <filename>examples/sample.jhbuildrc</filename>. Copie <filename>examples/sample.jhbuildrc</filename> para <filename>~/.config/jhbuildrc</filename> e personalize da forma que precisar.</para>

      <para>A amostra de configuração fará com que o JHBuild compile os módulos de <application>meta-gnome-core</application> e <application>meta-gnome-apps-tested</application> e as dependências da coleção de módulos <systemitem>gnome-apps</systemitem>. JHBuild vai descompactar as árvores de fontes para <filename>~/jhbuild/checkout/</filename> e instalar todos os arquivos em subdiretórios de <filename>~/jhbuild/install/</filename>. Os dois diretórios devem ser poder ser escritos.</para>

      <para>Variáveis de configuração estão documentadas em <xref linkend="config-reference"/>. A maioria das variáveis normalmente usadas são:</para>

      <variablelist>
<?dbhtml list-presentation="table"?>
        <varlistentry>
          <term><link linkend="cfg-repos"><varname>repos</varname></link></term>
          <listitem>
            <simpara>Um dicionário que pode ser usado para especificar uma localização alternativa de repositório para um repositório particular. Esta variável de configuração é útil para desenvolvedores de módulos. Por padrão, JHBuild vai baixar o código de repositórios usando uma localização anônima de repositório. As chaves de dicionário são nomes curtos de repositórios e os nomes são textos com a localização alternativa do repositório. Por exemplo:</simpara>

<programlisting>repos['git.gnome.org'] = 'ssh://<replaceable>usuário</replaceable>@git.gnome.org/git/'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-moduleset"><varname>moduleset</varname></link></term>
          <listitem>
            <simpara>Um texto ou uma lista de textos especificando os nomes das coleções de módulos a serem usados. Pode ser o nome do arquivo de uma coleção de módulos inclusa no JHBuild (excluindo o caminho e extensão) ou uma URL de HTTP completa para uma coleção de módulos gerenciada externamente. Coleções de módulos de URL de HTTP são mantidas no cache localmente. Se um módulo com o mesmo nome estiver presente em mais de uma coleção de módulos, a última coleção listada terá prioridade. As coleções de módulos fornecidas com o JHBuild são atualizadas para corresponder à versão de desenvolvimento atual do GNOME.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-modules"><varname>modules</varname></link></term>
          <listitem>
            <simpara>Uma lista de textos especificando módulos para compilar. A lista de módulos realmente compilada será expandida recursivamente para incluir todas as dependências, a menos que o comando <link linkend="command-reference-buildone"> <command>buildone</command></link> seja usado. Padrão é <literal>['meta-gnome-desktop']</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-checkoutroot"><varname>checkoutroot</varname></link></term>
          <listitem>
            <simpara>Um texto especificando o diretório para o qual serão desempacotadas as árvores de fontes. Se <link linkend="cfg-buildroot"><varname>buildroot</varname></link> estiver definido para <constant>None</constant>, as compilações vão ocorrer neste diretório também. Padrão é <filename>~/jhbuild/checkout</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-prefix"><varname>prefix</varname></link></term>
          <listitem>
            <simpara>Um texto especificando o prefixo no qual serão instalados os módulos. <varname>prefix</varname> deve ser um caminho absoluto. Deve haver permissão de escrita para este diretório. Padrão é <literal>'~/jhbuild/install/'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-autogenargs"><varname>autogenargs</varname></link></term>
          <listitem>
            <simpara>Um texto contendo argumentos passados para o script <command>autogen.sh</command> de todos os módulos. Pode ser sobrescrito por módulos em particular usando o dicionário <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>Um texto listando argumentos adicionais a serem passados para o <command>make</command>. JHBuild vai anexar automaticamente a opção de execução paralela (<option>-j</option>) baseada nos núcleos de CPU disponíveis. Padrão é <literal>""</literal>.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="getting-started-bootstrap">
      <title>Pré-requisitos de compilação</title>

      <para>Antes que qualquer módulo possa ser compilado, é necessário ter certas ferramentas de compilação instaladas. Ferramentas de compilação comuns incluem o GNU Autotools (<application>autoconf</application>, <application>automake</application>, <application>libtool</application> e <application>gettext</application>), o conjunto de ferramentas GNU (<application>binutils</application>, <application>gcc</application>, <application>g++</application>), make, pkg-config e Python, dependendo de quais módulos serão compilados.</para>

      <para>JHBuild pode verificar se as ferramentas estão instaladas usando o <command>sanitycheck</command> command:</para>

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

      <para>Se este comando exibir quaisquer mensagens, por favor instale o pacote necessário do repositório de sua distribuição. Uma lista de <ulink url="http://live.gnome.org/JhbuildDependencies">nomes de pacotes</ulink> para diferentes distribuições é mantida no wiki do GNOME. Execute o comando <command>sanitycheck</command> novamente após a instalação dos pacotes da distribuição para certificar de que as ferramentas necessárias estão presentes.</para>
    </section>

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

      <para>Após a configuração ter sido concluída, JHBuild poderá ser usado para compilar softwares. Para compilar todos os módulos selecionados no arquivo <filename>~/.config/jhbuildrc</filename>, execute o seguinte comando:</para>

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

      <para>JHBuild vai baixar, configurar, compilar e instalar cada um dos módulos. Se um erro ocorrer em qualquer estágio, o JHBuild vai apresentar um menu perguntando o que deve ser feito. As escolhas incluem entrar em um shell para corrigir o erro, executar novamente a compilação de vários estágios, desistir do módulo ou ignorar o erro e continuar.</para>

      <note>
        <simpara>Desistir do módulo vai levar qualquer módulo que dependa dele a falhar.</simpara>
      </note>

      <para>Logo abaixo está um exemplo do menu exibido:</para>

<screen>  [1] Re-executar fase build
  [2] Ignorar erro e continuar para install
  [3] Desistir do módulo
  [4] Iniciar shell
  [5] Recarregar configuração
  [6] Ir para fase "limpar diretório e iniciar novamente"
  [7] Ir para fase "configure"
  [8] Ir para fase "clean"
  [9] Ir para fase "distclean"
<prompt>escolha:</prompt> </screen>

      <para>Também é possível compilar uma coleção diferente de módulos e suas dependências passando os nomes de módulos para o comando <command>build</command>. Por exemplo, para compilar gtk+:</para>

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

      <para>Se JHBuild for cancelado no meio de uma compilação, é possível resumi-la em um módulo em particular usando a opção <option>--start-at</option>:</para>

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

      <para>Para compilar um ou mais módulos, ignorando suas dependências, JHBuild tem o comando <command>buildone</command>. Para o comando <command>buildone</command> concluir com sucesso, todas as dependências devem estar previamente compiladas e instaladas ou fornecidas por pacotes de distribuição.</para>

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

      <para>Quando desenvolvendo ativamente um módulo, você provavelmente o faz no diretório de trabalho dos fontes. O <command>make</command> vai chamar o sistema de compilação e instalar o módulo. Isso será uma parte chave do ciclo de editar-compilar-instalar-testar.</para>

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

      <para>Para obter uma lista de módulos e dependências que o JHBuild vai compilar e a ordem na qual eles serão compilados, use o comando <command>list</command>:</para>

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

      <para>Para obter informações sobre um módulo em particular, use o comando <command>info</command>:</para>

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

      <para>Para baixar ou atualizar os fontes de softwares sem compilá-los, use o comando <command>update</command>. O comando <command>update</command> fornece uma oportunidade para modificar os fontes antes de compilar e pode ser útil se a conexão com a Internet ficar variando.</para>

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

      <para>Posteriormente, JHBuild pode compilar tudo sem baixar ou atualizar os fontes:</para>

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

      <para>Para executar um comando em particular com o mesmo ambiente usado pelo JHBuild, use o comando <command>run</command>:</para>

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

      <para>Para iniciar um shell com o mesmo ambiente usado pelo JHBuild, use o comando <command>shell</command>:</para>

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

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

    <para>Esta seção fornece um guia em compilação, instalação e execução do GNOME.</para>

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

      <para>Para compilar o GNOME, são necessários pacotes de desenvolvimento. Isso inclui:</para>

      <itemizedlist>
        <listitem>
          <simpara>DocBook XML DTD e folhas de estilos XSLT. Estas precisam estar registradas no catálogo XML (<filename>/etc/xml/catalog</filename>).</simpara>
        </listitem>
        <listitem>
          <simpara>Bibliotecas X.</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libsmbclient</filename> do Samba (usado para navegar por redes Windows).</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libbz2</filename> do bzip2.</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libpng</filename>, <filename>libjpeg</filename> e <filename>libtiff</filename> (usado para carregar imagens).</simpara>
        </listitem>
      </itemizedlist>

      <para>Se instalando pacotes de distribuição, e se aplicável a sua distribuição, instale os pacotes <quote>dev</quote> ou <quote>devel</quote> correspondentes. Uma lista de <ulink url="http://live.gnome.org/JhbuildDependencies">nomes de pacotes</ulink> de diferentes distribuições é mantida no wiki do GNOME.</para>
    </section>

    <section id="running-single-application">
      <title>Executando um único aplicativo do GNOME</title>

      <para>Esta seção detalha como executar um único aplicativo do GNOME. O aplicativo vai executar dentro no ambiente atual. Para executar o aplicativo dentro do GNOME do JHBuild veja <xref linkend="running-gnome"/>.</para>

      <para>Abra um shell do JHBuild. O shell do JHBuild tem todas as variáveis de ambiente necessárias definidas.</para>

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

      <para>Verifique o aplicativo correto que será executado. Por exemplo:</para>

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

      <para>Execute o aplicativo:</para>

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

      <para>Alternativamente, execute o aplicativo usando o comando <command>run</command>:</para>

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

    <section id="running-gnome">
      <title>Executando o ambiente GNOME</title>

      <para>Crie uma nova conta de usuário para executar o GNOME do JHBuild. Executar o GNOME do JHBuild usando uma conta de usuário diferente é recomendado para evitar problemas causados pelas configurações de usuário armazenadas na pasta pessoal. Este manual chama esta nova conta de usuário de <systemitem class="username">gnomedev</systemitem>.</para>

      <para>Configure o JHBuild na nova conta <systemitem class="username">gnomedev</systemitem>. Copie ou crie um link simbólico de <filename>~/.config/jhbuildrc</filename> e <filename>~/.local/bin/jhbuild</filename> para a pasta pessoal do <systemitem class="username">gnomedev</systemitem>.</para>

      <para>Abra um terminal como o usuário <systemitem class="username">gnomedev</systemitem>. Adicione permanentemente <filename>~/.local/bin</filename> para a variável <envar>PATH</envar>, execute o seguinte comando:</para>

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

      <para>Teste se o JHBuild funciona:</para>

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

      <section>
        <title>Configurando o GNOME para executar do gerenciador de exibição</title>

        <para>Compile e instale o GNOME do JHBuild.</para>

        <para>Habilite os sistemas de serviço. O GNOME do JHBuild vai usar o daemon do <application>D-Bus</application> do sistema em <filename>/usr/bin</filename> e os sistemas de serviços dentro de <filename>/usr/share/dbus-1/system-services/</filename>. O GNOME do JHBuild vai usar o daemon do <application>D-Bus</application> da sessão do JHBuild e os serviços dentro de  <filename><replaceable>~/jhbuild/install/</replaceable>/share/dbus-1/services/</filename>. Substitua <filename>~/jhbuild/install</filename> com o prefixo <varname>prefix</varname> de instalação do GNOME no comando abaixo:</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>Crie um script de inicialização do GNOME em <filename>/usr/bin/gnome-jhbuild-session</filename> com o seguinte, substituindo <filename>~/jhbuild/install</filename> com o prefixo <varname>prefix</varname>:</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>Torne o arquivo <filename>/usr/bin/gnome-jhbuild-session</filename> um executável:</para>

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

        <para>Para adicionar uma nova entrada de sessão no gerenciador de exibição, crie <filename>/usr/share/xsessions/gnome-jhbuild.desktop</filename> e digite:</para>

<programlisting>[Desktop Entry]
Name=GNOME (JHBuild)
Comment=Esta sessão conecta você na sessão de teste do GNOME
TryExec=/usr/bin/gnome-jhbuild-session
Exec=/usr/bin/gnome-jhbuild-session
Icon=
Type=Application</programlisting>

        <para>Reinicie o <command>gdm</command>.</para>

        <para/>
      </section>

      <section>
        <title>Executando o GNOME do gerenciador de exibição</title>

        <para>Para executar o GNOME do JHBuild, selecione a sessão do GNOME (JHBuild) no gerenciador de exibição antes de digitar as credenciais do <systemitem class="username">gnomedev</systemitem>. Havendo sucesso, GNOME do JHBuild vai ser exibido. Não havendo sucesso, verifique o arquivo de log. O arquivo de log está localizado no <filename>~gnomedev/.cache/gdm/session.log</filename> ou <filename>~gnomedev/.xsession-errors</filename>.</para>
      </section>
    </section>

    <section id="static-analysis">
      <title>Análise estática</title>

      <para>O JHBuild permite executar ferramentas de análise estática no código em módulos na medida em que eles são compilados. Para habilitar isso, defina a variável de configuração <varname>static_analyzer</varname> para <constant>True</constant> no arquivo de configuração <filename>.jhbuildrc</filename>.</para>

      <para>Se habilitado, cada vez que um módulo é compilado usando JHBuild, o processo de compilação vai ser interfaceado em um analisador estático, o qual vai gerar um relatório de quaisquer problemas que ele localizar com o código. Esses relatórios são salvos como arquivos HTML em subdiretórios de <filename>/tmp/jhbuild_static_analyzer</filename> (por padrão; o caminho pode ser alterado usando a variável de configuração <varname>static_analyzer_outputdir</varname>).</para>

      <para>Análise estática atualmente funciona apenas para módulos que usam autotools como sistema de compilação. Ele requer que o programa <command>scan-build</command> esteja instalado, apesar do comando que ele usa poder ser alterado por meio da variável de configuração <varname>static_analyzer_template</varname>.</para>
    </section>
  </section>

  <section id="buildbot-integration">
    <title>Integração com o Buildbot</title>

    <para>Acoplado com o projeto <ulink url="http://buildbot.net">Buildbot</ulink>, o JHBuild também pode funcionar como uma ferramenta de integração contínua. A configuração do Buildbot é usada pelo projeto GNOME no <ulink url="http://build.gnome.org">build.gnome.org</ulink>.</para>

    <section id="buildbot-slave">
      <title>Configurando um Buildbot escravo</title>

      <para>Um Buildbot escravo (slave) é uma variação de uma instalação normal do JHBuild que atende às requisições de um Buildbot mestre (master). É recomendado configurar o JHBuild e concluir uma compilação com a maioria dos módulos compilando com sucesso antes de adicionar as personalizações do Buildbot.</para>

      <para>Os comandos do Buildbot são opções para o comando <command>bot</command>. Para baixar e instalar os softwares extras exigidos, execute o seguinte comando:</para>

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

      <para>Assim que esta etapa tiver sido concluída com sucesso, três novas variáveis serão necessárias no <filename>~/.config/jhbuildrc</filename>.</para>

      <note>
        <para>Não é possível usar um arquivo de configuração alternativo, o <link linkend="option-file"><option>--file</option></link> não vai ter o efeito desejado.</para>
      </note>

<programlisting>
jhbuildbot_master = 'build.gnome.org:9070'
jhbuildbot_slavename = 'nomedoescravo'
jhbuildbot_password = 'senha'
</programlisting>

      <para><varname>jhbuildbot_master</varname> é um texto especificando o servidor do Buildbot mestre; o padrão é <literal>'build.gnome.org:9070'</literal>. <varname>jhbuildbot_slavename</varname> e <varname>jhbuildbot_password</varname> identificam o escravo no servidor mestre. Contate os administradores do Buildbot mestre para obter o nome e senha do escravo.</para>

      <note>
        <para>Os administradores do <ulink url="http://build.gnome.org">build.gnome.org</ulink> podem ser encontrados na <ulink url="mailto:build-brigade-list@gnome.org">lista de discussão 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>Referência de comando</title>

    <para>JHBuild usa uma sintaxe de linha de comando similar a ferramentas como CVS:</para>

    <cmdsynopsis><command>jhbuild</command> <arg><replaceable>opções globais</replaceable></arg> <arg choice="plain"><replaceable>comando</replaceable></arg> <arg><replaceable>argumentos do comando</replaceable></arg></cmdsynopsis>

    <para>As opções globais do JHBuild são:</para>

    <variablelist>
      <varlistentry id="option-file">
        <term><option>-f</option>, <option>--file</option> <replaceable>configuração</replaceable></term>
        <listitem>
          <simpara>Usa um arquivo de configuração alternativo em vez do padrão <filename>~/.config/jhbuildrc</filename>.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-m</option>, <option>--moduleset</option> <replaceable>coleção-de-módulos</replaceable></term>
        <listitem>
          <simpara>Usa uma coleção de módulos que não aquela listada no arquivo de configuração. Esta opção pode ser um caminho relativo, se a coleção de módulo estiver localizada na pasta da coleação de módulo do JHBuild, ou um caminho absoluto, se localizado em outro lugar.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--no-interact</option></term>
        <listitem>
          <simpara>Não solicita interação do usuário. Esta opção é útil para deixar uma compilação funcionando sozinha, de forma a assegurar que a compilação não seja interrompida.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--exit-on-error</option></term>
        <listitem>
          <simpara>Sai imediatamente se um módulo falhar na compilação. Esta opção é útil principalmente no modo não interativo, de forma a garantir que o jhbuild não continue a compilar qualquer módulo adicional.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--conditions</option></term>
        <listitem>
          <simpara>Modifica as opções de condição para serem diferentes daquelas determinadas na base do SO e daquelas especificadas no jhbuildrc. Modificações são especificadas como <literal>-wayland</literal> ou <literal>+docs</literal> com a finalidade de remover ou adicionar condições. Modificações múltiplas podem ser separadas por uma vírgula (e.g.: <command>--conditions=+docs,-wayland</command>) ou você pode dividi-las por múltiplos argumentos de <command>--conditions</command>.</simpara>
        </listitem>
      </varlistentry>
    </variablelist>

    <para>Adicionalmente, JHBuild verifica a presença, e valor, das seguintes variáveis de ambiente:</para>

    <variablelist>
      <varlistentry>
        <term><envar>JHBUILD_RUN_AS_ROOT</envar></term>
        <listitem>
          <simpara>Por padrão, JHBuild não executa quando usando o usuário root, para evitar operações destrutivas que podem afetar o sistema como um todo. Em certos casos, porém, é aceitável executar JHBuild como root; por exemplo, dentro de um contêiner ou em um ambiente de integração contínua. Exportar a <envar>JHBUILD_RUN_AS_ROOT</envar> vai desabilitar a verificação de id de usuário na inicialização.</simpara>
        </listitem>
      </varlistentry>
    </variablelist>

    <para>Opções específicas de comandos são listadas abaixo.</para>

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

      <para>O comando <command>autobuild</command> compila automaticamente os módulos especificados no arquivo de configuração e, então, envia os resultados para 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-relatório</replaceable></arg> <arg>--verbose</arg></cmdsynopsis>

      <para>As opções <option>--autogen</option>, <option>--clean</option>, <option>--distcheck</option>, <option>--skip</option> e <option>--start-at</option> são processadas a cada execução do comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>--report-url=<replaceable>url-relatório</replaceable></option>, <option>-r <replaceable>url-relatório</replaceable></option></term>
          <listitem>
            <simpara>Esta opção especifica a URL do JhAutobuild para a qual deve relatar.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--verbose</option>, <option>-v</option></term>
          <listitem>
            <simpara>Se especificada, a saída do JHBuild será mais detalhada.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>O comando <command>bootstrap</command> instala uma coleção de utilitários de compilação. Os utilitários de compilação incluem <application>autoconf</application>, <application>automake</application> e utilitários similares. O método recomendado para instalar os utilitários de compilação é via sistema de gerenciamento de pacotes da distribuição. O <command>bootstrap</command> deve ser usado apenas se os utilitários de compilação não forem fornecidos pelo sistema de gerenciamento de pacotes da distribuição, por exemplo no <systemitem class="osname">Mac OS</systemitem>.</para>

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

      <para>O comando <command>bootstrap</command> compila usando o mesmo método que o comando <command>build</command>, mas usa a coleção de módulos <filename>bootstrap.modules</filename>.</para>

      <para>Veja a documentação do comando <link linkend="command-reference-build"><command>build</command></link> por opções disponíveis.</para>
    </section>

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

      <para>O comando <command>build</command> compila um ou mais pacotes, incluindo suas dependências.</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>tags</replaceable></arg> <arg>-D <replaceable>data</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>tempo</replaceable></arg> <arg>--nodeps</arg> <arg rep="repeat">módulo</arg></cmdsynopsis>

      <para>Se nenhum nome de módulo for fornecido na linha de comando, a lista de <link linkend="cfg-modules">módulos</link> do arquivo de configuração será usada.</para>

      <variablelist>
        <varlistentry>
          <term><option>-a</option>, <option>--autogen</option></term>
          <listitem>
            <simpara>Sempre executa <command>autogen.sh</command> antes de compilar módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-c</option>, <option>--clean</option></term>
          <listitem>
            <simpara>Executa <command>make clean</command> antes de compilar módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--check</option></term>
          <listitem>
            <simpara>Executa <command>make check</command> após compilar módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-d</option>, <option>--dist</option></term>
          <listitem>
            <simpara>Executa <command>make dist</command> após compilar módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--distcheck</option></term>
          <listitem>
            <simpara>Executa <command>make distcheck</command> após compilar módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--distclean</option></term>
          <listitem>
            <simpara>Para módulos git, executa <command>git clean -dfx</command> antes de compilar módulos. Para os demais, executa <command>make distclean</command> antes de compilar módulos.</simpara>

            <note>
              <simpara>Esta opção vai excluir quaisquer alterações que não tiverem commit.</simpara>
            </note>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--ignore-suggests</option></term>
          <listitem>
            <simpara>Não compila dependências adicionais.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-n</option>, <option>--no-network</option></term>
          <listitem>
            <simpara>Não acessa a rede ao compilar módulos. Isso vai pular os estágios de baixar e atualizar em uma compilação. Se um módulo não puder ser compilado sem acessar a rede, a compilação do módulo vai falhar.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-s</option>, <option>--skip</option>=<replaceable>módulo,...</replaceable></term>
          <listitem>
            <simpara>Não compila os módulos listados. Usada para pular a compilação das dependências especificadas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--tags</option>=<replaceable>tag,...</replaceable></term>
          <listitem>
            <simpara>Ignora módulos que não correspondam à <replaceable>tag</replaceable>. Aos módulos são atribuídos automaticamente uma tag correspondente ao nome da coleção de módulos do módulo.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-t</option>, <option>--start-at</option>=<replaceable>módulo</replaceable></term>
          <listitem>
            <simpara>Inicia no módulo informado, ao invés do primeiro da lista. Esta opção é útil se a compilação foi interrompida.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-D</option> <replaceable>data</replaceable></term>
          <listitem>
            <simpara>Se houver suporte pelo sistema de controle de versão em questão, atualiza a árvore de fonte para a data especificada antes de compilar. É necessário um formato de data ISO. Ex.: <literal>"2009-09-18 02:32Z"</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-x</option>, <option>--no-xvfb</option></term>
          <listitem>
            <simpara>Executa testes gráficos no servidor X atual, em vez de em um Xvfb simulado.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-C</option>, <option>--try-checkout</option></term>
          <listitem>
            <simpara>Se a compilação falhar, e se houver suporte pelo sistema de controle de versão, força um checkout e executa <command>autogen.sh</command> antes de tentar compilar novamente.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-N</option>, <option>--no-poison</option></term>
          <listitem>
            <simpara>Se uma ou mais dependências de um módulo falhar, esta opção força o JHBuild a tentar compilar o módulo mesmo assim.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-f</option>, <option>--force</option></term>
          <listitem>
            <simpara>Compila os módulos mesmo se a política define que não é necessário.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--build-optional-modules</option></term>
          <listitem>
            <simpara>Módulos listados como dependências opcionais, podem não ser necessários para compilação do módulo. Esta opção força o JHBuild a compilar essas dependências opcionais.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--min-age</option>=<replaceable>tempo</replaceable></term>
          <listitem>
            <simpara>Pula os módulos instalados mais recentemente do que o tempo especificado. O formato do <replaceable>tempo</replaceable> é um número seguido por uma unidade. Há suporte às seguintes unidades: segundos (s), minutos (m), horas (h) e dias (d). Por exemplo, <option>--min-age=2h</option> vai ignorar módulos compilados a duas horas atrás.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--nodeps</option></term>
          <listitem>
            <simpara>Ignora dependências do sistema em falta. Para ignorar uma única dependência do sistema, adicione o 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>O comando <command>make</command> é para desenvolvimento ativo em um módulo em particular. Ele requer que o diretório atual seja um checkout do código fonte e não 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>As opções são as mesmas disponíveis para o comando <link linkend="command-reference-build"><command>buildone</command></link>.</para>
    </section>

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

      <para>O comando <command>buildone</command> é similar ao <command>build</command>, mas ele não compila os módulos dependentes. Isso é útil para recompilar um ou mais 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>data</replaceable></arg> <arg>--no-xvfb</arg> <arg>--force</arg> <arg>--min-age=<replaceable>tempo</replaceable></arg> <arg>--nodeps</arg> <arg choice="plain" rep="repeat">módulo</arg></cmdsynopsis>

      <para>As opções <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> e <option>--nodeps</option> são processadas a cada execução do comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <para>Pelo menos um módulo deve estar listado na linha de comando.</para>
    </section>

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

      <para>O  <command>checkbranches</command> verifica se os ramos (branches) dos módulos estão definidos corretamente no sistema de controle de versão e se estão consistentes com a coleção de módulos.</para>

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

      <variablelist>
        <varlistentry>
          <term><option>--branch</option>=<replaceable>ramo</replaceable>, <option>-b</option> <replaceable>ramo</replaceable></term>
          <listitem>
            <simpara>O ramo a ser verificado.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

<screen><prompt>$</prompt> <userinput>jhbuild -m gnome-2.20 checkbranches</userinput>
libgnomecanvas não tem a definição do ramo gnome-2-20
<prompt>$</prompt></screen>
    </section>

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

      <para>O comando <command>clean</command> limpa os diretórios de compilação de um ou mais 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>Se nenhum nome de módulo for fornecido na linha de comando, a lista de <link linkend="cfg-modules">módulos</link> do arquivo de configuração será usada.</para>

      <para>Veja a documentação do comando <link linkend="command-reference-build"><command>build</command></link> para uma descrição das opções disponíveis.</para>
    </section>

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

      <para>O comando <command>dot</command> gera um arquivo descrevendo o gráfico direcionado criado pelas dependências entre uma coleção de módulos. Este arquivo pode ser, então, processado usando o software <ulink url="http://www.graphviz.org/">GraphViz</ulink> para produzir um diagrama.</para>

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

      <para>Se nenhum nome de módulo for fornecido na linha de comando, a lista de <link linkend="cfg-modules">módulos</link> do arquivo de configuração será usada.</para>

      <para>A opção <option>--soft-deps</option> adiciona linhas pontilhadas dos módulos para as suas dependências. A opção <option>--clusters</option> agrupa módulos de <link linkend="moduleset-syntax-defs-metamodule">metamodules</link>.</para>

      <para>A saída do comando dot pode ser direcionada para o utilitário dot para gerar um arquivo PostScript:</para>

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

      <para>Ou uma imagem PNG:</para>

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

      <figure id="sample-dot-output">
        <title>Exemplo de saída do dot do JHBuild</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>O comando <command>gui</command> inicia uma interface gráfica do JHBuild que pode ser usada para selecionar módulos para compilar e alterar algumas opções.</para>

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

      <para>A interface gráfica é renderizada usando GTK, de forma que bibliotecas extras de suporte são necessárias.</para>
    </section>

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

      <para>O comando <command>info</command> exibe informações sobre um ou mais módulos.</para>

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

      <para>O comando exibe o nome do módulo, tipo, dependências, pacotes dependentes, o diretório de fontes e o horário em que foi instalado pela última vez com JHBuild. Se disponível, informações específicas do tipo do módulo, como o repositório de sistema de controle de versão (VCS) ou a URL de download, também serão exibidas.</para>

      <para>Se nenhum módulo for especificado, o comando vai exibir informações sobre todos os módulos definidos na coleção de comandos.</para>

      <para>Se a opção <option>--installed</option> for especificada, a saída será filtrada para incluir apenas pacotes instalados. A saída resultante contém apenas módulos que foram realmente compilados e instalados pelo jhbuild. A saída não inclui dependências do sistema.</para>

      <note>
        <simpara>Se a opção <option>--installed</option> for especificada junto com um ou mais nomes de módulos, então apenas os módulos instalados (não incluindo dependências do sistema) são mostradas. Se pelo menos um módulo não estiver instalado, então o comando vai sair com um valor de retorno de 1.</simpara>
      </note>
    </section>

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

      <para>O comando <command>list</command> exibe a lista expandida de módulos que o comando <command>build</command> compilaria.</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>tags</replaceable></arg> <arg>--ignore-suggests</arg> <arg>--list-optional-modules</arg> <arg rep="repeat">módulos</arg></cmdsynopsis>

      <para>Se nenhum nome de módulo for fornecido na linha de comando, a lista de <link linkend="cfg-modules">módulos</link> do arquivo de configuração será usada.</para>

      <para>As opções <option>--skip</option>, <option>--start-at</option>, <option>--tags</option> e <option>--ignore-suggests</option> são processadas a cada execução do comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>-a</option>, <option>--all-modules</option></term>
          <listitem>
            <simpara>Lista todos os módulos da coleção de módulos independentemente das dependências de compilação.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-r</option>, <option>--show-revision</option></term>
          <listitem>
            <simpara>Se um módulo está definido em um ramo, mostra o nome do ramo com o nome do módulo.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--list-optional-modules</option></term>
          <listitem>
            <simpara>Esta opção força o JHBuild a lista todas as dependências opcionais.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>O comando <command>rdepends</command> exibe as dependências inversas de um módulo.</para>

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

      <variablelist>
        <varlistentry>
          <term><option>--dependencies</option></term>
          <listitem>
            <simpara>Mostra um caminho de dependência ao lado dos módulos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--direct</option></term>
          <listitem>
            <simpara>Limita a exibição a módulos dependendo diretamente do módulo especificado.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>O comando <command>run</command> executa o comando especificado usando o mesmo ambiente que o JHBuild usa ao compilar 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>Se usando o JHBuild para compilar o GNOME, este comando pode ser útil em scripts de inicialização do X.</para>

      <variablelist>
        <varlistentry>
          <term><option>--in-builddir</option>=<replaceable>módulo</replaceable></term>
          <listitem>
            <simpara>Executa o comando no diretório de compilação do módulo especificado.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

      <variablelist>
        <varlistentry>
          <term><option>--in-checkoutdir</option>=<replaceable>módulo</replaceable></term>
          <listitem>
            <simpara>Executa o comando no diretório fonte do módulo especificado.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>O comando <command>sanitycheck</command> realiza as verificações para confirmar que o ambiente de compilação está correto.</para>

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

      <para>Algumas verificações incluem:</para>

      <itemizedlist>
        <listitem>
          <simpara>Os prefixos de checkout e instalação têm permissão de escrita.</simpara>
        </listitem>
        <listitem>
          <simpara>As ferramentas necessárias para compilação estão instaladas.</simpara>
        </listitem>
        <listitem>
          <simpara>Algumas macros comumente usadas estão disponíveis nos caminhos de pesquisa dos comandos de <command>aclocal</command> associados com as várias versões do <command>automake</command>.</simpara>
        </listitem>
        <listitem>
          <simpara>O catálogo XML contém o DocBook DTD e as folhas de estilos.</simpara>
        </listitem>
      </itemizedlist>
    </section>

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

      <para>O comando <command>shell</command> inicia o shell do usuário com o mesmo ambiente que o JHBuild usa ao compilar módulos.</para>

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

      <para>O comando é equivalente a:</para>

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

      <para>A variável de ambiente <envar>UNDER_JHBUILD</envar> será definida para “true” quando este shell estiver ativo. Você pode usar a presença desta variável para personalizar o prompt do shell para indicar que você realmente está dentro de um shell controlado pelo jhbuild. Por exemplo, você pode querer colocar isso em seu <filename>.bashrc</filename>:</para>

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

      <para>Isso vai fazer com que o shell do bash exiba <literal>[jhbuild]</literal> antes do seu prompt normal, deixando mais fácil ver qual shell está em baixo de um ambiente do jhbuild.</para>
    </section>

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

      <para>O comando <command>sysdeps</command> exibe:</para>

      <orderedlist>
        <listitem>
          <simpara>uma lista de pacotes de sistemas instalados que serão usados durante a compilação. JHBuild não vai compilar esses módulos e, em vez disso, opta por usar o pacote do sistema.</simpara>
        </listitem>
        <listitem>
          <simpara>uma lista de pacotes necessários. Para começar uma compilação, os pacotes devem ser fornecidos pelo seus sistema.</simpara>
        </listitem>
        <listitem>
          <simpara>uma lista de pacotes opcionais. O pacote de sistema correspondente não foi encontrado ou é muito antigo. JHBuild vai compilar o módulo. Pacotes opcionais não serão exibidos se <link linkend="cfg-partial-build"><varname>partial_build</varname></link> for <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 opção instala pacotes de sistema que são dependências da coleção de módulos. Este método de instalação depende de sua distribuição. Pacotes de sistema são instalados usando <application>PackageKit</application>, se disponível. Para distribuições usando <application>APT</application> como o <systemitem class="osname">Debian</systemitem> e <systemitem class="osname">Ubuntu</systemitem>, esta opção requer <application>apt-file</application> para ser instalada.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

      <example>
        <title>exemplos de <command>sysdeps</command></title>
<screen><prompt>$</prompt> <userinput>jhbuild sysdeps</userinput>
Pacotes do sistema instalados que são novos o suficiente:
  speex (speex.pc requer=1.2rc1, instalado=1.2rc1)
  lcms2 (lcms2.pc requer=2.2, instalado=2.2)
...
Pacotes necessários:
  Pacotes do sistema instalados que são antigos demais:
    (nenhum)
  Nenhum pacote de sistema correspondente instalado:
    zlib (zlib.pc requer=1.2)
Pacotes opcionais: (JHBuild vai compilar os pacotes em falta)
  Pacotes do sistema instalados que são antigos demais:
    WebKit (webkitgtk-3.0.pc requer=1.5.1, instalado=1.4.0)
    ...
  Nenhum pacote de sistema correspondente instalado:
    pulseaudio (libpulse.pc requer=2.0)
    ...</screen>
      </example>
    </section>

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

      <para>O comando <command>tinderbox</command> é similar ao <command>build</command>, mas escreve todas as saídas do terminal em arquivos HTML para publicação em um site. Isso pode ser usado para instalar sistemas similares ao Tinderbox do Mozilla ou o Buildd do Debian.</para>

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

      <para>As opções <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> e <option>--nodeps</option> são processadas a cada execução do comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>-o</option>, <option>--output</option>=<replaceable>diretório</replaceable></term>
          <listitem>
            <simpara>O diretório no qual serão escritos os arquivos HTML. JHBuild vai criar um índice (<filename>index.html</filename>) e um arquivo HTML para cada módulo.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>O comando <command>uninstall</command> desinstala um ou mais 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>O comando <command>update</command> é similar ao <command>build</command>, mas realiza apenas os estágios de baixar e atualizar para módulos sem compilá-los.</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>tags</replaceable></arg> <arg>--ignore-suggests</arg> <arg>-D <replaceable>data</replaceable></arg> <arg rep="repeat">módulo</arg></cmdsynopsis>

      <para>As opções <option>--skip</option>, <option>--start-at</option>, <option>--tags</option>, <option>--ignore-suggests</option> e <option>-D</option> são processadas a cada execução do comando <link linkend="command-reference-build"><command>build</command></link>.</para>
    </section>

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

      <para>O comando <command>updateone</command> é similar ao <command>update</command>, mas ele não atualiza os módulos dependentes. É útil para atualizar um ou mais módulos.</para>

      <cmdsynopsis><command>jhbuild updateone</command> <arg>-D <replaceable>data</replaceable></arg> <arg choice="plain" rep="repeat">módulo</arg></cmdsynopsis>

      <para>A opção <option>-D</option> é processada a cada execução do comando <link linkend="command-reference-build"><command>build</command></link>.</para>

      <para>Pelo menos um módulo deve estar listado na linha de comando.</para>
    </section>
  </section>

  <section id="config-reference">
    <title>Referência de arquivo de configuração</title>

    <para>O arquivo <filename>~/.config/jhbuildrc</filename> usa uma sintaxe padrão do Python. O arquivo é executado e as variáveis resultantes definidas no espaço de nomes são usadas para controlar como o JHBuild age. Um conjunto de valores padrões são inseridos no espaço de nomes antes de executar o arquivo do usuário.</para>

    <para>Variáveis de configuração em Boolean são definas usando uma sintaxe como demonstrado no exemplo a seguir:</para>

<programlisting>use_local_modulesets = True</programlisting>

    <para>Variáveis de configuração em string são definidas usando uma sintaxe como demonstrado no exemplo a seguir:</para>

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

    <para>Variáveis de configuração em lista são definidas usando uma sintaxe como demonstrada no exemplo a seguir:</para>

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

    <para>Variáveis de configuração de dicionário são definidas usando uma sintaxe como demonstrada no exemplo a seguir:</para>

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

    <section id="config-reference-variables">
      <title>Variáveis de configuração</title>

      <variablelist>
<?dbhtml list-presentation="table"?>
        <varlistentry id="cfg-alwaysautogen">
          <term><varname>alwaysautogen</varname></term>
          <listitem>
            <simpara>Um valor em boolean que, se definida como <constant>True</constant>, sempre executa <command>autogen.sh</command>. Este comando é equivalente a passar a opção <option>--autogen</option> para o JHBuild. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-autogenargs">
          <term><varname>autogenargs</varname></term>
          <listitem>
            <simpara>Uma string contendo argumentos passados para o script <command>autogen.sh</command> de todos os módulos. Pode ser sobrescrita por módulos em particular, usando o dicionário <varname>module_autogenargs</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-branches">
          <term><varname>branches</varname></term>
          <listitem>
            <simpara>Um dicionário especificando qual ramo deve ser usado para módulos específicos. Isso é útil se você está fazendo algumas alterações em um ramo de um módulo e deseja JHBuild compilar este ramo em vez daquele listado na coleção de módulos.</simpara>

            <simpara>A definição de ramos depende do sistema de controle de versão (VCS) do módulo:</simpara>

            <itemizedlist>
              <listitem>
                <simpara>CVS: revisão. Ex.: <literal>'BRANCH-PROJECT-0_8'</literal></simpara>
              </listitem>
              <listitem>
                <simpara>Bazaar: URI do ramo do módulo. Ex.: <literal>'http://bzr.exemplo.net/projeto/gnome-2-28'</literal></simpara>
              </listitem>
              <listitem>
                <simpara>Git: tupla, com a primeira parte sendo um repositório opcional (ou o valor “None”) e a segunda parte do nome do ramo. Ex.: <literal>('git://git.exemplo.net/projeto', 'gnome-2-28')</literal></simpara>

                <example>
                  <title>Exemplo simples</title>
<programlisting>branches['nome-do-módulo'] = (None, 'nome-do-ramo')</programlisting>
                </example>
              </listitem>
              <listitem>
                <simpara>Subversion: URI do ramo do módulo. Ex.: <literal>'svn://svn.exemplo.net/projeto/gnome-2-28'</literal></simpara>
              </listitem>
            </itemizedlist>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-builddir-pattern">
          <term><varname>builddir_pattern</varname></term>
          <listitem>
            <simpara>Um padrão de formatação de estilo do <function>printf</function> usado para gerar nomes de diretórios de compilação. Isso é usado apenas ao usar árvores de fontes e compilação separados. O <literal>%s</literal> na string de formatação será substituído com <varname>checkoutdir</varname>. Padrão é <literal>'%s'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-buildroot">
          <term><varname>buildroot</varname></term>
          <listitem>
            <simpara>Uma string especificando o diretório pai para colocar as árvores de compilação. Padrão é <filename>~/.cache/jhbuild/build</filename>. Definir esse valor para <constant>None</constant> faz com que as compilações sejam realizadas dentro das árvores de fontes.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-buildscript">
          <term><varname>buildscript</varname></term>
          <listitem>
            <simpara>Uma string especificando qual buildscript deve ser usado. A configuração recomendada é a padrão, <literal>terminal</literal>. Em particular, não defina para <literal>gtk</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-build-policy">
          <term><varname>build_policy</varname></term>
          <listitem>
            <simpara>Uma string especificando quais módulos devem ser compilados. As três opções possíveis são: <literal>all</literal> para compilar todos os módulos solicitados; <literal>updated</literal> para compilar apenas os módulos que você alterou; ou <literal>updated-deps</literal> para compilar módulos que você alterou ou que possuem dependências que foram alteradas. Padrão é <literal>updated-deps</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-checkoutroot">
          <term><varname>checkoutroot</varname></term>
          <listitem>
            <simpara>Uma string especificando o diretório para o qual deve-se descompilar árvores de fontes. A menos que <varname>buildroot</varname> esteja especificado, as compilações ocorrerão neste diretório também. Padrão é <filename>~/checkout/gnome</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-checkout-mode">
          <term><varname>checkout_mode</varname></term>
          <listitem>
            <simpara>Uma string especificando como o checkout é realizado para diretórios em controle de versão. Padrão é <literal>update</literal>. Isso pode ser definido por módulo usando <varname>module_checkout_mode</varname>. Possíveis valores são <literal>update</literal> (atualiza diretório de checkout), <literal>clobber</literal> (limpa o diretório antes de buscar os fontes), <literal>export</literal> (limpa o diretório e, então, cria uma cópia sem versão dos fontes) e <literal>copy</literal> (realiza checkout em um diretório diferente daquele que será compilado).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-copy-dir">
          <term><varname>copy_dir</varname></term>
          <listitem>
            <simpara>Uma string especificando o diretório para onde será copiado, se a cópia <link linkend="cfg-checkout-mode"> <varname>checkout_mode</varname></link> estiver em uso. Padrão é o diretório de checkout.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-cvs-program">
          <term><varname>cvs_program</varname></term>
          <listitem>
            <simpara>Uma string especificando qual programa deve ser usado para dar suporte a CVS. Pode ser <literal>git-cvsimport</literal> ou <literal>cvs</literal>. Padrão é <literal>cvs</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-disable-Werror">
          <term><varname>disable_Werror</varname></term>
          <listitem>
            <simpara>Um valor booleano (padrão <literal>True</literal>) que controla se <literal>--disable-Werror</literal> vai ser passado para as compilações de automake. Muitos pacotes usam esta sinalização como uma forma de desabilitar aviso do compilador sejam fatais (encerra compilação). O valor de <literal>True</literal> está selecionado como um padrão razoável para aqueles usando jhbuild com a finalidade de obter uma versão atualizada de pacotes de software sem ser atrasados por falhas na compilação de módulos de outras pessoas. Configurar este valor para <literal>False</literal> pode fazer sentido para aqueles usando jhbuild como parte de um sistema de teste ou integração contínua.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-dvcs-mirror-dir">
          <term><varname>dvcs_mirror_dir</varname></term>
          <listitem>
            <simpara>Uma string especificando um diretório de espelho local. JHBuild vai criar espelhos locais de repositórios no diretório especificado. Os espelhos podem ser compartilhados por grupos de múltiplos diretórios, economizando espaço e tempo, porque hard-links serão usados por clones locais. Os comandos <command>update</command> e <command>updateone</command> vão criar os espelhos e obter novos commits dos repositórios online. Esta opção tem suporte apenas em repositórios Git e Bazaar.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="exit-on-error">
          <term><varname>exit_on_error</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se sair imediatamente quando um módulo falhar na compilação. Isso é útil principalmente no modo não interativo, de forma a evitar que módulos adicionais sejam compilados após um falhar. Definir isso como <constant>True</constant> é equivalente a passar a opção <option>--exit-on-error</option>. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-extra-prefixes">
          <term><varname>extra_prefixes</varname></term>
          <listitem>
            <simpara>Uma lista de strings especificando, por ordem de precedência, a lista de prefixos extras. JHBuild define muitas variáveis de ambiente (tais como <envar>LD_LIBRARY_PATH</envar>, <envar>PKG_CONFIG_PATH</envar> e <envar>XDG_DATA_DIRS</envar>) baseadas na variável <varname>prefix</varname>. Adicionar diretórios a <varname>extra_prefixes</varname> vai resultar em esses prefixos serem incluídos também, em uma precedência menor do que o <varname>prefix</varname> do JHBuild, mas em uma precedência mais alta do que os diretórios do sistema. Essa variável está vazia por padrão, exceto em sistemas que instalam softwares em <filename>/usr/local</filename>, caso em que ela contém esse diretório.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-help-website">
          <term><varname>help_website</varname></term>
          <listitem>
            <simpara>Uma tupla especificando o nome do site e URL de ajuda. O site é exibido no html de tinderbox para módulos que falharem. <varname>%(module)s</varname> na URL será substituído com o nome do módulo. Para desabilitar, defina <varname>help_website</varname> para <literal>None</literal>. Padrão é <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>Uma string especificando um programa a ser usado como substituto para <literal>/usr/bin/install</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-ignore-suggests">
          <term><varname>ignore_suggests</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se ignorar dependências ao se calcular a árvore de dependência. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-interact">
          <term><varname>interact</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se interagir com o usuário. Definindo este valor para <constant>False</constant> é equivalente a passar a opção <option>--no-interact</option>. Padrão é <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makeargs">
          <term><varname>makeargs</varname></term>
          <listitem>
            <simpara>Um texto listando argumentos adicionais a serem passados para o <command>make</command>. JHBuild vai anexar automaticamente a opção de execução paralela (<option>-j</option>) baseada nos núcleos de CPU disponíveis. Padrão é <literal>""</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makecheck">
          <term><varname>makecheck</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se executar <command>make check</command> após <command>make</command>. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makecheck-advistory">
          <term><varname>makecheck_advisory</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se as falhas ao executar <command>make check</command> deveriam ser avisos e não causar uma falha de compilação. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makeclean">
          <term><varname>makeclean</varname></term>
          <listitem>
            <simpara>Um valor boolean especificando se deve-se executar <command>make clean</command> antes <command>make</command>. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makedist">
          <term><varname>makedist</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se executar <command>make dist</command> após <command>make</command>. Padrão é <constant>False</constant>. Esta configuração é equivalente a passar a opção <option>--dist</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makedistcheck">
          <term><varname>makedistcheck</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se executar <command>make distcheck</command> após <command>make</command>. Padrão é <constant>False</constant>. Esta configuração é equivalente a passar  a opção <option>--distcheck</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-autogenargs">
          <term><varname>module_autogenargs</varname></term>
          <listitem>
            <simpara>Um dicionário mapeando os nomes de módulos em strings especificando os argumentos a serem passados para o <command>autogen.sh</command>. A configuração em <varname>module_autogenargs</varname> é usada, em vez da configuração global <varname>autogenargs</varname>. Se um módulo particular não está listado no diretório, a global <varname>autogenargs</varname> será usada.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-checkout-mode">
          <term><varname>module_checkout_mode</varname></term>
          <listitem>
            <simpara>Um dicionário especificando quais modos de checkout devem ser usados para os módulos. Isso sobrescreve a configuração global <varname>checkout_mode</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-makeargs">
          <term><varname>module_makeargs</varname></term>
          <listitem>
            <simpara>Um dicionário mapeando os nomes de módulos em strings especificando os argumentos a serem passados para <command>make</command>. A configuração em <varname>module_makeargs</varname> substitui o valor de <varname>makeargs</varname>. Se um módulo em particular não está listado no dicionário, a global <varname>makeargs</varname> será usada.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-makecheck">
          <term><varname>module_makecheck</varname></term>
          <listitem>
            <simpara>Um dicionário mapeando os nomes de módulos em valores boolean especificando se deve-se executar <command>make check</command> após <command>make</command>. A configuração em <varname>module_makecheck</varname> substitui o valor de <varname>makecheck</varname>. Se um módulo em particular não estiver listado no dicionário, a globa <varname>makecheck</varname> será usada.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-nopoison">
          <term><varname>module_nopoison</varname></term>
          <listitem>
            <simpara>Um dicionário mapeando os nomes de módulos em valores boolean. Se um módulo estiver definido como <constant>True</constant>, JHBuild vai tentar compilar módulos dependentes mesmo se o módulo especificado falhar. A configuração em <varname>module_nopoison</varname> substitui o valor de <varname>nopoison</varname>. Se um módulo em particular não estiver listado no dicionário, a global <varname>nopoison</varname> será usada.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-extra-env">
          <term><varname>module_extra_env</varname></term>
          <listitem>
            <simpara>Um dicionário mapeando os nomes de módulos em dicionários com variáveis de ambiente extras a serem passadas ao executar comandos do módulo.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-static-analyzer">
          <term><varname>module_static_analyzer</varname></term>
          <listitem>
            <simpara>Dicionário mapeando nomes de módulos para valores booleanos indicando se a análise estática deveria ser realizada enquanto compila aquele módulo. Isso permite que a opção de configuração global <varname>static_analyzer</varname> seja sobrescrita.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-modules">
          <term><varname>modules</varname></term>
          <listitem>
            <simpara>Uma lista de textos especificando módulos para compilar. A lista de módulos realmente compilada será expandida recursivamente para incluir todas as dependências, a menos que o comando <link linkend="command-reference-buildone"> <command>buildone</command></link> seja usado. Padrão é <literal>['meta-gnome-desktop']</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-moduleset">
          <term><varname>moduleset</varname></term>
          <listitem>
            <simpara>Um texto ou uma lista de textos especificando os nomes das coleções de módulos a serem usados. Pode ser o nome do arquivo de uma coleção de módulos inclusa no JHBuild (excluindo o caminho e extensão) ou uma URL de HTTP completa para uma coleção de módulos gerenciada externamente. Coleções de módulos de URL de HTTP são mantidas no cache localmente. Se um módulo com o mesmo nome estiver presente em mais de uma coleção de módulos, a última coleção listada terá prioridade. As coleções de módulos fornecidas com o JHBuild são atualizadas para corresponder à versão de desenvolvimento atual do GNOME.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-modulesets-dir">
          <term><varname>modulesets_dir</varname></term>
          <listitem>
            <simpara>Uma string especificando o diretório contendo as coleções de módulos a serem usadas. Padrão é o diretório <filename>modulesets/</filename> nos fontes do JHBuild.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nice-build">
          <term><varname>nice_build</varname></term>
          <listitem>
            <simpara>Executa compilações sob a prioridade <constant>SCHED_IDLE</constant> no Linux, <command>nice</command> em outros Unix. Isso pode melhorar drasticamente a interatividade de computador para compilações paralelas enquanto se tem apenas um impacto insignificante no rendimento da compilação.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nobuild">
          <term><varname>nobuild</varname></term>
          <listitem>
            <simpara>Um valor em boolean, se definido como <constant>True</constant>, o JHBuild não vai compilar módulos, e sim apenas baixar e desempacotar os fontes. O valor padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nonetwork">
          <term><varname>nonetwork</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se acessar a rede. Isso afeta a obtenção ou atualização de módulos de CVS, download de tarballs e atualização de coleções de módulos. Definir isso como <constant>True</constant> é equivalente a passar a opção <option>--no-network</option>. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nonotify">
          <term><varname>nonotify</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se emitir notificações usando o daemon de notificação. Se definido como <constant>False</constant>, notificações são emitidas. Padrão é <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nopoison">
          <term><varname>nopoison</varname></term>
          <listitem>
            <simpara>Um valor em boolean, se definido como <constant>True</constant>, JHBuild tenta compilar módulos mesmo se uma ou mais dependências do módulo não compilarem com sucesso. Esta opção é equivalente ao argumento <option>--no-poison</option>. O valor padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-notrayicon">
          <term><varname>notrayicon</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se mostrar um ícone na área de notificação usando o Zenity. Se definido como <constant>False</constant>, um ícone é mostrado. Padrão é <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-noxvfb">
          <term><varname>noxvfb</varname></term>
          <listitem>
            <simpara>Um valor em boolean, se definido como <constant>True</constant>, JHBuild vai executar quaisquer testes gráficos no servidor X real, em vez de usar <command>Xvfb</command>. Esta opção é equivalente a passar <option>--no-xvfb</option>. O valor padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-partial-build">
          <term><varname>partial_build</varname></term>
          <listitem>
            <simpara>Um valor em boolean, se definido como <constant>True</constant>, JHBuild não vai compilar módulos de dependências se os pacotes de sistema correspondentes estiverem instalados em uma versão suficiente. Padrão é <constant>True</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-prefix">
          <term><varname>prefix</varname></term>
          <listitem>
            <simpara>Um texto especificando o prefixo no qual serão instalados os módulos. <varname>prefix</varname> deve ser um caminho absoluto. Deve haver permissão de escrita para este diretório. Padrão é <literal>'~/jhbuild/install/'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-pretty-print">
          <term><varname>pretty_print</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se embelezar o formato da saída do subprocesso. Apenas saídas CVS têm suporte a embelezamento da saída. Desabilite se isso causar problemas. Padrão é <literal>True</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-print-command-pattern">
          <term><varname>print_command_pattern</varname></term>
          <listitem>
            <simpara>Uma string exibida antes do JHBuild executar um comando. <varname>%(command)s</varname> na string vai ser substituído com o comando a ser executado. <varname>%(cwd)s</varname> na string será substituída com o diretório de trabalho atual. Padrão é <literal>'%(command)s'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-progress-bar">
          <term><varname>progress_bar</varname></term>
          <listitem>
            <simpara>Um valor em boolean especificando se deve-se exibir uma barra de progresso durante o <link linkend="cfg-quiet-mode">quiet_mode</link>. Padrão é <literal>True</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-quiet-mode">
          <term><varname>quiet_mode</varname></term>
          <listitem>
            <simpara>Um valor em boolean, se definido como <constant>True</constant>, desabilita a saída (mensagens) dos comandos em execução. Padrão é <literal>False</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-repos">
          <term><varname>repos</varname></term>
          <listitem>
            <simpara>Um dicionário especificando uma localização alternativa do repositório para um repositório em particular. Esta variável de configuração é útil para desenvolvedor de módulos. Por padrão, JHBuild vai baixar o código dos repositórios usando um local de repositório anônimo. As chaves de dicionário são nomes curtos de repositórios e os nomes são textos com a localização alternativa do repositório. Por exemplo:</simpara>

<programlisting>repos['git.gnome.org'] = 'ssh://usuário@git.gnome.org/git/'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-skip">
          <term><varname>skip</varname></term>
          <listitem>
            <simpara>Uma lista de módulos para pular. Esta opção de linha de comando <option>--skip</option> estende a lista. Esta lista está vazia, por padrão. Se a lista contém um valor especial <literal>"*"</literal>, JHBuild vai pular todos os módulos não listados explicitamente na variável <varname>modules</varname>. Isso pode ser útil se você deseja compilar módulos sem suas dependências implícitas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer">
          <term><varname>static_analyzer</varname></term>
          <listitem>
            <simpara>Um valor booleano, se definido como <constant>True</constant>, executa uma ferramenta de análise estática em cada módulo como está sendo compilado. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer-outputdir">
          <term><varname>static_analyzer_outputdir</varname></term>
          <listitem>
            <simpara>Diretório raiz abaixo no qual relatórios de análise estática serão salvos (se <varname>static_analyzer</varname> for <constant>True</constant>). Padrão é <filename>/tmp/jhbuild_static_analyzer</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer-template">
          <term><varname>static_analyzer_template</varname></term>
          <listitem>
            <simpara>Modelo de comando para analisador estático. Ele possui os parâmetros <varname>outputdir</varname> (o valor da variável de configuração <varname>static_analyzer_outputdir</varname>) e <varname>module</varname> (o nome do módulo sendo compilado atualmente) substituído por um estilo <function>printf</function>. O comando resultante é usado como um prefixo para <command>make</command> ao compilador um módulo. Padrão é <command>scan-build</command>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-sticky-date">
          <term><varname>sticky_date</varname></term>
          <listitem>
            <simpara>Uma string que, se definida e se houver suporte por seu sistema de controle de versão, JHBuild vai atualizar a árvore de fontes na data especificada antes de compilar. Uma data no formato ISO é necessária, ex.: <literal>"<replaceable>yyyy</replaceable>-<replaceable>mm</replaceable>-<replaceable>dd</replaceable>"</literal>. Padrão é <constant>None</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-svn-program">
          <term><varname>svn_program</varname></term>
          <listitem>
            <simpara>Uma string especificando qual programa deve ser usado para ter suporte a subversion. Pode ser <literal>svn</literal>, <literal>git-svn</literal> ou <literal>bzr</literal>. Padrão é <literal>svn</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-system-libdirs">
          <term><varname>system_libdirs</varname></term>
          <listitem>
            <simpara>Uma lista de strings especificando os caminhos das bibliotecas de sistema. Isso é usado ao definir os valores padrão de algumas variáveis de ambiente, tais como <envar>PKG_CONFIG_PATH</envar>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-tarballdir">
          <term><varname>tarballdir</varname></term>
          <listitem>
            <simpara>Uma string que, se definida, faz tarballs serem baixados para o diretório especificado em vez do <varname>checkoutroot</varname>. Isso é útil se você tiver múltiplos ambientes de JHBuild ou regularmente limpa <varname>checkoutroot</varname> e deseja reduzir o uso da conexão com a Internet. O padrão é <literal>'~/cache/jhbuild/downloads'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-tinderbox-outputdir">
          <term><varname>tinderbox_outputdir</varname></term>
          <listitem>
            <simpara>Uma string especificando o diretório para armazenar a saída de <command>jhbuild tinderbox</command>. Esta string pode ser sobrescrita pela opção <option>--output</option>. Padrão é <constant>None</constant>, de forma que a opção de linha de comando deve ser usada ou esta variável deve estar definida no arquivo de configuração.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-trycheckout">
          <term><varname>trycheckout</varname></term>
          <listitem>
            <simpara>Um valor em boolean, se definido como <constant>True</constant>, JHBuild vai automaticamente tentar resolver falhas 1) executando <command>autogen.sh</command> novamente e 2) baixando uma versão mais nova de um módulo a partir do controle de versão. Esta configuração é equivalente à opção <option>--try-checkout</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-use-local-modulesets">
          <term><varname>use_local_modulesets</varname></term>
          <listitem>
            <simpara>Um valor em boolean que especifica que devem ser usadas coleções de módulos que foram baixados junto com o código fonte do JHBuild; em vez de baixá-los em tempo de execução do sistema de controle de versão do GNOME. Padrão é <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-xvfbargs">
          <term><varname>xvfbargs</varname></term>
          <listitem>
            <simpara>Uma string listando argumentos a serem passados para o <command>Xvfb</command>, se executando testes gráficos.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-conditions">
          <term><varname>conditions</varname></term>
          <listitem>
            <simpara>Uma coleção de condições (textos) que podem influenciar os módulos que são compilados e as opções que são usadas para compilá-los. Você deveria usar <literal>conditions.add()</literal> e <literal>conditions.discard()</literal> para modificar a lista se você quiser fazer alterações.</simpara>
            <simpara>A coleção original de condições é determinado de acordo com o SO e pode ser modificado usando o argumento de linha de comando <option>--conditions=</option>. As alterações feitas por <option>--conditions</option> são visíveis no momento em que jhbuildrc é carregado, de forma que você possa definir outras variáveis com base no valor atual do conjunto, mas <option>--conditions</option> serão aplicadas novamente após qualquer alterações feita por jhbuildrc.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="config-reference-other">
      <title>Outras estruturas do arquivo de configuração</title>

      <para>Além das variáveis, há outras configurações que podem ser definidas no arquivo de configuração:</para>

      <variablelist>
        <varlistentry id="cfg-os-environ">
          <term><varname>os.environ</varname></term>
          <listitem>
            <para>Um dicionário representando o ambiente. Este ambiente é passado para o processo que chama o JHBuild.</para>

            <para>Algumas variáveis de ambiente influenciáveis incluem <envar>CPPFLAGS</envar>, <envar>CFLAGS</envar>, <envar>INSTALL</envar> e <envar>LDFLAGS</envar>. Por exemplo:</para>

<programlisting>os.environ['CFLAGS'] = '-O0 -g'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><function>addpath</function>(<parameter>envvar</parameter>, <parameter>pathname</parameter>)</term>
          <listitem>
            <para>Isso vai adicionar um diretório à variável de ambiente <envar>PATH</envar>. <function>addpath</function> vai lidar corretamente o caso quando a variável de ambiente estiver inicialmente vazia (tendo dois-pontos no começo ou final de uma variável de ambiente pode ter consequências inesperadas).</para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><function>prependpath</function>(<parameter>envvar</parameter>, <parameter>pathname</parameter>)</term>
          <listitem>
            <para>Após o processamento do arquivo de configuração, JHBuild vai alterar alguns caminhos baseados em tais <varname>prefix</varname> (ex.: adicionar <literal>$prefix/bin</literal> ao início de <envar>PATH</envar>).</para>

            <para>A função <function>prependpath</function> funciona como <function>addpath</function>, exceto que a variável de ambiente é modificada após JHBuild ter feito suas alterações no ambiente.</para>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>
  </section>

  <section id="moduleset-syntax">
    <title>Sintaxe de arquivo de coleção de módulos</title>

    <para>JHBuild usa arquivos XML para descrever as dependências entre módulo. Um esquema de RELAX-NG e uma definição de tipo de documento são incluídos ao JHBuild no diretório <filename>modulesets/</filename>. O esquema de RELAX-NG pode ser usado para editar arquivos de coleção de módulos usando <literal>nxml-mode</literal> no Emacs.</para>

    <para>O elemento primário em um arquivo da coleção de módulos é o elemento <sgmltag class="element">moduleset</sgmltag>. Nenhum espaço de nomes XML é usado. Os elementos embaixo deste vem em três tipos: fontes de módulos, declarações de inclusões (include) e definições de módulo.</para>

    <para>O conteúdo no arquivo de coleção de módulos pode ser incluído condicionalmente usando a tag &lt;if&gt; para cobrir o conteúdo condicional. Ele é atualmente possível apenas predicar a inclusão se uma opção de condição em particular estiver definida ou não, usando &lt;if condition-set='cond'&gt; ou &lt;se condition-unset='cond'&gt;. Condições são definidas por padrão com base no SO, mas pode ser influenciado por meio da variável <varname>conditions</varname> em jhbuildrc ou o argumento de linha de comando <command>--conditions=</command>.</para>

    <section id="moduleset-syntax-sources">
      <title>Fontes de módulo</title>

      <para>Em vez de listar a localidade completa de cada módulo, um número de “fontes de módulo” está listado na coleção de módulos e, então, referenciada pelo nome nas definições de módulo. Além de reduzir a quantidade de informação redundante na coleção de módulos, isso deixa mais fácil para o usuário especificar uma fonte alternativa para aqueles módulos (para CVS e Subversion, é comum para desenvolvedores e usuários usarem diferentes métodos de acesso a repositório).</para>

      <para>O elemento <sgmltag class="element">repository</sgmltag> é usado para descrever todos os tipos de repositórios. O elemento <sgmltag class="element">branch</sgmltag> é usado dentro da definição do módulo para especificar configurações adicionais.</para>

<programlisting>
&lt;repository name="<replaceable>nome</replaceable>"
  type="<replaceable>tipo</replaceable>"
  [ default="<replaceable>padrão</replaceable>" ]
  [ password="<replaceable>senha</replaceable>" ]
  [ cvsroot="<replaceable>raiz-cvs</replaceable>" ]
  [ archive="<replaceable>arquivo</replaceable>" ]
  [ href="<replaceable>href</replaceable>" ]
  [ server="<replaceable>servidor</replaceable>" ]
  [ database="<replaceable>banco de dados</replaceable>" ]
  [ defbranch="<replaceable>ramo</replaceable>" ]
  [ trunk-template="<replaceable>modelo-trunk</replaceable>" ]
  [ branches-template="<replaceable>modelo-branches</replaceable>" ]
  [ tags-template="<replaceable>modelo-tags</replaceable>" ]
  [ developer-href-example="<replaceable>exemplo-href-desenvolvedor</replaceable>" ] /&gt;
</programlisting>

      <para>O atributo <sgmltag class="attribute">name</sgmltag> é um identificador único do repositório.</para>

      <para>O atributo <sgmltag class="attribute">default</sgmltag> especifica este repositório no fonte padrão desta coleção de módulos.</para>

      <para>O atributo <sgmltag class="attribute">type</sgmltag> especifica o tipo de repositório. Ele pode ser: <literal>bzr</literal>, <literal>cvs</literal>, <literal>darcs</literal>, <literal>fossil</literal>, <literal>git</literal>, <literal>hg</literal>, <literal>mnt</literal>, <literal>svn</literal> ou <literal>tarball</literal>. Outros atributos dependem do <sgmltag class="attribute">type</sgmltag>, além do <sgmltag class="element">branch</sgmltag> usado dentro das definições de módulo. Aqueles descritos embaixo das subseções de tipos de repositório.</para>

      <para>O atributo <sgmltag class="attribute">developer-href-example</sgmltag> é usado para especificar o formato da URL do repositório usado por desenvolvedores. Serve apenas como informação.</para>

      <para>O elemento <sgmltag class="element">branch</sgmltag> é usado dentro das definições de módulo.</para>

<programlisting>
&lt;branch
  [ repo="<replaceable>repositório</replaceable>" ]
  [ module="<replaceable>nome-do-módulo</replaceable>" ]
  [ checkoutdir="<replaceable>diretório-de-checkout</replaceable>" ]
  [ revision="<replaceable>revisão</replaceable>" ]
  [ tag="<replaceable>tag</replaceable>" ]
  [ update-new-dirs="<replaceable>atualiza-direstpiruis-novos</replaceable>" ]
  [ override-checkoutdir="<replaceable>sobrescreve-checkoutdir</replaceable>" ]
  [ subdir="<replaceable>subdiretório</replaceable>" ]
  [ branch="<replaceable>ramo</replaceable>" ]
  [ version="<replaceable>versão</replaceable>" ]
  [ size="<replaceable>tamanho</replaceable>" ]
  [ source-subdir="<replaceable>subdiretório-fonte</replaceable>" ]
  [ hash="<replaceable>hash</replaceable>" ]/&gt;
</programlisting>

      <para>Todos os atributos possuem padrões sensíveis e dependem das definições do módulo e repositório. Atributos comuns são descritos aqui.</para>

      <para>O atributo <sgmltag class="attribute">repo</sgmltag> é usado para especificar um nome de repositório não padronizado.</para>

      <para>O atributo <sgmltag class="attribute">module</sgmltag> é usado para especificar um nome de módulo para baixar do repositório. Padrão é a identificação (id) do módulo.</para>

      <para>O atributo <sgmltag class="attribute">checkoutdir</sgmltag> é usado para especificar o nome do diretório no qual será realizado checkout. Padrão é a identificação (id) do módulo.</para>

      <para>Outros atributos são descritos abaixo.</para>

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

        <para>Este tipo de repositório é usado para definir um repositório Bazaar. É recomendado ter Bazaar 1.16 ou outra versão mais nova.</para>

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

        <para>São atributos adicionais: <sgmltag class="attribute">trunk-template</sgmltag> (padrão é <literal>"%(module)s"</literal>) e <sgmltag class="attribute">branches-template</sgmltag> (padrão é <literal>"%(module)s/%(branch)s</literal>"). Estes atributos são usados para especificar modelos para construção de URL. Um elemento <sgmltag class="element">branch</sgmltag> nas definições do módulo pode especificar atributos <sgmltag class="attribute">branch</sgmltag> e <sgmltag class="attribute">user</sgmltag>. Estes valores serão substituídos nos modelos. Se um deles for definido,  <sgmltag class="attribute">branches-template</sgmltag> é usado. Do contrário, <sgmltag class="attribute">trunk-template</sgmltag> é usado. Desta forma, você pode sobrescrever um repositório para compilar módulos do seu ramo pessoal ou compilar muitos módulos de um repositório com uma disposição não padronizada.</para>

        <para>Um elemento <sgmltag class="element">branch</sgmltag> adicional aceita um atributo <sgmltag class="attribute">revspec</sgmltag> para ancorar em uma revisão em particular. Qualquer <literal>bzr revspec</literal> válido é aceito. Por exemplo, use <literal>date:yesterday, -5, tag:0.1</literal> para obter a primeira revisão a partir de ontem, 5 commits atrás da tip ou tag “0.1”. Veja <literal>bzr help revisionspec</literal> para todos os valores possíveis.</para>

        <para>Por exemplo, um repositório com 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>Exemplo de elementos <sgmltag class="element">branch</sgmltag> para o repositório acima:</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>Este tipo de repositório é usado para definir um repositório CVS.</para>

        <para>O atributo <sgmltag class="attribute">password</sgmltag> é usado para especificar a senha do repositório.</para>

        <para>O atributo <sgmltag class="attribute">cvsroot</sgmltag> é usado para especificar a raiz do repositório.</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>São atributos adicionais: <sgmltag class="attribute">revision</sgmltag>, <sgmltag class="attribute">update-new-dirs</sgmltag> e <sgmltag class="attribute">override-checkoutdir</sgmltag>.</para>
      </section>

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

        <para>Este tipo de repositório é usado para definir um repositório 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>Este tipo de repositório é usado para definir um repositório Git.</para>

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

        <para>Ele permite os seguintes atributos no elemento <sgmltag class="element">branch</sgmltag>:</para>

        <para>O atributo <sgmltag class="attribute">revision</sgmltag> é usado para especificar um ramo local ou remoto que pode ser selecionado na fase de atualização. Padrão é “master”. É possível sobrescrever este atributo com a variável de configuração <varname>branches</varname>. A seleção será realizada apenas se o ramo atual estiver seguindo um ramo remoto, para não atrapalhar o seu próprio trabalho.</para>

        <para>O atributo <sgmltag class="attribute">tag</sgmltag> é usado para especificar uma revisão para baixar incondicionalmente na fase de atualização. Ele substitui o 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>ramo-local-ou-remoto</replaceable>"
        tag="<replaceable>tag</replaceable>"/&gt;
        </programlisting>
      </section>

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

        <para>Este tipo de repositório é usado para definir um repositório 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>Este tipo de repositório é usado para definir um repositório Monotone.</para>

        <para>O atributo <sgmltag class="attribute">server</sgmltag> é usado para especificar o servidor do repositório.</para>

        <para>O atributo <sgmltag class="attribute">database</sgmltag> é usado para especificar o banco de dados a ser usado pelo repositório.</para>

        <para>O atributo <sgmltag class="attribute">defbranch</sgmltag> é usado para especificar o ramo do repositório a ser usado.</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>Este tipo de repositório é usado para definir um repositório.</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>Ele permite uma <sgmltag class="attribute">revision</sgmltag> no elemento <sgmltag class="element">branch</sgmltag>. Este atributo define o ramo para fazer checkout ou, se for um número, uma revisão específica para fazer checkout.</para>

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

        <para>É possível especificar uma disposição <literal>svn</literal> diferente usando <sgmltag class="attribute">trunk-template</sgmltag> (padrão é “%(module)s/trunk”), <sgmltag class="attribute">branches-template</sgmltag> (padrão é “%(module)s/branches/%(branch)s”) and <sgmltag class="attribute">tags-template</sgmltag> (padrão é “%(module)s/tags/%(tag)s”)</para>
      </section>

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

        <para>Este tipo de repositório é usado para definir um repositório de sistema falso. Um repositório de sistema é necessário para criar <link linkend="moduleset-syntax-defs-systemmodule"><sgmltag class="element">systemmodules</sgmltag></link>.</para>

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

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

        <para>Este tipo de repositório é usado para definir um repositório de tarball.</para>

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

        <para>Ele permite os seguintes atributos no elemento <sgmltag class="element">branch</sgmltag>:</para>

        <para>O atributo <sgmltag class="attribute">module</sgmltag> especifica o arquivo para baixar e compilar, o atributo <sgmltag class="attribute">version</sgmltag> especifica a versão do módulo.</para>

        <para>Os elementos <sgmltag class="attribute">size</sgmltag> e <sgmltag class="attribute">hash</sgmltag>, assim como o obsoleto <sgmltag class="attribute">md5sum</sgmltag>, são opcionais. Se esses atributos estiverem presentes, eles são usados para verificar se o pacote de fontes foi baixado corretamente.</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>Qualquer número de elementos de <sgmltag class="element">patch</sgmltag> pode ser acrescentado dentro do elemento <sgmltag class="element">branch</sgmltag>. Esses patches são aplicados, em ordem, na árvore de fontes após o desempacotamento. O atributo <sgmltag class="attribute">file</sgmltag> fornece o nome do arquivo de patch e o atributo <sgmltag class="attribute">strip</sgmltag> informa quantos níveis devem ser suprimidos ao aplicar o patch.</para>

        <para>Para coleções de módulos disponibilizados com o JHBuild, os arquivos de patch são buscados no diretório <filename>jhbuild/patches/</filename>; para coleções de módulos relacionados por URI, os arquivos de patch são obtidos no mesmo diretório do arquivo de coleção de módulos ou em seu subdiretório <filename>patches/</filename>. Também é possível que o atributo <sgmltag class="attribute">file</sgmltag> especifique uma URI, caso em que o patch será baixado desta localização.</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>Um elemento <sgmltag class="element">branch</sgmltag> de tarball também pode conter elementos <sgmltag class="element">quilt</sgmltag>, que especificam <sgmltag class="element">branch</sgmltag> aninhados para  importar.</para>
      </section>
    </section>

    <section id="moduleset-syntax-includes">
      <title>Incluindo outras coleções de módulos</title>

      <para>JHBuild permite que uma coleção de módulos inclua os conteúdos de outra por referência usando o elemento <sgmltag class="element">include</sgmltag>.</para>

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

      <para>O <sgmltag class="attribute">href</sgmltag> é uma referência de URI à coleção de módulos a serem incluídos, relativo ao arquivo contendo o elemento <sgmltag class="element">include</sgmltag>.</para>

      <para>Apenas definições de módulos são importadas da coleção de módulos referenciada - fontes de módulos não são. Múltiplos níveis de inclusões são permitidas, mas loops de inclusão não são (não código algum para lidar com loops no presente momento).</para>
    </section>

    <section id="moduleset-syntax-defs">
      <title>Definições de módulo</title>

      <para>Há vários tipos de definições de módulos que podem ser usados em um arquivo de coleção de módulos, e a lista pode ser facilmente estendida. Apenas aqueles mais comuns que são mencionados aqui.</para>

      <para>As definições são basicamente todas compostas de um elemento <sgmltag class="element">branch</sgmltag> descrevendo como obter o módulo e elementos <sgmltag class="element">dependencies</sgmltag>, <sgmltag class="element">suggests</sgmltag> e <sgmltag class="element">after</sgmltag> para declarar as dependências do módulo.</para>

      <para>Quaisquer módulos listados no elemento <sgmltag class="element">dependencies</sgmltag> serão adicionados à lista de módulos de <command>jhbuild build</command>, se eles já não estiverem inclusos, e confirmados de que módulos dependentes serão compilados primeiro.</para>

      <para>Após gerar a lista de módulos, os módulos listados no elemento <sgmltag class="element">suggests</sgmltag> serão usados para posterior organização da lista de módulos (apesar de que ela não vai obter nenhum módulos adicionais). Isso não foi destinado para casos em que um módulo possui uma dependência opcional em outro módulo.</para>

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

        <para>O elemento <sgmltag class="element">autotools</sgmltag> é usado para definir um módulo que é compilado usando o sistema de compilação do GNU Autotools.</para>

<programlisting>
&lt;autotools id="<replaceable>id</replaceable>"
	      [ autogenargs="<replaceable>argumentos-autogen</replaceable>" ]
	      [ makeargs="<replaceable>argumentos-make</replaceable>" ]
	      [ makeinstallargs="<replaceable>argumentos-make-install</replaceable>" ]
	      [ autogen-sh="<replaceable>autogen-sh</replaceable>" ]
	      [ makefile="<replaceable>makefile</replaceable>" ]
	      [ skip-autogen="<replaceable>ignora-autogen</replaceable>" ]
	      [ skip-install="<replaceable>ignora-install</replaceable>" ]
	      [ uninstall-before-install="<replaceable>desinstala-antes-de-instalar</replaceable>" ]
	      [ autogen-template="<replaceable>modelo-de-autogen</replaceable>" ]
	      [ check-target="<replaceable>verifica-alvo</replaceable>" ]
	      [ force-non-srcdir-builds="<replaceable>força-compilações-fora-do-srcdir</replaceable>" ]
	      [ supports-non-srcdir-builds="<replaceable>suporte-a-compilações-fora-do-srcdir</replaceable>" ]&gt;
	      [ supports-unknown-configure-options="<replaceable>suporte-a-opções-desconhecidas-pelo-configure</replaceable>" ]
	      [ supports-static-analyzer="<replaceable>suporte-a-analisador-estático</replaceable>" ]&gt;

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

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;

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

        <para>Os atributos <sgmltag class="attribute">autogenargs</sgmltag>, <sgmltag class="attribute">makeargs</sgmltag> e <sgmltag class="attribute">makeinstallargs</sgmltag> são usados para especificar argumentos adicionais a serem passados para o <command>autogen.sh</command>, <command>make</command> e <command>make install</command>, respectivamente.</para>

        <para>O atributo <sgmltag class="attribute">autogen-sh</sgmltag> especifica o nome do script autogen.sh a ser executado. O valor <literal>autoreconf</literal> pode ser usado se seu módulo não possuir um script <command>autogen.sh</command> equivalente. Nesse caso, JHBuild vai executar <command>autoreconf -fi</command>, seguido pelo <command>configure</command> apropriado. <sgmltag class="attribute">skip-autogen</sgmltag> escolhe executar ou não o autogen.sh, sendo ele um boolean com um valor <literal>never</literal> extra para informar o JHBuild para nunca pular a execução do <command>autogen.sh</command>. <sgmltag class="attribute">skip-install</sgmltag> é um atributo boolean especificando pular ou não o comando <command>make install</command> no módulo. <sgmltag class="attribute">makefile</sgmltag> especifica o nome de arquivo do makefile a ser usado.</para>

	<para>O <sgmltag class="attribute">uninstall-before-install</sgmltag> especifica quaisquer arquivos antigos instalados do módulo que deveriam ser removidos antes de executar a etapa de instalação. Isso pode ser usado para contornar um problema no qual libtool tenta criar um link de uma biblioteca que ele está instalando com outra que ele está instalando, mas, por causa do jhbuild usar DESTDIR, acaba por encontrar a biblioteca antiga instalada. O lado negativo de se especificar isso é que pode causar problemas se o usuário estiver atualmente executando um código que depende dos arquivos instalados do módulo.</para>

        <para>O atributo <sgmltag class="attribute">supports-non-srcdir-builds</sgmltag> é usado para marcar módulos que não podem ser compilados do zero usando um diretório de fontes separados.</para>

        <para>O atributo <sgmltag class="attribute">force-non-srcdir-builds</sgmltag> é usado para marcar módulos que não podem ser compilados do zero usando um diretório de fontes, mas podem ser compilados fora dele.</para>

        <para>O atributo <sgmltag class="attribute">autogen-template</sgmltag> pode ser usado se você precisar um controle melhor da linha de comando do autogen. Ele é uma string  no formato python, que será substituída pelas seguintes variáveis: <varname>srcdir</varname>, <varname>autogen-sh</varname>, <varname>prefix</varname>, <varname>libdir</varname> e <varname>autogenargs</varname>. Por exemplo, aqui está o autogen-template padrão:</para>

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

        <para>O atributo <sgmltag class="attribute">check-target</sgmltag> deve ser especificado (com valor sendo falso) para módulos que não possuem um alvo para <command>make check</command>.</para>

        <para>O atributo <sgmltag class="attribute">supports-static-analyzer</sgmltag> deve ser especificado (com valor sendo falso) para módulos que não possuem suporte a compilação sob uma ferramenta estática, tal como <command>scan-build</command>.</para>

        <para>O atributo <sgmltag class="attribute">supports-unknown-configure-options</sgmltag> é usado para marcar módulos que vão resultar em erro se uma opção desconhecida é passada para <filename>configure</filename>. Opções de configurações globais não serão usada para aquele módulo.</para>
      </section>

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

        <para>O elemento <sgmltag class="element">cmake</sgmltag> é usado para definir um módulo que é compilado usando o sistema de compilação do CMake.</para>

<programlisting>
  &lt;cmake id="<replaceable>nome-do-módulo</replaceable>"
      [ skip-install="<replaceable>instalação-para-ignorar</replaceable>" ]
      [ cmakedir="<replaceable>dir-cmake</replaceable>" ]
      [ force-non-srcdir-builds="<replaceable>força-compilação-não-srcdir</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

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

        <para>O atributo <sgmltag class="attribute">dir-cmake</sgmltag> é usado para especificar o subdiretório no qual o cmake será executado em relação ao srcdir.</para>

        <para>O atributo <sgmltag class="attribute">force-non-srcdir-builds</sgmltag> é usado para marcar módulos que não podem ser compilados do zero usando um diretório de fontes, mas podem ser compilados fora dele.</para>
      </section>

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

        <para>O elemento <sgmltag class="element">meson</sgmltag> é usado para definir um módulo que é compilado usando o sistema de compilação do Meson.</para>

<programlisting>
  &lt;meson id="<replaceable>nome-do-módulo</replaceable>"
            [ skip-install="<replaceable>instalação para ignorar</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/meson&gt;
</programlisting>
      </section>

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

        <para>O elemento <sgmltag class="element">distutils</sgmltag> é usado para definir um módulo que é compilado usando distutils do python.</para>

<programlisting>
&lt;distutils id="<replaceable>nome-do-módulo</replaceable>"
            [ supports-non-srcdir-builds="<replaceable>sim|no</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

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


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

        <para>O elemento <sgmltag class="element">distutils</sgmltag> é usado para definir um módulo que é compilado usando distutils do python.</para>

<programlisting>
&lt;distutils id="<replaceable>nome-do-módulo</replaceable>"
            [ supports-non-srcdir-builds="<replaceable>sim|no</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

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

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

        <para>O elemento <sgmltag class="element">linux</sgmltag> define um módulo usado para compilar um kernel do linux. Além disso, uma configuração de kernel separada pode ser escolhida usando o subelemento <sgmltag class="element">kconfig</sgmltag>.</para>

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

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

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;

  &lt;kconfig [ repo="<replaceable>repositório</replaceable>" ]
	    version="<replaceable>versão</replaceable>"
	    [ module="<replaceable>módulo</replaceable>" ]
	    [ config="<replaceable>configuração</replaceable>" ] /&gt;

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

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

        <para>O elemento <sgmltag class="element">perl</sgmltag> é usado para compilar módulos de perl.</para>

        <para>O atributo <sgmltag class="attribute">makeargs</sgmltag> é usado para especificar argumentos adicionais a ser passados para o <command>make</command>.</para>

<programlisting>
&lt;perl id="<replaceable>nome-do-módulo</replaceable>"
	 [ makeargs="<replaceable>argumentos-make</replaceable>" ]&gt;

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

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;

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

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

        <para>O elemento <sgmltag class="element">systemmodule</sgmltag> é usado para especificar os módulos que deve ser fornecidos pelo sistema. O módulo deveria ser instalado pelo sistema de gerenciamento de pacotes da sua distribuição.</para>

<programlisting>
&lt;systemmodule id="<replaceable>nome-do-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>versão</replaceable>" /&gt;
&lt;/systemmodule&gt;
</programlisting>

        <para>Se o módulo do sistema não fornecer um arquivo de pkg-config,  a tag <sgmltag class="element">systemdependencies</sgmltag> pode ser usada para identificar as dependências. Há suporte a dois valores no atributo <sgmltag class="attribute">type</sgmltag> da tag <sgmltag class="element">dep</sgmltag>:</para>

        <orderedlist>
          <listitem>
            <simpara>Valor <sgmltag class="attvalue">path</sgmltag>. O caminho é pesquisado por um nome de programa correspondente.</simpara>
          </listitem>
          <listitem>
            <simpara>Valor <sgmltag class="attvalue">c_include</sgmltag>. O caminho de include C é pesquisado pelo nome de header correspondente. <sgmltag class="attribute">name</sgmltag> pode incluir um subdiretório. O caminho de pesquisa de includes C podem ser modificados pela configuração <varname>CPPFLAGS</varname> dentro das variáveis de configuração <varname>cflags</varname> ou <link linkend="cfg-module-autogenargs"><varname>module_autogenargs</varname></link>.</simpara>
          </listitem>
        </orderedlist>

<programlisting>
&lt;systemmodule id="<replaceable>nome-do-módulo</replaceable>"&gt;
  &lt;branch repo="<replaceable>sistema</replaceable>" version="<replaceable>versão</replaceable>" /&gt;
  &lt;systemdependencies&gt;
    &lt;dep type="path" name="<replaceable>nome-executável</replaceable>" /&gt;
  &lt;/systemdependencies&gt;
&lt;/systemmodule&gt;

&lt;systemmodule id="<replaceable>nome-do-módulo</replaceable>"&gt;
  &lt;branch repo="<replaceable>sistema</replaceable>" version="<replaceable>versão</replaceable>" /&gt;
  &lt;systemdependencies&gt;
    &lt;dep type="c_include" name="<replaceable>nome-do-header</replaceable>" /&gt;
  &lt;/systemdependencies&gt;
&lt;/systemmodule&gt;
</programlisting>

        <para>Se o módulo do sistema puder ser instalado em diferentes localizações ou instalado com diferentes nomes por diferentes localizações, a tag <sgmltag class="element">altdep</sgmltag> pode ser usada como subelementos da tag <sgmltag class="element">dep</sgmltag> para especificar localizações e nomes alternativos. A tag <sgmltag class="element">altdep</sgmltag> oferece suporte aos mesmo atributos que a tag <sgmltag class="element">dep</sgmltag>.</para>

<programlisting>
&lt;systemmodule id="<replaceable>nome-do-módulo</replaceable>"&gt;
  &lt;branch repo="<replaceable>sistema</replaceable>" version="<replaceable>versão</replaceable>" /&gt;
  &lt;systemdependencies&gt;
    &lt;dep type="path" name="<replaceable>nome-executável</replaceable>" /&gt;
      &lt;altdep type="path" name="<replaceable>nome-executável-alternativo-1</replaceable>" /&gt;
      &lt;altdep type="path" name="<replaceable>nome-executável-alternativo-2</replaceable>" /&gt;
      ...
    &lt;dep&gt;
  &lt;/systemdependencies&gt;
&lt;/systemmodule&gt;

&lt;systemmodule id="<replaceable>nome-do-módulo</replaceable>"&gt;
  &lt;branch repo="<replaceable>sistema</replaceable>" version="<replaceable>versão</replaceable>" /&gt;
  &lt;systemdependencies&gt;
    &lt;dep type="c_include" name="<replaceable>nome-do-header</replaceable>" /&gt;
      &lt;altdep type="c_include" name="<replaceable>nome-do-header-1</replaceable>" /&gt;
      &lt;altdep type="c_include" name="<replaceable>nome-do-header-2</replaceable>" /&gt;
      ...
    &lt;dep&gt;
  &lt;/systemdependencies&gt;
&lt;/systemmodule&gt;
</programlisting>
      </section>

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

        <para>O elemento <sgmltag class="element">waf</sgmltag> é usado para definir um módulo que é compilado usando o sistema de compilação do Waf.</para>

        <para>O atributo <sgmltag class="attribute">waf-command</sgmltag> é usado para especificar o script do comando waf a ser usado. Padrão é <command>waf</command>.</para>

        <para>O atributo <sgmltag class="attribute">python-command</sgmltag> é usado para especificar o executável do Python a ser usado. Padrão é <command>python</command>. Isso é útil para compilar módulos com a versão 3 do Python.</para>

<programlisting>
&lt;waf id="<replaceable>nome-do-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>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/waf&gt;
</programlisting>
      </section>

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

        <para>O elemento <sgmltag class="element">testmodule</sgmltag> é usado para criar um módulo que executa uma suíte de testes usando LDTP ou 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>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
    ...
  &lt;/after&gt;

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

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

        <para>O atributo <sgmltag class="attribute">type</sgmltag> fornece um tipo de testes para ser executado no módulo. “dogtail” usa python para chamar todos os arquivos .py. “ldtp” chama 'ldtprunner run.xml'.</para>

        <para>A menos que a opção de configuração noxvfb esteja definida, um servidor Xvfb começa a executar os testes.</para>
      </section>

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

        <para>O elemento <sgmltag class="element">metamodule</sgmltag> define um módulo que, na verdade, nada faz. O único propósito de um módulo deste tipo é suas dependências.</para>

        <para>Por exemplo, meta-gnome-desktop depende de todos os componentes chave do ambiente GNOME e, portanto, ao dizer ao JHBuild para instalá-lo, na verdade instala o ambiente inteiro.</para>

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

        <para>O atributo <sgmltag class="attribute">id</sgmltag> fornece o nome do módulo. Os elementos filhos são lidados como sendo de <link linkend="moduleset-syntax-defs-autotools"><sgmltag class="element">autotools</sgmltag></link>.</para>
      </section>
    </section>

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

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

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

          <para>O elemento <sgmltag class="element">cvsroot</sgmltag> está agora obsoleto - o elemento <sgmltag class="element">repository</sgmltag> deveria ser usado em seu lugar.</para>

          <para>O elemento <sgmltag class="element">cvsroot</sgmltag> é usado para descrever um repositório CVS.</para>

<programlisting>
  &lt;cvsroot name="<replaceable>nome-raiz</replaceable>"
           [ default="<replaceable>yes|no</replaceable>" ]
           root="<replaceable>cvsroot-anônimo</replaceable>"
           password="<replaceable>senha-anônimo</replaceable>"/&gt;
</programlisting>

          <para>O atributo <sgmltag class="attribute">name</sgmltag> deveria ser um identificador único do repositório CVS.</para>

          <para>O atributo <sgmltag class="attribute">default</sgmltag> informa se este é ou não a fonte padrão do módulo deste arquivo de coleção de módulos.</para>

          <para>O atributo <sgmltag class="attribute">root</sgmltag> lista a raiz CVS usada para um acesso anônimo a este repositório e o atributo <sgmltag class="attribute">password</sgmltag> informa a senha usada para um acesso anônimo.</para>
        </section>

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

          <para>O elemento <sgmltag class="element">svnroot</sgmltag> está agora obsoleto - o elemento <sgmltag class="element">repository</sgmltag> deveria ser usado em seu lugar.</para>

          <para>O elemento <sgmltag class="element">svnroot</sgmltag> é usado para descrever um repositório Subversion.</para>

<programlisting>
  &lt;svnroot name="<replaceable>nome-raiz</replaceable>"
           [ default="<replaceable>yes|no</replaceable>" ]
           href="<replaceable>svnroot-anônimo</replaceable>"/&gt;
</programlisting>

          <para>O atributo <sgmltag class="attribute">name</sgmltag> deveria ser um identificador único do repositório Subversion.</para>

          <para>O atributo <sgmltag class="attribute">default</sgmltag> informa se este é ou não a fonte padrão do módulo deste arquivo de coleção de módulos.</para>

          <para>O atributo <sgmltag class="attribute">href</sgmltag> lista a URL base do repositório. Provavelmente será uma URL de <literal>http</literal>, <literal>https</literal> ou <literal>svn</literal>.</para>
        </section>
      </section>

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

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

        <warning>
          <para>Esta seção descreve elementos obsoletos. Eles podem estar sendo usados em coleções de módulos existentes, mas é aconselhado não mais usá-los.</para>
        </warning>

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

          <important>
            <para>Este elemento obsoleto é apenas uma interface dos tipos de módulo <sgmltag class="element">autotools</sgmltag> e de repositório <sgmltag class="element">tarball</sgmltag>.</para>
          </important>

          <para>O elemento <sgmltag class="element">tarball</sgmltag> é usado para definir um módulo que está para ser compilado a partir de um tarball.</para>

<programlisting>
  &lt;tarball id="<replaceable>nome-do-módulo</replaceable>"
              [ version="<replaceable>versão</replaceable>" ]
              [ checkourdir="<replaceable>diretório-checkout</replaceable>" ]
              [ autogenargs="<replaceable>argumentos-autogen</replaceable>" ]
              [ makeargs="<replaceable>argumentos-make</replaceable>" ]
              [ autogen-sh="<replaceable>autogen-sh</replaceable>" ]
              [ supports-non-srcdir-builds="<replaceable>yes|no</replaceable>" ]&gt;
    &lt;source href="<replaceable>url-fonte</replaceable>"
            [ size="<replaceable>tamanho-fonte</replaceable>" ]
            [ hash="<replaceable>algoritmo-fonte:hash-fonte</replaceable>" ]
            [ md5sum="<replaceable>md5sum-fonte</replaceable>" ]/&gt;
    &lt;patches&gt;
      &lt;patch file="<replaceable>nome-de-arquivo</replaceable>" strip="<replaceable>nível</replaceable>"/&gt;
      ...
    &lt;/patches&gt;
    &lt;dependencies&gt;
      &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
      ...
    &lt;/dependencies&gt;
    &lt;suggests&gt;
      &lt;dep package="<replaceable>nome-do-módulo</replaceable>"/&gt;
      ...
    &lt;/suggests&gt;
  &lt;/tarball&gt;
</programlisting>

          <para>Os atributos <sgmltag class="attribute">id</sgmltag> e <sgmltag class="attribute">version</sgmltag> são usados para identificar o módulo.</para>

          <para>O elemento <sgmltag class="element">source</sgmltag> especifica o arquivo para baixar e compilar. O atributo <sgmltag class="attribute">href</sgmltag> é obrigatório, enquanto os atributos <sgmltag class="attribute">size</sgmltag> e <sgmltag class="attribute">hash</sgmltag>, assim como o obsoleto <sgmltag class="attribute">md5sum</sgmltag>, são opcionais. Se esses últimos dois atributos estiverem presentes, eles são usados para verificar se o pacote de fontes foi baixado corretamente.</para>

          <para>O elemento <sgmltag class="element">patches</sgmltag> é usado para especificar um ou mais patches a serem aplicados na árvore de fontes para aplicar na árvore de fontes após descompactar, o atributo <sgmltag class="attribute">file</sgmltag> fornece o nome de arquivo do patch e o atributo <sgmltag class="attribute">strip</sgmltag> informa quantos níveis devem ser suprimidos ao aplicar o patch.</para>

          <para>Para coleções de módulos disponibilizados com o JHBuild, os arquivos de patch são buscados no diretório <filename>jhbuild/patches/</filename>; para coleções de módulos relacionados por URI, os arquivos de patch são obtidos no mesmo diretório do arquivo de coleção de módulos ou em seu subdiretório <filename>patches/</filename>. Também é possível que o atributo <sgmltag class="attribute">file</sgmltag> especifique uma URI, caso em que o patch será baixado desta localização.</para>

          <para>Os outros atributos e os elementos <sgmltag class="element">dependencies</sgmltag>, <sgmltag class="element">suggests</sgmltag> e <sgmltag class="element">after</sgmltag> são processados como sendo de <link linkend="moduleset-syntax-defs-autotools">autotools</link>.</para>
        </section>
      </section>

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

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