# Manual do JHBuild

James
Henstridge
C.J.
Adams-Collier
Frederic
Peters
David
Turner
2004, 2008
James Henstridge
Manual do JHBuild v0.5
Janeiro de 2008
Manual do JHBuild v0.1
Agosto de 2007

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.

Rafael Fontenelle
rafaelff@gnome.org
2013-2020
Rafael Fontenelle

## Introdução

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

JHBuild foi escrito originalmente para compilar o GNOME, mas ele tem sido estendido para ser usável com outros projetos. Um arquivo de coleção de módulos pode ser hospedado em um servidor web, permitindo regras de compilação independente do projeto do JHBuild.

JHBuild pode compilar módulos de uma variedade de fontes, incluindo repositórios CVS, Subversion, Bazaar, Darcs, Git e Mercurial, 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.

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.

## Primeiros passos

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.

### Instalando JHBuild

JHBuild requer um runtime do Python. Verifique se Python >= 3.5 está instalado.

Uma forma recomendada para baixar JHBuild é por meio do sistema de controle de versão, `git`. 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, `~/jhbuild/checkout`.

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

Isso vai baixar o JHBuild em uma pasta chamada `jhbuild` dentro do diretório atual. Agora, para compilar e instalar o JHBuild:

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

Se gnome-common, yelp-tools e autotools estiverem disponíveis, `autogen.sh` vai configurar o JHBuild para instalar via autotools. Se gnome-common, yelp-tools e autotools não estiverem disponíveis, `autogen.sh` vai configurar JHBuild para instalar por meio de um Makefile simples. Para sempre usar o método Makefile simples passe `--simple-install` para o `autogen.sh`.

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

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

Para adicionar permanentemente `~/.local/bin` à variável `PATH`, execute o seguinte comando:

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

### Configurando JHBuild

JHBuild pode ser configurado por um arquivo de configuração. A localização padrão é `~/.config/jhbuildrc`. 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 `examples/sample.jhbuildrc`. Copie `examples/sample.jhbuildrc` para `~/.config/jhbuildrc` e personalize da forma que precisar.

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

Variáveis de configuração estão documentadas em . A maioria das variáveis normalmente usadas são:

`repos`

  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:

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

`moduleset`

  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.

`modules`

  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 `buildone` seja usado. Padrão é `['meta-gnome-desktop']`.

`checkoutroot`

  Um texto especificando o diretório para o qual serão desempacotadas as árvores de fontes. Se `buildroot` estiver definido para `None`, as compilações vão ocorrer neste diretório também. Padrão é `~/jhbuild/checkout`.

`prefix`

  Um texto especificando o prefixo no qual serão instalados os módulos. `prefix` deve ser um caminho absoluto. Deve haver permissão de escrita para este diretório. Padrão é `'~/jhbuild/install/'`.

`autogenargs`

  Um texto contendo argumentos passados para o script `autogen.sh` de todos os módulos. Pode ser sobrescrito por módulos em particular usando o dicionário `module_autogenargs`.

`cmakeargs`

  Um texto contendo argumentos passados para a chamada de `cmake` de todos os módulos. Pode ser sobrescrito por módulos em particular usando o dicionário `module_cmakeargs`.

`makeargs`

  Um texto listando argumentos adicionais a serem passados para o `make`. JHBuild vai anexar automaticamente a opção de execução paralela (`-j`) baseada nos núcleos de CPU disponíveis. Padrão é `""`.

`mesonargs`

  Um texto contendo argumentos passados para a chamada de `meson` de todos os módulos. Pode ser sobrescrito por módulos em particular usando o dicionário `module_mesonargs`.

`ninjaargs`

  Uma string listando argumentos a serem passados para o `ninja`. Por padrão, usa `''`.

### Pré-requisitos de compilação

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 (autoconf, automake, libtool e gettext), o conjunto de ferramentas GNU (binutils, gcc, g++), make, pkg-config e Python, dependendo de quais módulos serão compilados.

JHBuild pode verificar se as ferramentas estão instaladas usando o `sanitycheck` command:

    $ jhbuild sanitycheck

Se este comando exibir quaisquer mensagens, por favor instale o pacote necessário do repositório de sua distribuição. Uma lista de nomes de pacotes para diferentes distribuições é mantida no wiki do GNOME. Execute o comando `sanitycheck` novamente após a instalação dos pacotes da distribuição para certificar de que as ferramentas necessárias estão presentes.

### Usando JHBuild

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 `~/.config/jhbuildrc`, execute o seguinte comando:

    $ jhbuild build

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.

Desistir do módulo vai levar qualquer módulo que dependa dele a falhar.

Logo abaixo está um exemplo do menu exibido:

      [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"
    escolha:

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 `build`. Por exemplo, para compilar gtk+:

    $ jhbuild build gtk+

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

    $ jhbuild build --start-at=pango

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

    $ jhbuild buildone gtk+

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

    $ jhbuild make

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 `list`:

    $ jhbuild list

Para obter informações sobre um módulo em particular, use o comando `info`:

    $ jhbuild info gtk+

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

    $ jhbuild update

Posteriormente, JHBuild pode compilar tudo sem baixar ou atualizar os fontes:

    $ jhbuild build --no-network

Para executar um comando em particular com o mesmo ambiente usado pelo JHBuild, use o comando `run`:

    $ jhbuild run program

Para iniciar um shell com o mesmo ambiente usado pelo JHBuild, use o comando `shell`:

    $ jhbuild shell

## JHBuild e GNOME

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

### Compilando GNOME

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

- DocBook XML DTD e folhas de estilos XSLT. Estas precisam estar registradas no catálogo XML (`/etc/xml/catalog`).

- Bibliotecas X.

- `libsmbclient` do Samba (usado para navegar por redes Windows).

- `libbz2` do bzip2.

- `libpng`, `libjpeg` e `libtiff` (usado para carregar imagens).

Se instalando pacotes de distribuição, e se aplicável a sua distribuição, instale os pacotes dev ou devel correspondentes. Uma lista de nomes de pacotes de diferentes distribuições é mantida no wiki do GNOME.

### Executando um único aplicativo do GNOME

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 .

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

    $ jhbuild shell

Verifique o aplicativo correto que será executado. Por exemplo:

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

Execute o aplicativo:

    $ gedit &

Alternativamente, execute o aplicativo usando o comando `run`:

    $ jhbuild run gedit

### Executando o ambiente GNOME

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

Configure o JHBuild na nova conta gnomedev. Copie ou crie um link simbólico de `~/.config/jhbuildrc` e `~/.local/bin/jhbuild` para a pasta pessoal do gnomedev.

Abra um terminal como o usuário gnomedev. Adicione permanentemente `~/.local/bin` para a variável `PATH`, execute o seguinte comando:

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

Teste se o JHBuild funciona:

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

#### Configurando o GNOME para executar do gerenciador de exibição

Compile e instale o GNOME do JHBuild.

Habilite os sistemas de serviço. O GNOME do JHBuild vai usar o daemon do D-Bus do sistema em `/usr/bin` e os sistemas de serviços dentro de `/usr/share/dbus-1/system-services/`. O GNOME do JHBuild vai usar o daemon do D-Bus da sessão do JHBuild e os serviços dentro de `~/jhbuild/install//share/dbus-1/services/`. Substitua `~/jhbuild/install` com o prefixo `prefix` de instalação do GNOME no comando abaixo:

    $ rm -rf ~/jhbuild/install/var/run/dbus
    $ ln -s /var/run/dbus ~/jhbuild/install/var/run/dbus
    $ rm -rf ~/jhbuild/install/var/lib/dbus/machine-id
    $ ln -s /var/lib/dbus/machine-id ~/jhbuild/install/var/lib/dbus/machine-id

Crie um script de inicialização do GNOME em `/usr/bin/gnome-jhbuild-session` com o seguinte, substituindo `~/jhbuild/install` com o prefixo `prefix`:

    #!/bin/sh

    GNOME=~/jhbuild/install

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

    jhbuild run gnome-session

Torne o arquivo `/usr/bin/gnome-jhbuild-session` um executável:

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

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

    [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

Reinicie o `gdm`.

#### Executando o GNOME do gerenciador de exibição

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

### Análise estática

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 `static_analyzer` para `True` no arquivo de configuração `.jhbuildrc`.

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 `/tmp/jhbuild_static_analyzer` (por padrão; o caminho pode ser alterado usando a variável de configuração `static_analyzer_outputdir`).

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

## Referência de comando

JHBuild usa uma sintaxe de linha de comando similar a ferramentas como CVS:

    jhbuild opções globais comando argumentos do comando

As opções globais do JHBuild são:

`-f`, `--file` configuração

  Usa um arquivo de configuração alternativo em vez do padrão `~/.config/jhbuildrc`.

`-m`, `--moduleset` coleção-de-módulos

  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.

`--no-interact`

  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.

`--exit-on-error`

  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.

`--conditions`

  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 `-wayland` ou `+docs` com a finalidade de remover ou adicionar condições. Modificações múltiplas podem ser separadas por uma vírgula (e.g.: `--conditions=+docs,-wayland`) ou você pode dividi-las por múltiplos argumentos de `--conditions`.

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

`JHBUILD_RUN_AS_ROOT`

  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 `JHBUILD_RUN_AS_ROOT` vai desabilitar a verificação de id de usuário na inicialização.

Opções específicas de comandos são listadas abaixo.

### autobuild

O comando `autobuild` compila automaticamente os módulos especificados no arquivo de configuração e, então, envia os resultados para JhAutobuild.

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

As opções `--autogen`, `--clean`, `--distcheck`, `--skip` e `--start-at` são processadas a cada execução do comando `build`.

`--report-url=url-relatório`, `-r url-relatório`

  Esta opção especifica a URL do JhAutobuild para a qual deve relatar.

`--verbose`, `-v`

  Se especificada, a saída do JHBuild será mais detalhada.

### bootstrap

O comando `bootstrap` instala uma coleção de utilitários de compilação. Os utilitários de compilação incluem autoconf, automake 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 `bootstrap` 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 Mac OS.

    jhbuild bootstrap

O comando `bootstrap` compila usando o mesmo método que o comando `build`, mas usa a coleção de módulos `bootstrap.modules`.

Veja a documentação do comando `build` por opções disponíveis.

### build

O comando `build` compila um ou mais pacotes, incluindo suas dependências.

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

Se nenhum nome de módulo for fornecido na linha de comando, a lista de módulos do arquivo de configuração será usada.

`-a`, `--autogen`

  Sempre executa `autogen.sh` antes de compilar módulos.

`-c`, `--clean`

  Executa `make clean` antes de compilar módulos.

`--check`

  Executa `make check` após compilar módulos.

`-d`, `--dist`

  Executa `make dist` após compilar módulos.

`--distcheck`

  Executa `make distcheck` após compilar módulos.

`--distclean`

  Para módulos git, executa `git clean -dfx` antes de compilar módulos. Para os demais, executa `make distclean` antes de compilar módulos.

  Esta opção vai excluir quaisquer alterações que não tiverem commit.

`--ignore-suggests`

  Não compila dependências adicionais.

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

  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.

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

  Não compila os módulos listados. Usada para pular a compilação das dependências especificadas.

`--tags`=tag,...

  Ignora módulos que não correspondam à tag. Aos módulos são atribuídos automaticamente uma tag correspondente ao nome da coleção de módulos do módulo.

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

  Inicia no módulo informado, ao invés do primeiro da lista. Esta opção é útil se a compilação foi interrompida.

`-D` data

  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.: `"2009-09-18 02:32Z"`.

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

  Executa testes gráficos no servidor X atual, em vez de em um Xvfb simulado.

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

  Se a compilação falhar, e se houver suporte pelo sistema de controle de versão, força um checkout e executa `autogen.sh` antes de tentar compilar novamente.

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

  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.

`-f`, `--force`

  Compila os módulos mesmo se a política define que não é necessário.

`--build-optional-modules`

  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.

`--min-age`=tempo

  Pula os módulos instalados mais recentemente do que o tempo especificado. O formato do tempo é um número seguido por uma unidade. Há suporte às seguintes unidades: segundos (s), minutos (m), horas (h) e dias (d). Por exemplo, `--min-age=2h` vai ignorar módulos compilados a duas horas atrás.

`--nodeps`

  Ignora dependências do sistema em falta. Para ignorar uma única dependência do sistema, adicione o módulo a `skip`.

### make

O comando `make` é 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 `buildone -nf $(basename $(pwd))`.

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

As opções são as mesmas disponíveis para o comando `buildone`.

### buildone

O comando `buildone` é similar ao `build`, mas ele não compila os módulos dependentes. Isso é útil para recompilar um ou mais módulos.

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

As opções `--autogen`, `--check`, `--clean`, `-d`, `--distcheck`, `--distclean`, `--no-network`, `-D`, `-x` e `--nodeps` são processadas a cada execução do comando `build`.

Pelo menos um módulo deve estar listado na linha de comando.

### checkbranches

O `checkbranches` 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.

    jhbuild checkbranches --branch=ramo

`--branch`=ramo, `-b` ramo

  O ramo a ser verificado.

    $ jhbuild -m gnome-2.20 checkbranches
    libgnomecanvas não tem a definição do ramo gnome-2-20
    $

### clean

O comando `clean` limpa os diretórios de compilação de um ou mais módulos.

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

Se nenhum nome de módulo for fornecido na linha de comando, a lista de módulos do arquivo de configuração será usada.

Veja a documentação do comando `build` para uma descrição das opções disponíveis.

### dot

O comando `dot` 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 GraphViz para produzir um diagrama.

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

Se nenhum nome de módulo for fornecido na linha de comando, a lista de módulos do arquivo de configuração será usada.

A opção `--soft-deps` adiciona linhas pontilhadas dos módulos para as suas dependências. A opção `--clusters` agrupa módulos de metamodules.

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

    $ jhbuild dot módulos | dot -Tps > dependências.ps

Ou uma imagem PNG:

    $ jhbuild dot módulos | dot -Tpng > dependências.png

#### Exemplo de saída do dot do JHBuild

### gui

O comando `gui` inicia uma interface gráfica do JHBuild que pode ser usada para selecionar módulos para compilar e alterar algumas opções.

    jhbuild gui

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

### info

O comando `info` exibe informações sobre um ou mais módulos.

    jhbuild info --installed módulo

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.

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

Se a opção `--installed` 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.

Se a opção `--installed` 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.

### list

O comando `list` exibe a lista expandida de módulos que o comando `build` compilaria.

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

Se nenhum nome de módulo for fornecido na linha de comando, a lista de módulos do arquivo de configuração será usada.

As opções `--skip`, `--start-at`, `--tags` e `--ignore-suggests` são processadas a cada execução do comando `build`.

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

  Lista todos os módulos da coleção de módulos independentemente das dependências de compilação.

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

  Se um módulo está definido em um ramo, mostra o nome do ramo com o nome do módulo.

`--list-optional-modules`

  Esta opção força o JHBuild a lista todas as dependências opcionais.

### rdepends

O comando `rdepends` exibe as dependências inversas de um módulo.

    jhbuild rdepends módulo

`--dependencies`

  Mostra um caminho de dependência ao lado dos módulos.

`--direct`

  Limita a exibição a módulos dependendo diretamente do módulo especificado.

### run

O comando `run` executa o comando especificado usando o mesmo ambiente que o JHBuild usa ao compilar módulos.

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

Se usando o JHBuild para compilar o GNOME, este comando pode ser útil em scripts de inicialização do X.

`--in-builddir`=módulo

  Executa o comando no diretório de compilação do módulo especificado.

`--in-checkoutdir`=módulo

  Executa o comando no diretório fonte do módulo especificado.

### sanitycheck

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

    jhbuild sanitycheck

Algumas verificações incluem:

- Os prefixos de checkout e instalação têm permissão de escrita.

- As ferramentas necessárias para compilação estão instaladas.

- Algumas macros comumente usadas estão disponíveis nos caminhos de pesquisa dos comandos de `aclocal` associados com as várias versões do `automake`.

- O catálogo XML contém o DocBook DTD e as folhas de estilos.

### shell

O comando `shell` inicia o shell do usuário com o mesmo ambiente que o JHBuild usa ao compilar módulos.

    jhbuild shell

O comando é equivalente a:

    $ jhbuild run $SHELL

A variável de ambiente `UNDER_JHBUILD` 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 `.bashrc`:

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

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

### sysdeps

O comando `sysdeps` exibe:

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

2. uma lista de pacotes necessários. Para começar uma compilação, os pacotes devem ser fornecidos pelo seus sistema.

3. 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 `partial_build` for `False`.

    jhbuild sysdeps --install

`--install`

  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 PackageKit, se disponível. Para distribuições usando APT como o Debian e Ubuntu, esta opção requer apt-file para ser instalada.

#### exemplos de `sysdeps`

    $ jhbuild sysdeps
    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)
        ...

### tinderbox

O comando `tinderbox` é similar ao `build`, 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.

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

As opções `--autogen`, `--clean`, `--distclean`, `--no-network`, `--skip`, `--start-at`, `-D`, `-C`, `-N`, `-f` e `--nodeps` são processadas a cada execução do comando `build`.

`-o`, `--output`=diretório

  O diretório no qual serão escritos os arquivos HTML. JHBuild vai criar um índice (`index.html`) e um arquivo HTML para cada módulo.

### uninstall

O comando `uninstall` desinstala um ou mais módulos.

    jhbuild uninstall módulo

### update

O comando `update` é similar ao `build`, mas realiza apenas os estágios de baixar e atualizar para módulos sem compilá-los.

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

As opções `--skip`, `--start-at`, `--tags`, `--ignore-suggests` e `-D` são processadas a cada execução do comando `build`.

### updateone

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

    jhbuild updateone -D data módulo

A opção `-D` é processada a cada execução do comando `build`.

Pelo menos um módulo deve estar listado na linha de comando.

## Referência de arquivo de configuração

O arquivo `~/.config/jhbuildrc` 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.

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

    use_local_modulesets = True

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

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

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

    skip = ['mozilla', 'pulseaudio']

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

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

### Variáveis de configuração

`alwaysautogen`

  Um valor em boolean que, se definida como `True`, sempre executa `autogen.sh`. Este comando é equivalente a passar a opção `--autogen` para o JHBuild. Padrão é `False`.

`autogenargs`

  Uma string contendo argumentos passados para o script `autogen.sh` de todos os módulos. Pode ser sobrescrita por módulos em particular, usando o dicionário `module_autogenargs`.

`branches`

  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.

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

  - CVS: revisão. Ex.: `'BRANCH-PROJECT-0_8'`

  - Bazaar: URI do ramo do módulo. Ex.: `'http://bzr.exemplo.net/projeto/gnome-2-28'`

  - Git: tupla, com a primeira parte sendo um repositório opcional (ou o valor “None”) e a segunda parte do nome do ramo. Ex.: `('git://git.exemplo.net/projeto', 'gnome-2-28')`

    #### Exemplo simples

        branches['nome-do-módulo'] = (None, 'nome-do-ramo')

  - Subversion: URI do ramo do módulo. Ex.: `'svn://svn.exemplo.net/projeto/gnome-2-28'`

`builddir_pattern`

  Um padrão de formatação de estilo do `printf` usado para gerar nomes de diretórios de compilação. Isso é usado apenas ao usar árvores de fontes e compilação separados. O `%s` na string de formatação será substituído com `checkoutdir`. Padrão é `'%s'`.

`buildroot`

  Uma string especificando o diretório pai para colocar as árvores de compilação. Padrão é `~/.cache/jhbuild/build`. Definir esse valor para `None` faz com que as compilações sejam realizadas dentro das árvores de fontes.

`buildscript`

  Uma string especificando qual buildscript deve ser usado. A configuração recomendada é a padrão, `terminal`. Em particular, não defina para `gtk`.

`build_policy`

  Uma string especificando quais módulos devem ser compilados. As três opções possíveis são: `all` para compilar todos os módulos solicitados; `updated` para compilar apenas os módulos que você alterou; ou `updated-deps` para compilar módulos que você alterou ou que possuem dependências que foram alteradas. Padrão é `updated-deps`.

`checkoutroot`

  Uma string especificando o diretório para o qual deve-se descompilar árvores de fontes. A menos que `buildroot` esteja especificado, as compilações ocorrerão neste diretório também. Padrão é `~/checkout/gnome`.

`checkout_mode`

  Uma string especificando como o checkout é realizado para diretórios em controle de versão. Padrão é `update`. Isso pode ser definido por módulo usando `module_checkout_mode`. Possíveis valores são `update` (atualiza diretório de checkout), `clobber` (limpa o diretório antes de buscar os fontes), `export` (limpa o diretório e, então, cria um tarball de fontes contendo quaisquer patches) e `copy` (realiza checkout em um diretório diferente daquele que será compilado).

`cmakeargs`

  Uma string contendo argumentos passados para a chamada de `cmake` de todos os módulos. Pode ser sobrescrita por módulos em particular, usando o dicionário `module_cmakeargs`. Padrão é `''`.

`copy_dir`

  Uma string especificando o diretório para onde será copiado, se a cópia `checkout_mode` estiver em uso. Padrão é o diretório de checkout.

`export_dir`

  Uma string especificando o diretório para onde será exportado, se a exportação `checkout_mode` estiver em uso. Padrão é o diretório de checkout.

`cvs_program`

  Uma string especificando qual programa deve ser usado para dar suporte a CVS. Pode ser `git-cvsimport` ou `cvs`. Padrão é `cvs`.

`disable_Werror`

  Um valor booleano (padrão `True`) que controla se `--disable-Werror` 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 `True` 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 `False` pode fazer sentido para aqueles usando jhbuild como parte de um sistema de teste ou integração contínua.

`dvcs_mirror_dir`

  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 `update` e `updateone` 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.

`exit_on_error`

  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 `True` é equivalente a passar a opção `--exit-on-error`. Padrão é `False`.

`extra_prefixes`

  Uma lista de strings especificando, por ordem de precedência, a lista de prefixos extras. JHBuild define muitas variáveis de ambiente (tais como `LD_LIBRARY_PATH`, `PKG_CONFIG_PATH` e `XDG_DATA_DIRS`) baseadas na variável `prefix`. Adicionar diretórios a `extra_prefixes` vai resultar em esses prefixos serem incluídos também, em uma precedência menor do que o `prefix` 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 `/usr/local`, caso em que ela contém esse diretório.

`help_website`

  Uma tupla especificando o nome do site e URL de ajuda. O site é exibido no html de tinderbox para módulos que falharem. `%(module)s` na URL será substituído com o nome do módulo. Para desabilitar, defina `help_website` para `None`. Padrão é `('Gnome Live!', 'http://live.gnome.org/JhbuildIssues/%(module)s')`.

`installprog`

  Uma string especificando um programa a ser usado como substituto para `/usr/bin/install`.

`ignore_suggests`

  Um valor em boolean especificando se deve-se ignorar dependências ao se calcular a árvore de dependência. Padrão é `False`.

`interact`

  Um valor em boolean especificando se deve-se interagir com o usuário. Definindo este valor para `False` é equivalente a passar a opção `--no-interact`. Padrão é `True`.

`makeargs`

  Um texto listando argumentos adicionais a serem passados para o `make`. JHBuild vai anexar automaticamente a opção de execução paralela (`-j`) baseada nos núcleos de CPU disponíveis. Padrão é `""`.

`makecheck`

  Um valor em boolean especificando se deve-se executar `make check` após `make`. Padrão é `False`.

`makecheck_advisory`

  Um valor em boolean especificando se as falhas ao executar `make check` deveriam ser avisos e não causar uma falha de compilação. Padrão é `False`.

`makeclean`

  Um valor boolean especificando se deve-se executar `make clean` antes `make`. Padrão é `False`.

`makedist`

  Um valor em boolean especificando se deve-se executar `make dist` após `make`. Padrão é `False`. Esta configuração é equivalente a passar a opção `--dist`.

`makedistcheck`

  Um valor em boolean especificando se deve-se executar `make distcheck` após `make`. Padrão é `False`. Esta configuração é equivalente a passar a opção `--distcheck`.

`mesonargs`

  Uma string contendo argumentos passados para a chamada de `meson` de todos os módulos. Pode ser sobrescrita por módulos em particular, usando o dicionário `module_mesonargs`. Padrão é `''`.

`module_autogenargs`

  Um dicionário mapeando os nomes de módulos em strings especificando os argumentos a serem passados para o `autogen.sh`. A configuração em `module_autogenargs` é usada, em vez da configuração global `autogenargs`. Se um módulo particular não está listado no diretório, a global `autogenargs` será usada.

`module_checkout_mode`

  Um dicionário especificando quais modos de checkout devem ser usados para os módulos. Isso sobrescreve a configuração global `checkout_mode`.

`module_cmakeargs`

  Um dicionário mapeando os nomes de módulos em strings especificando os argumentos a serem passados para o `cmake`. A configuração em `module_cmakeargs` é usada, em vez da configuração global `cmakeargs`. Se um módulo particular não está listado no diretório, a global `cmakeargs` será usada.

`module_makeargs`

  Um dicionário mapeando os nomes de módulos em strings especificando os argumentos a serem passados para `make`. A configuração em `module_makeargs` substitui o valor de `makeargs`. Se um módulo em particular não está listado no dicionário, a global `makeargs` será usada.

`module_makecheck`

  Um dicionário mapeando os nomes de módulos em valores boolean especificando se deve-se executar `make check` após `make`. A configuração em `module_makecheck` substitui o valor de `makecheck`. Se um módulo em particular não estiver listado no dicionário, a globa `makecheck` será usada.

`module_mesonargs`

  Um dicionário mapeando os nomes de módulos em strings especificando os argumentos a serem passados para o `meson`. A configuração em `module_mesonargs` é usada, em vez da configuração global `mesonargs`. Se um módulo particular não está listado no diretório, a global `mesonargs` será usada.

`module_ninjaargs`

  Um dicionário mapeando os nomes de módulos em strings especificando os argumentos a serem passados para `ninja`. A configuração em `module_ninjaargs` substitui o valor de `ninjaargs`. Se um módulo em particular não está listado no dicionário, a global `ninjaargs` será usada.

`module_nopoison`

  Um dicionário mapeando os nomes de módulos em valores boolean. Se um módulo estiver definido como `True`, JHBuild vai tentar compilar módulos dependentes mesmo se o módulo especificado falhar. A configuração em `module_nopoison` substitui o valor de `nopoison`. Se um módulo em particular não estiver listado no dicionário, a global `nopoison` será usada.

`module_extra_env`

  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.

`module_static_analyzer`

  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 `static_analyzer` seja sobrescrita.

`modules`

  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 `buildone` seja usado. Padrão é `['meta-gnome-desktop']`.

`moduleset`

  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.

`modulesets_dir`

  Uma string especificando o diretório contendo as coleções de módulos a serem usadas. Padrão é o diretório `modulesets/` nos fontes do JHBuild.

`nice_build`

  Executa compilações sob a prioridade `SCHED_IDLE` no Linux, `nice` 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.

`ninjaargs`

  Uma string listando argumentos a serem passados para o `ninja`. Por padrão, usa `''`.

`nobuild`

  Um valor em boolean, se definido como `True`, o JHBuild não vai compilar módulos, e sim apenas baixar e desempacotar os fontes. O valor padrão é `False`.

`nonetwork`

  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 `True` é equivalente a passar a opção `--no-network`. Padrão é `False`.

`nonotify`

  Um valor em boolean especificando se deve-se emitir notificações usando o daemon de notificação. Se definido como `False`, notificações são emitidas. Padrão é `True`.

`nopoison`

  Um valor em boolean, se definido como `True`, 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 `--no-poison`. O valor padrão é `False`.

`notrayicon`

  Um valor em boolean especificando se deve-se mostrar um ícone na área de notificação usando o Zenity. Se definido como `False`, um ícone é mostrado. Padrão é `True`.

`noxvfb`

  Um valor em boolean, se definido como `True`, JHBuild vai executar quaisquer testes gráficos no servidor X real, em vez de usar `Xvfb`. Esta opção é equivalente a passar `--no-xvfb`. O valor padrão é `False`.

`partial_build`

  Um valor em boolean, se definido como `True`, 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 é `True`.

`prefix`

  Um texto especificando o prefixo no qual serão instalados os módulos. `prefix` deve ser um caminho absoluto. Deve haver permissão de escrita para este diretório. Padrão é `'~/jhbuild/install/'`.

`pretty_print`

  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 é `True`.

`print_command_pattern`

  Uma string exibida antes do JHBuild executar um comando. `%(command)s` na string vai ser substituído com o comando a ser executado. `%(cwd)s` na string será substituída com o diretório de trabalho atual. Padrão é `'%(command)s'`.

`progress_bar`

  Um valor em boolean especificando se deve-se exibir uma barra de progresso durante o quiet_mode. Padrão é `True`.

`quiet_mode`

  Um valor em boolean, se definido como `True`, desabilita a saída (mensagens) dos comandos em execução. Padrão é `False`.

`repos`

  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:

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

`shallow_clone`

  Um valor boolean especificando se o JHBuild deve preferir downloads menores de controle de versão. Equivalente a `git clone --depth 1` ou `bzr co --light`. Padrão é `False`.

`skip`

  Uma lista de módulos para pular. Esta opção de linha de comando `--skip` estende a lista. Esta lista está vazia, por padrão. Se a lista contém um valor especial `"*"`, JHBuild vai pular todos os módulos não listados explicitamente na variável `modules`. Isso pode ser útil se você deseja compilar módulos sem suas dependências implícitas.

`static_analyzer`

  Um valor booleano, se definido como `True`, executa uma ferramenta de análise estática em cada módulo como está sendo compilado. Padrão é `False`.

`static_analyzer_outputdir`

  Diretório raiz abaixo no qual relatórios de análise estática serão salvos (se `static_analyzer` for `True`). Padrão é `/tmp/jhbuild_static_analyzer`.

`static_analyzer_template`

  Modelo de comando para analisador estático. Ele possui os parâmetros `outputdir` (o valor da variável de configuração `static_analyzer_outputdir`) e `module` (o nome do módulo sendo compilado atualmente) substituído por um estilo `printf`. O comando resultante é usado como um prefixo para `make` ao compilador um módulo. Padrão é `scan-build`.

`sticky_date`

  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.: `"yyyy-mm-dd"`. Padrão é `None`.

`svn_program`

  Uma string especificando qual programa deve ser usado para ter suporte a subversion. Pode ser `svn`, `git-svn` ou `bzr`. Padrão é `svn`.

`system_libdirs`

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

`tarballdir`

  Uma string que, se definida, faz tarballs serem baixados para o diretório especificado em vez do `checkoutroot`. Isso é útil se você tiver múltiplos ambientes de JHBuild ou regularmente limpa `checkoutroot` e deseja reduzir o uso da conexão com a Internet. O padrão é `'~/cache/jhbuild/downloads'`.

`tinderbox_outputdir`

  Uma string especificando o diretório para armazenar a saída de `jhbuild tinderbox`. Esta string pode ser sobrescrita pela opção `--output`. Padrão é `None`, 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.

`trycheckout`

  Um valor em boolean, se definido como `True`, JHBuild vai automaticamente tentar resolver falhas 1) executando `autogen.sh` 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 `--try-checkout`.

`use_local_modulesets`

  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 é `False`.

`xvfbargs`

  Uma string listando argumentos a serem passados para o `Xvfb`, se executando testes gráficos.

`conditions`

  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 `conditions.add()` e `conditions.discard()` para modificar a lista se você quiser fazer alterações.

  A coleção original de condições é determinado de acordo com o SO e pode ser modificado usando o argumento de linha de comando `--conditions=`. As alterações feitas por `--conditions` 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 `--conditions` serão aplicadas novamente após qualquer alterações feita por jhbuildrc.

### Outras estruturas do arquivo de configuração

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

`os.environ`

  Um dicionário representando o ambiente. Este ambiente é passado para o processo que chama o JHBuild.

  Algumas variáveis de ambiente influenciáveis incluem `CPPFLAGS`, `CFLAGS`, `INSTALL` e `LDFLAGS`. Por exemplo:

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

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

  Isso vai adicionar um diretório à variável de ambiente `PATH`. `addpath` 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).

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

  Após o processamento do arquivo de configuração, JHBuild vai alterar alguns caminhos baseados em tais `prefix` (ex.: adicionar `$prefix/bin` ao início de `PATH`).

  A função `prependpath` funciona como `addpath`, exceto que a variável de ambiente é modificada após JHBuild ter feito suas alterações no ambiente.

## Sintaxe de arquivo de coleção de módulos

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 `modulesets/`. O esquema de RELAX-NG pode ser usado para editar arquivos de coleção de módulos usando `nxml-mode` no Emacs.

O elemento primário em um arquivo da coleção de módulos é o elemento `moduleset`. 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.

O conteúdo no arquivo de coleção de módulos pode ser incluído condicionalmente usando a tag <if> 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 <if condition-set='cond'> ou <se condition-unset='cond'>. Condições são definidas por padrão com base no SO, mas pode ser influenciado por meio da variável `conditions` em jhbuildrc ou o argumento de linha de comando `--conditions=`.

### Fontes de módulo

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

O elemento `repository` é usado para descrever todos os tipos de repositórios. O elemento `branch` é usado dentro da definição do módulo para especificar configurações adicionais.

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

O atributo `name` é um identificador único do repositório.

O atributo `default` especifica este repositório no fonte padrão desta coleção de módulos.

O atributo `type` especifica o tipo de repositório. Ele pode ser: `bzr`, `cvs`, `darcs`, `fossil`, `git`, `hg`, `mnt`, `svn` ou `tarball`. Outros atributos dependem do `type`, além do `branch` usado dentro das definições de módulo. Aqueles descritos embaixo das subseções de tipos de repositório.

O atributo `developer-href-example` é usado para especificar o formato da URL do repositório usado por desenvolvedores. Serve apenas como informação.

O elemento `branch` é usado dentro das definições de módulo.

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

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.

O atributo `repo` é usado para especificar um nome de repositório não padronizado.

O atributo `module` é usado para especificar um nome de módulo para baixar do repositório. Padrão é a identificação (id) do módulo.

O atributo `checkoutdir` é usado para especificar o nome do diretório no qual será realizado checkout. Padrão é a identificação (id) do módulo.

Outros atributos são descritos abaixo.

#### Bazaar

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

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

São atributos adicionais: `trunk-template` (padrão é `"%(module)s"`) e `branches-template` (padrão é `"%(module)s/%(branch)s`"). Estes atributos são usados para especificar modelos para construção de URL. Um elemento `branch` nas definições do módulo pode especificar atributos `branch` e `user`. Estes valores serão substituídos nos modelos. Se um deles for definido, `branches-template` é usado. Do contrário, `trunk-template` é 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.

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

Por exemplo, um repositório com atributos `template` definidos:

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

Exemplo de elementos `branch` para o repositório acima:

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

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

#### CVS

Este tipo de repositório é usado para definir um repositório CVS.

O atributo `password` é usado para especificar a senha do repositório.

O atributo `cvsroot` é usado para especificar a raiz do repositório.

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

São atributos adicionais: `revision`, `update-new-dirs` e `override-checkoutdir`.

#### Darcs

Este tipo de repositório é usado para definir um repositório Darcs.

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

#### Git

Este tipo de repositório é usado para definir um repositório Git.

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

Ele permite os seguintes atributos no elemento `branch`:

O atributo `revision` é 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 `branches`. A seleção será realizada apenas se o ramo atual estiver seguindo um ramo remoto, para não atrapalhar o seu próprio trabalho.

O atributo `tag` é usado para especificar uma revisão para baixar incondicionalmente na fase de atualização. Ele substitui o atributo `revision`.

    <branch repo="git.freedesktop.org" module="swfdec/swfdec"
            checkoutdir="swfdec"
            revision="ramo-local-ou-remoto"
            tag="tag"/>

#### Mercurial

Este tipo de repositório é usado para definir um repositório Mercurial.

    <repository type="hg" name="hg.gtk-vnc"
        href="http://gtk-vnc.codemonkey.ws/hg/" />

    <branch repo="hg.gtk-vnc" module="outgoing.hg" checkoutdir="gtk-vnc"/>

#### Monotone

Este tipo de repositório é usado para definir um repositório Monotone.

O atributo `server` é usado para especificar o servidor do repositório.

O atributo `database` é usado para especificar o banco de dados a ser usado pelo repositório.

O atributo `defbranch` é usado para especificar o ramo do repositório a ser usado.

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

#### Subversion

Este tipo de repositório é usado para definir um repositório.

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

Ele permite uma `revision` no elemento `branch`. Este atributo define o ramo para fazer checkout ou, se for um número, uma revisão específica para fazer checkout.

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

É possível especificar uma disposição `svn` diferente usando `trunk-template` (padrão é “%(module)s/trunk”), `branches-template` (padrão é “%(module)s/branches/%(branch)s”) and `tags-template` (padrão é “%(module)s/tags/%(tag)s”)

#### Sistema

Este tipo de repositório é usado para definir um repositório de sistema falso. Um repositório de sistema é necessário para criar `systemmodules`.

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

#### Tarballs

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

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

Ele permite os seguintes atributos no elemento `branch`:

O atributo `module` especifica o arquivo para baixar e compilar, o atributo `version` especifica a versão do módulo.

Os elementos `size` e `hash`, assim como o obsoleto `md5sum`, são opcionais. Se esses atributos estiverem presentes, eles são usados para verificar se o pacote de fontes foi baixado corretamente.

O atributo `rename-tarball` pode ser usado para renomear o arquivo tarball ao baixar, no caso do nome original conflitar com outro módulo.

Qualquer número de elementos de `patch` pode ser acrescentado dentro do elemento `branch`. Esses patches são aplicados, em ordem, na árvore de fontes após o desempacotamento. O atributo `file` fornece o nome do arquivo de patch e o atributo `strip` informa quantos níveis devem ser suprimidos ao aplicar o patch.

Para coleções de módulos disponibilizados com o JHBuild, os arquivos de patch são buscados no diretório `jhbuild/patches/`; 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 `patches/`. Também é possível que o atributo `file` especifique uma URI, caso em que o patch será baixado desta localização.

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

Um elemento `branch` de tarball também pode conter elementos `quilt`, que especificam `branch` aninhados para importar.

### Incluindo outras coleções de módulos

JHBuild permite que uma coleção de módulos inclua os conteúdos de outra por referência usando o elemento `include`.

    <include href="uri"/>

O `href` é uma referência de URI à coleção de módulos a serem incluídos, relativo ao arquivo contendo o elemento `include`.

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

### Definições de módulo

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.

As definições são basicamente todas compostas de um elemento `branch` descrevendo como obter o módulo e elementos `dependencies`, `suggests` e `after` para declarar as dependências do módulo.

Quaisquer módulos listados no elemento `dependencies` serão adicionados à lista de módulos de `jhbuild build`, se eles já não estiverem inclusos, e confirmados de que módulos dependentes serão compilados primeiro.

Após gerar a lista de módulos, os módulos listados no elemento `suggests` 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.

#### autotools

O elemento `autotools` é usado para definir um módulo que é compilado usando o sistema de compilação do GNU Autotools.

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

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

      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <after>
        <dep package="nome-do-módulo"/>
        ...
      </after>

    </autotools>

Os atributos `autogenargs`, `makeargs` e `makeinstallargs` são usados para especificar argumentos adicionais a serem passados para o `autogen.sh`, `make` e `make install`, respectivamente.

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

O `uninstall-before-install` 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.

O atributo `supports-non-srcdir-builds` é usado para marcar módulos que não podem ser compilados do zero usando um diretório de fontes separados.

O atributo `force-non-srcdir-builds` é 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.

O atributo `autogen-template` 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: `srcdir`, `autogen-sh`, `prefix`, `libdir` e `autogenargs`. Por exemplo, aqui está o autogen-template padrão:

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

O atributo `check-target` deve ser especificado (com valor sendo falso) para módulos que não possuem um alvo para `make check`.

O atributo `supports-static-analyzer` 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 `scan-build`.

O atributo `supports-unknown-configure-options` é usado para marcar módulos que vão resultar em erro se uma opção desconhecida é passada para `configure`. Opções de configurações globais não serão usada para aquele módulo.

#### cmake

O elemento `cmake` é usado para definir um módulo que é compilado usando o sistema de compilação do CMake.

      <cmake id="nome-do-módulo"
          [ cmakeargs="argumentos-cmake" ]
          [ ninjaargs="argumentos-ninja" ]
          [ makeargs="argumentos-make" ]
          [ skip-install="instalação-para-ignorar" ]
          [ cmakedir="dir-cmake" ]
          [ use-ninja="usar-ninja" ]
          [ force-non-srcdir-builds="força-compilação-não-srcdir" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <after>
        <dep package="nome-do-módulo"/>
        ...
      </after>
    </cmake>

O atributo `cmakeargs` é usado para especificar argumentos adicionais a ser passados para o `cmake`.

O atributo `ninjaargs` é usado para especificar argumentos adicionais a ser passados para o `ninja`.

O atributo `makeargs` é usado para especificar argumentos adicionais a ser passados para o `make`.

O atributo `dir-cmake` é usado para especificar o subdiretório no qual o cmake será executado em relação ao srcdir.

O atributo `force-non-srcdir-builds` é 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.

O atributo `use-ninja` é usado para marcar módulos que devem se compilados usando o backend Ninja para cmake, em vez do backend Make. O padrão é usar o backend Ninja.

#### Meson

O elemento `meson` é usado para definir um módulo que é configurado usando o sistema de compilação do Meson e compilado usando a ferramenta de compilação Ninja.

      <meson id="nome-do-módulo"
                [ mesonargs="argumentos-meson" ]
                [ ninjaargs="argumentos-ninja" ]
                [ skip-install="instalação para ignorar" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <after>
        <dep package="nome-do-módulo"/>
        ...
      </after>
    </meson>

O atributo `mesonargs` é usado para especificar argumentos adicionais a ser passados para o `meson`.

O atributo `ninjaargs` é usado para especificar argumentos adicionais a ser passados para o `ninja`.

#### distutils

O elemento `distutils` é usado para definir um módulo que é compilado usando distutils do python.

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

      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <after>
        <dep package="nome-do-módulo"/>
        ...
      </after>
    </distutils>

#### linux

O elemento `linux` 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 `kconfig`.

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

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

      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <after>
        <dep package="nome-do-módulo"/>
        ...
      </after>

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

    </linux>

#### perl

O elemento `perl` é usado para compilar módulos de perl.

O atributo `makeargs` é usado para especificar argumentos adicionais a ser passados para o `make`.

    <perl id="nome-do-módulo"
    	 [ makeargs="argumentos-make" ]>

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

      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <after>
        <dep package="nome-do-módulo"/>
        ...
      </after>

    </perl>

#### systemmodule

O elemento `systemmodule` é 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.

    <systemmodule id="nome-do-módulo">
      <pkg-config>pkg-config.pc</pkg-config>

      <branch repo="sistema" version="versão" />
    </systemmodule>

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

1. Valor `path`. O caminho é pesquisado por um nome de programa correspondente.

2. Valor `c_include`. O caminho de include C é pesquisado pelo nome de header correspondente. `name` pode incluir um subdiretório. O caminho de pesquisa de includes C podem ser modificados pela configuração `CPPFLAGS` dentro das variáveis de configuração `cflags` ou `module_autogenargs`.

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

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

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

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

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

#### waf

O elemento `waf` é usado para definir um módulo que é compilado usando o sistema de compilação do Waf.

O atributo `waf-command` é usado para especificar o script do comando waf a ser usado. Padrão é `waf`.

O atributo `python-command` é usado para especificar o executável do Python a ser usado. Padrão é `python`. Isso é útil para compilar módulos com a versão 3 do Python.

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

      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <after>
        <dep package="nome-do-módulo"/>
        ...
      </after>
    </waf>

#### testmodule

O elemento `testmodule` é usado para criar um módulo que executa uma suíte de testes usando LDTP ou Dogtail.

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

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

      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <after>
        <dep package="nome-do-módulo"/>
        ...
      </after>

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

    </testmodule>

O atributo `type` 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'.

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

#### metamodule

O elemento `metamodule` define um módulo que, na verdade, nada faz. O único propósito de um módulo deste tipo é suas dependências.

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.

    <metamodule id="nome-do-módulo">
      <dependencies>
        <dep package="nome-do-módulo"/>
        ...
      </dependencies>
      <suggests>
        <dep package="nome-do-módulo"/>
        ...
      </suggests>
    </metamodule>

O atributo `id` fornece o nome do módulo. Os elementos filhos são lidados como sendo de `autotools`.

### Elementos obsoletos

#### Fontes de módulo

##### cvsroot

O elemento `cvsroot` está agora obsoleto - o elemento `repository` deveria ser usado em seu lugar.

O elemento `cvsroot` é usado para descrever um repositório CVS.

      <cvsroot name="nome-raiz"
               [ default="yes|no" ]
               root="cvsroot-anônimo"
               password="senha-anônimo"/>

O atributo `name` deveria ser um identificador único do repositório CVS.

O atributo `default` informa se este é ou não a fonte padrão do módulo deste arquivo de coleção de módulos.

O atributo `root` lista a raiz CVS usada para um acesso anônimo a este repositório e o atributo `password` informa a senha usada para um acesso anônimo.

##### svnroot

O elemento `svnroot` está agora obsoleto - o elemento `repository` deveria ser usado em seu lugar.

O elemento `svnroot` é usado para descrever um repositório Subversion.

      <svnroot name="nome-raiz"
               [ default="yes|no" ]
               href="svnroot-anônimo"/>

O atributo `name` deveria ser um identificador único do repositório Subversion.

O atributo `default` informa se este é ou não a fonte padrão do módulo deste arquivo de coleção de módulos.

O atributo `href` lista a URL base do repositório. Provavelmente será uma URL de `http`, `https` ou `svn`.

#### Tipos de módulos obsoletos

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.

##### tarball

Este elemento obsoleto é apenas uma interface dos tipos de módulo `autotools` e de repositório `tarball`.

O elemento `tarball` é usado para definir um módulo que está para ser compilado a partir de um tarball.

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

Os atributos `id` e `version` são usados para identificar o módulo.

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

O elemento `patches` é 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 `file` fornece o nome de arquivo do patch e o atributo `strip` informa quantos níveis devem ser suprimidos ao aplicar o patch.

Para coleções de módulos disponibilizados com o JHBuild, os arquivos de patch são buscados no diretório `jhbuild/patches/`; 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 `patches/`. Também é possível que o atributo `file` especifique uma URI, caso em que o patch será baixado desta localização.

Os outros atributos e os elementos `dependencies`, `suggests` e `after` são processados como sendo de autotools.