# Handbok för JHBuild

James
Henstridge
C.J.
Adams-Collier
Frederic
Peters
David
Turner
2004, 2008
James Henstridge
Handbok för JHBuild v0.5
Januari 2008
Handbok för JHBuild v0.1
Augusti 2007

JHBuild är ett verktyg som används för att bygga hela GNOME-skrivbordet från versionshanteringssystemet. JHBuild kan också anpassas för att bygga andra projekt.

Daniel Nylander
po@danielnylander.se
2008
Daniel Nylander
Anders Jonsson
anders.jonsson@norsjovallen.se
2016
Anders Jonsson
Sebastian Rasmussen
sebras@gmail.com
2016
Sebastian Rasmussen

## Introduktion

JHBuild är ett verktyg designat för att förenkla byggande av samlingar av källpaket, kallade moduler. JHBuild använder moduluppsättnings-filer för att beskriva modulerna som finns tillgängliga att bygga. Moduluppsättnings-filer inkluderar beroendeinformation som låter JHBuild upptäcka vilka moduler som måste byggas och i vilken ordning.

JHBuild skrev från början för att bygga GNOME, men har sedan dess blivit utökat för att vara användbart för andra projekt. En moduluppsättnings-fil kan sparas på en webbserver vilket låter byggregler vara oberoende av JHBuild-projektet.

JHBuild kan bygga moduler från en uppsjö av källor, inklusive CVS-, Subversion-, Bazaar-, Darcs-, Git- och Mercurial-arkiv, så väl som Tar- och Zip-arkiv från webb- eller FTP-platser. JHBuild kan bygga moduler via ett antal byggsystem, inklusive Autotools-, CMake-, Meson-, WAF-, Python Distutils- och Perl-Makefiler.

JHBuild är inte avsett att vara en ersättare för distributionens pakethanteringssystem. Det gör det istället enkelt att bygg programvara för ett separat installationsprefix utan att interferera med resten av systemet.

## Komma igång

JHBuild kräver att ett antal inställningssteg genomförs innan man bygger programvara. JHBuild förutsätter viss programvara och det är nödvändigt att installera de krävda verktygen för att hämta och bygga programvarumodulerna.

### Installera JHBuild

JHBuild kräver en Python-exekveringsmiljö. Verifiera att Python >= 3.5 är installerat.

Det rekommenderade sättet att hämta JHBuild är via versionshanteringssystemet `git`. Detta kan åstadkommas med följande kommando. Det rekommenderas att kommandot körs från en ny katalog där all källkod kommer att installeras, t.ex. `~/jhbuild/checkout`.

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

Detta kommer att hämta JHBuild till en ny mapp vid namn `jhbuild` under den aktuella katalogen. Bygg och installera nu JHBuild:

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

Om gnome-common, yelp-tools och autotools finns tillgängliga så kommer `autogen.sh` att konfigurera JHBuild att installera via autotools. Om gnome-common, yelp-tools och autotools inte finns tillgängliga kommer `autogen.sh` att konfigurera JHBuild att installera via en vanlig Makefil. För att alltid använda metoden med en vanlig Makefil ange `--simple-install` till `autogen.sh`.

Om stegen ovan avslutas framgångsrikt kommer ett litet skalskript att installeras i `~/.local/bin` för att starta JHBuild. Lägg till `~/.local/bin` i `PATH`:

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

För att permanent lägga till `~/.local/bin` till variabeln `PATH`, kör följande kommando:

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

### Konfigurera JHBuild

JHBuild kan konfigureras via en konfigurationsfil. Standardplatsen är `~/.config/jhbuildrc`. Om en konfigurationsfil inte existerar kommer standardvärden att användas. Konfigurationsfilen använder Python-syntax. Ett exempel finns, se `examples/sample.jhbuildrc`. Kopiera `examples/sample.jhbuildrc` till `~/.config/jhbuildrc` och anpassa efter behov.

Exempelkonfigurationsfilen kommer att göra så att JHBuild bygger modulerna meta-gnome-core och meta-gnome-apps-tested och beroenden från moduluppsättningen gnome-apps. JHBuild kommer att packa upp källträden i `~/jhbuild/checkout/` och installera alla filer i underkatalog under `~/jhbuild/install/`. De två katalogerna måste vara skrivbara.

Konfigurationsvariabler finns dokumenterade i . De vanligast använda variablerna är:

`repos`

  En uppslagsbok som kan användas för att ange en alternativ arkivplats för ett visst arkiv. Denna konfigurationsvariabel är användbar för en modulutvecklare. Som standard kommer JHBuild att checka ut kod från arkiv via en anonym arkivplats. Upplagsverkets nycklar är korta arkivnamn och värdena är alternativa arkivplatssträngar. Till exempel:

      repos['git.gnome.org'] = 'ssh://användarnamn@git.gnome.org/git/'

`moduleset`

  En sträng eller lista av strängar som anger namn(en) för de moduluppsättningar som ska användas. Detta kan antingen vara filnamnet för en moduluppsättning inkluderad med JHBuild (exklusive sökvägen och filändelsen), eller en fullständig HTTP URL till en externt hanterad moduluppsättning. HTTP-URL-moduluppsättningar cachas lokalt. Om en modul med samma namn finns i mer än en moduluppsättning kommer den senast listade att ha högre prioritet. Moduluppsättningar som tillhandahålls av JHBuild uppdateras för att matcha aktuell GNOME-utvecklingsversion.

`modules`

  En lista av strängar som ange vilka moduler som ska byggas. Listan av moduler som faktiskt byggts kommer att expanderas rekursivt till att inkludera alla beroenden om inte kommandot `buildone` används. Standardvärdet är `['meta-gnome-desktop']`.

`checkoutroot`

  En sträng som anger katalogen att packa upp källträden i. Om `buildroot` är inställt till `None` kommer byggen också att ske i denna katalog. Standardvärdet är `~/jhbuild/checkout`.

`prefix`

  En sträng som anger prefixet att installera moduler i. `prefix` måste vara en absolut sökväg. Denna katalog måste vara skrivbar. Standardvärdet är `”~/jhbuild/install”`.

`autogenargs`

  En sträng som innehåller argument som angetts till skriptet `autogen.sh` för alla moduler. Kan åsidosättas för specifika moduler via uppslagsboken `module_autogenargs`.

`cmakeargs`

  En sträng som innehåller argument som angetts till `cmake`-anropet för alla moduler. Kan åsidosättas för specifika moduler via uppslagsboken `module_cmakeargs`.

`makeargs`

  En sträng som listar ytterligare argument som ska anges till `make`. JHBuild kommer automatiskt att lägga till den parallella exekveringsflaggan (`-j`) baserat på antalet tillgängliga CPU-kärnor. Standardvärdet är `””`.

`mesonargs`

  En sträng som innehåller argument som angetts till `meson`-anropet för alla moduler. Kan åsidosättas för specifika moduler via uppslagsboken `module_mesonargs`.

`ninjaargs`

  En sträng som listar ytterligare argument som ska skickas till `ninja`. Standardvärdet är `''`.

### Byggförutsättningar

Innan några moduler kan byggas är det nödvändigt att ha vissa byggverktyg installerade. Vanliga byggverktyg inkluderar GNU Autotools (autoconf, automake, libtool och gettext), GNU-verktygskedjan (binutils, gcc, g++), make, pkg-config och Python, beroende på vilka moduler som ska byggas.

JHBuild kan kontrollera att verktygen är installerade via kommandot `sanitycheck`:

    $ jhbuild sanitycheck

Om detta kommando visar några meddelanden, installera paketet som krävs från din distributions arkiv. En lista över paketnamn för olika distributioner underhålls på GNOME:s wiki. Kör kommandot `sanitycheck` på nytt efter att du installerat distributionens paket för att säkerställa att verktygen är installerade.

### Att använda JHBuild

Efter att installationen är avslutad kan JHBuild användas för att bygga programvara. För att bygga alla moduler som valts i filen `~/.config/jhbuildrc`, kör följande kommando:

    $ jhbuild build

JHBuild kommer att hämta, konfigurera, kompilera och installera varje modul. Om ett fel uppstår någonstans kommer JHBuild att visa en meny och fråga vad som ska hända. Alternativen inkluderar att öppna ett skal för att fixa problemet, köra om bygget från olika steg, hoppa över modulen eller ignorera felet och fortsätta.

Att hoppa över en modul kommer att förorsaka att de moduler som beror på modulen misslyckas.

Nedan finns ett exempel på menyn som visas:

      [1] Kör om fas byggnation
      [2] Ignorera fel och fortsätt installera
      [3] Hoppa över modul
      [4] Starta skal
      [5] Läsa om konfiguration
      [6] Gå till fas ”töm katalogen och börja om”
      [7] Gå till fas ”configure”
      [8] Gå till fas ”clean”
      [9] Gå till fas ”distclean”
    val:

Det är också möjligt att bygga en annan uppsättning moduler och deras beroenden genom att ange modulnamnen som argument till kommandot `build`. För att till exempel bygga gtk+:

    $ jhbuild build gtk+

Om JHBuild avbryts halvvägs genom ett bygg är det möjligt att återuppta bygget för en specifik modul via flaggan `--start-at`:

    $ jhbuild build --start-at=pango

För att bygga en eller flera moduler, utan deras beroenden, tillhandahåller JHBuild kommandot `buildone`. För att kommandot `buildone` ska kunna avslutas korrekt måste alla beroenden ha byggts och installerats tidigare eller tillhandahållas av distributionspaket.

    $ jhbuild buildone gtk+

Under aktiv utveckling av en modul befinner du dig sannolikt i en arbetskatalog för källkoden. `make` kommer att starta byggsystemet och installera modulen. Detta kommer att vara en väsentlig del i cykeln redigera-kompilera-installera-testa.

    $ jhbuild make

För att få en lista över modulerna och deras beroenden som JHBuild kommer att bygg och ordningen de kommer att byggas i, använd kommandot `list`:

    $ jhbuild list

För att få information om en vissa modul, använda kommandot `info`:

    $ jhbuild info gtk+

För att hämta eller uppdatera all programvarukällkod utan att bygga, använda kommandot `update`. Kommandot `update` erbjuder en möjlighet att modifiera källkoden innan den byggs och kan vara användbart om bandbredden till internet varierar.

    $ jhbuild update

Senare kan JHBuild bygga allting utan att hämta ner eller uppdatera källkoden:

    $ jhbuild build --no-network

För att köra ett särskilt kommando med samma miljö som används av JHBuild, använd kommandot `run`:

    $ jhbuild run program

För att starta ett skal med samma miljö som används av JHBuild, använd kommandot `shell`:

    $ jhbuild shell

## JHBuild och GNOME

Detta avsnitt tillhandahåller guidning om hur man bygger, installerar och kör GNOME.

### Bygga GNOME

För att bygga GNOME krävs ett antal utvecklingspaket. Detta inkluderar:

- DocBook XML DTD och XSLT-stilmallar. Detta måste registreras i XML-katalogen (`/etc/xml/catalog`).

- X-bibliotek.

- `libsmbclient` från Samba (används för att bläddra i Windows-nätverk).

- `libbz2` från bzip2.

- `libpng`, `libjpeg` och `libtiff` (använda för bildinläsning).

Om du ska installera distributionspaket och om det gäller för din distribution, installera motsvarande dev- eller devel-paket. En lista över paketnamn för olika distribution underhålls på GNOME:s wiki.

### Kör ett enstaka GNOME-program

Detta avsnitt beskriver detaljerat hur du kör ett enstaka GNOME-program. Programmet kommer att köras i den aktuella skrivbordsmiljön. För att köra programmet i den fullständiga JHBuild GNOME se .

Start ett JHBuild-skal. JHBuild-skalet har alla de nödvändiga miljövariablerna inställda.

    $ jhbuild shell

Bekräfta att rätt program kommer köras. Till exempel:

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

Kör programmet:

    $ gedit &

Alternativ, kör programmet med `run`-kommandot:

    $ jhbuild run gedit

### Att köra GNOME-skrivbordsmiljön

Skapa ett nytt användarkonto för att köra JHBuild GNOME. Att köra JHBuild GNOME som ett annat användarkonto rekommenderas för att undvika problem som orsakas av att användarinställningarna sparas i hemkatalogen. Denna handbok refererar till det nya kontot som gnomedev.

Ställ in JHBuild för det nya gnomedev-kontot. Kopiera eller mjuklänka `~/.config/jhbuildrc` och `~/.local/bin/jhbuild` till hemkatalogen för gnomedev.

Öppna en terminal som användaren gnomedev. För att permanent lägga till `~/.local/bin` till `PATH`-variabeln, kör följande kommando:

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

Testa att JHBuild fungerar:

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

#### Ställ in GNOME att köra från displayhanteraren

Bygg och installera JHBuild GNOME.

Aktivera systemtjänster. JHBuild GNOME kommer att använda `/usr/bin` system D-Bus-demonen och systemtjänsterna i `/usr/share/dbus-1/system-services/`. JHBuild GNOME kommer att använda JHBuild-sessionens D-Bus-demon och tjänsterna i `~/jhbuild/install//share/dbus-1/services/`. Ersätt `~/jhbuild/install` med GNOME-installations`prefix`et i kommandot nedan:

    $ 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

Skapa ett GNOME-startskript i `/usr/bin/gnome-jhbuild-session` med följande, ersätt `~/jhbuild/install` med GNOME-installations`prefix`et:

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

Gör filen `/usr/bin/gnome-jhbuild-session` körbar:

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

För att lägga till en ny sessionspost i displayhanteraren, skapa `/usr/share/xsessions/gnome-jhbuild.desktop` och mata in:

    [Desktop Entry]
    Name=GNOME (JHBuild)
    Comment=Denna session loggar in dig i en GNOME-testsession
    TryExec=/usr/bin/gnome-jhbuild-session
    Exec=/usr/bin/gnome-jhbuild-session
    Icon=
    Type=Application

Starta om `gdm`.

#### Kör GNOME från displayhanteraren

För att köra JHBuild GNOME, välj GNOME (JHBuild)-sessionen i displayhanteraren innan du matar in inloggningsuppgifterna för gnomedev. Om det lyckas kommer JHBuild GNOME att visas. Om det misslyckas, kolla loggfilen. Loggfilen kommer att finnas i `~gnomedev/.cache/gdm/session.log` eller `~gnomedev/.xsession-errors`.

### Statisk analys

JHBuild har stöd för att köra statiska analysverktyg för koden i modulerna allt eftersom de byggts. För att aktivera detta ställ in konfigurationsvariabeln `static_analyzer` på `True` i konfigurationsfilen `.jhbuildrc`.

Om det är aktiverat kommer, varje gång en modul byggts med JHBuild, byggprocessen att omsvepas i en statisk analysator som kommer att generera en rapport för de problem som den hittar i koden. Dessa rapporter sparas som HTML-filer i underkataloger under `/tmp/jhbuild_static_analyzer` (som standard; sökvägen kan ändras via konfigurationsvariabeln `static_analyzer_outputdir`).

Statisk analys fungerar för närvarande bara för moduler som använder autotools som sitt byggsystem. Det kräver att programmet `scan-build` är installerat, men kommandot kan ändras genom att modifiera konfigurationsvariabeln `static_analyzer_template`.

## Kommandoreferens

JHBuild använder en kommandoradssyntax i stil med verktyg så som CVS:

    jhbuild globala-flaggor kommando kommandoargument

De globala JHBuild-flaggorna är:

`-f`, `--file` konfiguration

  Använd en alternativ konfigurationsfil istället för standardvärdet `~/.config/jhbuildrc`.

`-m`, `--moduleset` moduluppsättning

  Använd en annan moduluppsättning än den moduluppsättning som listas i konfigurationsfilen. Denna flagga kan vara en relativ sökväg om moduluppsättningen finns i JHBuilds moduluppsättningsmapp eller en absolut sökväg om den finns någon annanstans.

`--no-interact`

  Fråga inte användaren om något. Denna flagga är användbar om du lämnar ett bygge obevakat, för att säkerställa att bygget inte avbryts.

`--exit-on-error`

  Avsluta omedelbart efter att en modul misslyckas med att bygga. Denna flagga är i första hand användbar i icke-interaktivt läge för att säkerställa att jhbuild inte fortsätter att bygga ytterligare moduler.

`--conditions`

  Modifiera villkorsflaggorna till att vara andra än de som bestämts baserat på OS och de som angetts i jhbuildrc. Modifieringar anges som `-wayland` eller `+docs` för att ta bort eller lägga till villkor. Flera modifieringar kan separeras med ett komma i stil med `--conditions=+docs,-wayland` eller så kan du dela upp dem i flera `--conditions`-argument.

Dessutom kontrollerar JHBuild närvaron av och värdet på följande miljövariabler:

`JHBUILD_RUN_AS_ROOT`

  Som standard körs JHBuild inte när root-användaren används, för att undvika destruktiva åtgärder som kan påverka hela systemet. I vissa fall är det dock acceptabelt att köra JHBuild som root; exempelvis i en behållare eller i en kontinuerlig integrationsmiljö. Att exportera miljövariabeln `JHBUILD_RUN_AS_ROOT` kommer att inaktivera kontrollen av användar-ID vid uppstart.

Kommandospecifika flaggor listas nedan.

### autobuild

Kommandot `autobuild` bygger automatiskt modulerna så som de angetts i konfigurationsfilen och skickar sedan upp resultaten till JhAutobuild.

    jhbuild autobuild --autogen --clean --distcheck --skip=modul --start-at=modul --report-url=rapport-url --verbose

Flaggorna `--autogen`, `--clean`, `--distcheck`, `--skip` och `--start-at` behandlas enligt kommandot `build`.

`--report-url=rapport-url`, `-r rapport-url`

  Denna flagga anger JhAutobuild-URL:en att rapportera till.

`--verbose`, `-v`

  Om angiven kommer JHBuilds utmatning att vara utförligare.

### bootstrap

Kommandot `bootstrap` installerar en uppsättning av byggverktyg. Byggverktygen inkluderar autoconf, automake och liknande verktyg. Den rekommenderade metoden att installera byggverktygen är via din distributions pakethanteringssystem. `bootstrap` bör bara användas om byggverktygen inte tillhandahålls av din distributions pakethanteringssystem, till exempel på Mac OS.

    jhbuild bootstrap

Kommandot `bootstrap` bygger moduler via samma metod som kommandot `build` men använder moduluppsättningen `bootstrap.modules` istället.

Se kommandodokumentationen för `build` för tillgängliga flaggor.

### build

Kommandot `build` bygger ett eller flera paket samt deras beroenden.

    jhbuild build --autogen --clean --check --dist --distcheck --distclean --ignore-suggests --no-network --skip=modul --start-at=modul --tags=taggar -D datum --no-xvfb --try-checkout --no-poison --force --build-optional-modules --min-age=tid --nodeps modul

Om inga modulnamn anges på kommandoraden kommer listan moduler från konfigurationsfilen att användas.

`-a`, `--autogen`

  Kör alltid `autogen.sh` innan du bygger moduler.

`-c`, `--clean`

  Kör `make clean` innan du bygger moduler.

`--check`

  Kör `make check` efter moduler har byggts.

`-d`, `--dist`

  Kör `make dist` efter moduler har byggts.

`--distcheck`

  Kör `make distcheck` efter moduler har byggts.

`--distclean`

  För git-moduler, kör `git clean -dfx` innan du bygger modulerna. För andra moduler, kör `make distclean` innan du bygger modulerna.

  Denna flagga kommer att ta bort alla ändringar som inte checkats in.

`--ignore-suggests`

  Bygg inte mjuka beroenden.

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

  Använd inte nätverket när moduler byggs. Detta kommer att hoppa över hämtning eller uppdateringsstegen i ett bygge. Om en modul inte kan byggas utan nätverksåtkomst kommer bygget av modulen att misslyckas.

`-s`, `--skip`=modul,…

  Bygg inte de listade modulerna. Används för att hoppa över att bygga specifika beroenden.

`--tags`=tagg,…

  Ignorera moduler som inte matchar tagg. Moduler får automatiskt en tagg som matchar namnet på modulens moduluppsättning.

`-t`, `--start-at`=modul

  Börja med den namngivna modulen snarare än i början av listan. Denna flagga är användbar om bygget avbröts.

`-D` datum

  Om det stöd av det underliggande versionshanteringssystemet, uppdatera källkodsträdet till det angivna datumet innan bygget startar. ISO-datumformat krävs, t.ex. `"2009-09-18 02:32Z"`.

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

  Kör grafiska tester på den riktiga X-servern snarare än i en simulerad Xvfb.

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

  Om bygget misslyckas och om det stöds av versionshanteringssystemet, tvinga en utcheckning och kör `autogen.sh` innan du försöker bygga igen.

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

  Om en eller flera av en moduls beroenden misslyckas, tvingar denna flagga JHBuild att försöka bygga modulen ändå.

`-f`, `--force`

  Bygg modulerna även om policyn säger att det inte krävs.

`--build-optional-modules`

  Moduler listade som valfria beroenden, kanske inte behövs för att bygga modulen. Denna flagga tvingar JHBuild att bygga valfria beroenden.

`--min-age`=tid

  Hoppa över moduler som installerats senare än det angivna relativa datumet. Strängformatet för tid är ett antal åtföljt av en enhet. Följande enheter stöds: sekunder (s), minuter (m), timmar (h) och dagar (d). Till exempel kommer `--min-age=2h` att hoppa över moduler som byggts de senaste två timmarna.

`--nodeps`

  Hoppa över saknade systemberoenden. För att ignorera ett enstaka systemberoende lägg till modulen i `skip`.

### make

Kommandot `make` används för att aktivt utveckla i en viss modul. Det kräver att den aktuella katalogen innehåller utcheckad källkod och gör detsamma som `buildone -nf $(basename $(pwd))`.

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

Flaggorna är de samma som de som finns tillgängliga för kommandot `buildone`.

### buildone

Kommandot `buildone` liknar `build` men det bygger inte modulberoenden. Det är användbart för att bygga om en eller flera moduler.

    jhbuild buildone --autogen --clean --check --distcheck --distclean --no-network -D datum --no-xvfb --force --min-age=tid --nodeps modul

Flaggorna `--autogen`, `--check`, `--clean`, `-d`, `--distcheck`, `--distclean`, `--no-network`, `-D`, `-x` och `--nodeps` behandlas på samma sätt som för kommandot `build`.

Åtminstone en modul måste listas på kommandoraden.

### checkbranches

`checkbranches` kontrollerar att modulens grenar är korrekt definierade i versionshanteringssystemet och att grenarna stämmer överens med moduluppsättningen.

    jhbuild checkbranches --branch=gren

`--branch`=gren, `-b` gren

  Grenen som ska kontrolleras.

    $ jhbuild -m gnome-2.20 checkbranches
    libgnomecanvas saknar grendefinition för gnome-2-20
    $

### clean

Kommandot `clean` tömmer byggkatalogerna för en eller flera moduler.

    jhbuild clean --skip=modul --start-at=modul

Om inga modulnamn anges på kommandoraden kommer listan moduler från konfigurationsfilen att användas.

Se kommandodokumentationen för `build` för en beskrivning över tillgängliga flaggor.

### dot

Kommandot `dot` genererar en fil som beskriver den riktade grafen över beroenden mellan en uppsättning av moduler. Denna fil kan sedan behandlas av programvaran GraphViz för att producera ett diagram.

    jhbuild dot --soft-deps --clusters modul

Om inga modulnamn anges på kommandoraden kommer listan moduler från konfigurationsfilen att användas.

Flaggan `--soft-deps` lägger till streckade linjer från modulerna till de mjuka beroendena. Flaggan `--clusters` grupperar moduler från metamoduler tillsammans.

Utdata från dot-kommandot kan skickas vidare till dot-verktyget för att generera en PostScript-fil:

    $ jhbuild dot moduler | dot -Tps > beroenden.ps

Eller en PNG-bild:

    $ jhbuild dot moduler | dot -Tpng > beroenden.png

#### Exempelutmatning från JHBuild dot

### gui

Kommandot `gui` startat ett grafiskt gränssnitt för JHBuild som kan användas för att välja moduler att bygga och ändra ett antal inställningar.

    jhbuild gui

Det grafiska gränssnittet renderas med hjälp av GTK så extra stödbibliotek krävs.

### info

Kommandot `info` visar information om en eller flera moduler.

    jhbuild info --installed modul

Kommandot visar modulnamnet, typen, beroenden, paket som beror på denna modul, källkodskatalogen och tiden den senast installerades med JHBuild. Om tillgängligt kommer också information specifik för modultypen så som CVS-arkiv eller hämtnings-URL att visas.

Om det inte finns någon modul angiven kommer kommandot att visa information om alla de moduler som finns definierade i moduluppsättningen.

Om flaggan `--installed` anges kommer utmatningen att filtreras så att den bara inkluderar installerade paket. Denna utmatning kommer endast att innehålla moduler som faktiskt byggts och installerats av jhbuild. Utmatningen inkluderar inte systemberoenden.

Om flaggan `--installed` angetts tillsammans med ett eller flera modulnamn så kommer bara de installerade modulerna (exklusive systemberoenden) att skrivas ut. Om åtminstone en modul inte är installerad kommer kommandot att avslutas med returvärdet 1.

### list

Kommandot `list` skriver ut den expanderade listan över moduler som kommandot `build` hade byggt.

    jhbuild list -a -r -s --start-at=modul --tags=taggar --ignore-suggests --list-optional-modules modul

Om inga modulnamn anges på kommandoraden kommer listan moduler från konfigurationsfilen att användas.

Flaggorna `--skip`, `--start-at`, `--tags` och `--ignore-suggests` behandlas på samma sätt som för kommandot `build`.

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

  Lista alla modulerna från en moduluppsättning oavsett byggberoenden.

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

  Om en modul är inställd på en gren, visa grennamnet med modulnamnet.

`--list-optional-modules`

  Denna flagga tvingar JHBuild att lista valfria beroenden.

### rdepends

Kommandot `rdepends` visar de omvända beroendena för en modul.

    jhbuild rdepends modul

`--dependencies`

  Visa beroendesökvägen intill modulerna.

`--direct`

  Begränsa utskriften till moduler som direkt beror på den angivna modulen.

### run

Kommandot `run` kör det angivna kommandot i samma miljö som JHBuild använder för att bygga moduler.

    jhbuild run --in-builddir --in-checkoutdir program argument

Om JHBuild används för att bygga GNOME kan detta kommando vara användbart i uppstartsskripten för X.

`--in-builddir`=modul

  Kör kommandot i byggkatalogen för den angivna modulen.

`--in-checkoutdir`=modul

  Kör kommandot i källkodskatalogen för den angivna modulen.

### sanitycheck

Kommandot `sanitycheck` utför ett antal kontroller för att verifiera att byggmiljön är OK.

    jhbuild sanitycheck

Dessa kontroller inkluderar:

- Att utchecknings- och installationsprefixen är skrivbara.

- Att de byggverktyg som krävs är installerade.

- Att vissa vanliga makron är tillgängliga i sökvägar för `aclocal` förknippat med de olika versionerna av `automake`.

- XML-katalogen innehåller DocBook DTD och stilmallar.

### shell

Kommandot `shell` startar användarens skal med samma miljö som JHBuild använder för att bygga moduler.

    jhbuild shell

Detta kommando är ekvivalent med följande:

    $ jhbuild run $SHELL

Miljövariabeln `UNDER_JHBUILD` kommer att vara satt till ”true” (sant) när detta skal är aktivt. Du kan använda närvaron av den variabeln för att anpassa ditt skals prompt för att indikera att du faktiskt är i ett jhbuild-kontrollerat skal. Till exempel kan du vilja lägga följande i din `.bashrc`:

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

Detta kommer att få ditt bash-skal att visa `[jhbuild]` innan din normala prompt vilket gör det enklare att se vilka skal som körs i en jhbuild-miljö.

### sysdeps

Kommandot `sysdeps` visar:

1. en lista över installerade systempaket som kommer att användas under bygget. JHBuild kommer inte att bygga dessa moduler utan väljer att använda systempaketen istället.

2. en lista över paket som krävs. För att påbörja ett bygge måste paketen tillhandahållas av ditt system.

3. en lista över valfria paket. Motsvarande systempaket hittades inte eller var för gamla. JHBuild kommer att bygga modulen. Valfria paket kommer inte att visas om `partial_build` är `False` (falsk).

    jhbuild sysdeps --install

`--install`

  Denna flagga installerar systemberoenden som är beroenden från moduluppsättningen. Installationsmetoden beror på din distribution. Systempaket installeras via PackageKit om tillgängligt. För distributioner som använder APT så som Debian och Ubuntu kräver denna flagga att apt-file är installerat.

#### `sysdeps`-exempel

    $ jhbuild sysdeps
    Systeminstallerade paket som är tillräckligt nya:
      speex (speex.pc krävs=1.2rc1, installerat=1.2rc1)
      lcms2 (lcms2.pc krävs=2.2, installerat=2.2)
    ...
    Paket som krävs:
      Systeminstallerade paket som är för gamla:
        (inga)
      Inget matchande systempaket installerat:
        zlib (zlib.pc krävs=1.2)
    Valfria paket: (JHBuild kommer att bygga de paket som saknas)
      Systeminstallerade paket som är för gamla:
        WebKit (webkitgtk-3.0.pc krävs=1.5.1, installerat=1.4.0)
        ...
      Inget matchande systempaket installerat:
        pulseaudio (libpulse.pc krävs=2.0)
        ...

### tinderbox

Kommandot `tinderbox` liknar `build` men skriver all terminalutmatning till HTML-filer som är lämpliga för publicering på en webbplats. Det kan användas för att ställa in system liknande Mozillas Tinderbox eller Debians Buildd.

    jhbuild tinderbox --autogen --clean --distclean --no-network --output=katalog --skip=modul --start-at=modul -D datum -C -N -f --nodeps modul

Flaggorna `--autogen`, `--clean`, `--distclean`, `--no-network`, `--skip`, `--start-at`, `-D`, `-C`, `-N`, `-f` och `--nodeps` behandlas på samma sätt som för kommandot `build`.

`-o`, `--output`=katalog

  Katalogen som HTML-filer skrivs till. JHBuild kommer att skapa ett index (`index.html`) och en HTML-fil för varje modul.

### uninstall

Kommandot `uninstall` avinstallerar en eller flera moduler.

    jhbuild uninstall modul

### update

Kommandot `update` liknar `build` men utför bara hämtnings- eller uppdateringssteget för moduler utan att bygga dem.

    jhbuild update --skip=modul --start-at=modul --tags=taggar --ignore-suggests -D datum modul

Flaggorna `--skip`, `--start-at`, `--tags`, `--ignore-suggests` och `-D` behandlas på samma sätt som för kommandot `build`.

### updateone

Kommandot `updateone` liknar `update` men det uppdaterar inte modulberoenden. Det är användbart för att uppdatera en eller flera moduler.

    jhbuild updateone -D datum modul

Flaggan `-D` behandlas på samma sätt som för kommandot `build`.

Åtminstone en modul måste listas på kommandoraden.

## Referensmanual för konfigurationsfil

Filen `~/.config/jhbuildrc` använder Pythons standardsyntax. Filen körs och variablerna som definieras i namnrymden används för att kontrollera hur JHBuild beter sig. En uppsättning av standardvärden infogas i namnrymden innan användarens konfigurationsfil körs.

Booleska konfigurationsvariabler ställs in enligt den syntax som visas i följande exempel:

    use_local_modulesets = True

Konfigurationsvariabler som är strängar ställs in via en syntax som visas i följande exempel:

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

Konfigurationsvariabler som är listor ställs in via en syntax som visas i följande exempel:

    skip = ['mozilla', 'pulseaudio']

Konfigurationsvariabler som är ordböcker ställs in via en syntax som visas i följande exempel:

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

### Konfigurationsvariabler

`alwaysautogen`

  Ett booleskt värde som är inställt på `True` (sant) kommer alltid att köra `autogen.sh`. Detta är ekvivalent med att ange flaggan `--autogen` till JHBuild. Standardvärdet är `False` (falskt).

`autogenargs`

  En sträng som innehåller argument som anges till skriptet `autogen.sh` för alla moduler. Kan åsidosättas för specifika moduler via uppslagsboken `module_autogenargs`.

`branches`

  En uppslagsbok som anger vilken gren som används för specifika moduler. Detta är användbart om du gör ändringar på en viss gren för en modul och vill att JHBuild ska använda den grenen istället för den som listats i moduluppsättningen.

  Definitionen av grenar beror på VCS-modulen:

  - CVS: revision. T.ex. `'GREN-PROJEKT-0_8'`

  - Bazaar: URI:n för modulgrenen. T.ex. `'http://bzr.example.net/projekt/gnome-2-28'`

  - Git: en tupel, där första delen är ett valfritt arkiv (eller värdet None (inget)) och andra delen är grenens namn. T.ex. `('git://git.example.net/project', 'gnome-2-28')`

    #### Enkelt exempel

        branches['modulnamn'] = (None, 'grennamn')

  - Subversion: URI:n för modulgrenen. T.ex. `'svn://svn.example.net/projekt/gnome-2-28'`

`builddir_pattern`

  Ett formateringsmönster i `printf`-stil som används för att generera namn för byggkataloger. Detta används bara när separata källkods- och byggträd används. `%s` i formateringssträngen kommer att ersättas med `checkoutdir`. Standardvärdet är `'%s'`.

`buildroot`

  En sträng som anger den överordnade katalogen som byggträd placeras i. Standardvärdet är `~/.cache/jhbuild/build`. Att ställa in värdet till `None` (ingen) får byggen att utföras i källkodsträden.

`buildscript`

  En sträng som ange vilket byggskript som ska användas. Den rekommenderade inställningen är standardvärdet, `terminal`. Bör framför allt inte ställs in till `gtk`.

`build_policy`

  En sträng som anger vilka moduler som ska byggas. De tre möjliga alternativen är `all`, för att bygga alla moduler som begärs, `updated` för att endast bygga de moduler som har ändrats eller `updated-deps` för att bygga moduler som har ändrats eller som har beroenden som har ändrats. Standardvärdet är `updated-deps`.

`checkoutroot`

  En sträng som anger vilken katalog som källkodsträd ska packas upp i. Om värdet inte är `buildroot` (byggrot) kommer byggen att ske i denna katalog också. Standardvärdet är `~/checkout/gnome`.

`checkout_mode`

  En sträng som anger hur utcheckningen görs för kataloger under versionshantering. Standardvärdet är `update`. Detta kan ställas in för varje modul via `module_checkout_mode`. Möjliga värden är `update` (uppdatera katalog med utcheckning i), `clobber` (töm katalog innan källkod checkas ut), `export` (töm katalogen, skapa sedan ett tar-arkiv av källkoden samt eventuella programfixar) och `copy` (checka ut i en annan katalog än den som kommer att byggas).

`cmakeargs`

  En sträng som innehåller argument som anges till `cmake`-anropet för alla moduler. Kan åsidosättas för specifika moduler via uppslagsboken `module_cmakeargs`. Standardvärdet är `''`.

`copy_dir`

  En sträng som anger vilken katalog som ska kopieras till om värdet copy används för `checkout_mode`. Standardvärdet är utcheckningskatalogen.

`export_dir`

  En sträng som anger vilken katalog som ska kopieras till om värdet export används för `checkout_mode`. Standardvärdet är utcheckningskatalogen.

`cvs_program`

  En sträng som anger vilket program som ska användas för CVS-stöd. Detta kan vara `git-cvsimport` eller `cvs`. Standardvärdet är `cvs`.

`disable_Werror`

  Ett booleskt värde (standardvärdet är `True` (sant)) som styr om `--disable-Werror` kommer att skickas till automake-byggen. Många paket använder denna flagga som ett sätt att inaktivera ödesdigra kompilatorvarningar. Värdet `True` (sant) är valt som ett rimligt standardvärde för de som använder jhbuild som ett sätt att få en uppdaterad version av programvarupaket utan att komma in på sidospår på grund av byggfel i andras moduler. Att ställa in detta värde till `False` (falskt) kan vara vettigt för de som använder jhbuild som en del av ett kontinuerligt integrations- eller testsystem.

`dvcs_mirror_dir`

  En sträng som anger en lokal katalog för spegling. JHBuild kommer att skapa lokala speglingar av arkiv i den angivna katalogen. Speglingarna kan delas av flera arkivgrupper vilket sparar utrymme och tid eftersom hårda länkar kommer att användas för lokala kloner. Kommandona `update` och `updateone` kommer att skapa speglingar och hämta nya incheckningar från arkiven på nätet. Detta alternativ stöds endast av Git- och Bazaar-arkiv.

`exit_on_error`

  Ett booleskt värde som anger huruvida bygget ska avslutas omedelbart när en modul misslyckas med att bygga. Detta är framför allt användbart i icke-interaktivt läge för att förhindra ytterligare moduler från att bygga efter att en misslyckas. Att ställa in detta värde till `True` (sant) är ekvivalent med att ange flaggan `--exit-on-error`. Standardvärdet är `False` (falskt).

`extra_prefixes`

  En lista av strängar som anger i precedensordning listan över extra prefix. JHBuild ställer in många miljövariabler (så som `LD_LIBRARY_PATH`, `PKG_CONFIG_PATH` och `XDG_DATA_DIRS`) baserat på variabeln `prefix`. Att lägga till kataloger till `extra_prefixes` kommer att förorsaka att dessa prefix också kommer att inkluderas, vid en lägre precedens än den för JHBuild `prefix`, men vid en högre precedens än systemkatalogerna. Denna variabel är tom som standard förutom på system som installerar programvara i `/usr/local` då den innehåller denna katalog.

`help_website`

  En tupel som anger namn och URL för en hjälpwebbplats. Webbplatsen visas i tinderbox-html för misslyckade moduler. `%(module)s` i URL:en kommer att ersättas med modulnamnet. För att inaktivera ställ in `help_website` till `None` (ingen). Standardvärdet är `('Gnome Live!', 'http://live.gnome.org/JhbuildIssues/%(module)s')`.

`installprog`

  En sträng som anger vilket program som ska användas som ersättning för `/usr/bin/install`.

`ignore_suggests`

  Ett booleskt värde som anger huruvida mjuka beroenden ska hoppas över när beroendeträdet beräknas. Standardvärdet är `False` (falskt).

`interact`

  Ett booleskt värde som anger huruvida bygget ska interagera med användaren. Om detta värde ställs in på `False` (falskt) är det ekvivalent med att ange flaggan `--no-interact`. Standardvärdet är `True` (sant).

`makeargs`

  En sträng som listar ytterligare argument som ska anges till `make`. JHBuild kommer automatiskt att lägga till den parallella exekveringsflaggan (`-j`) baserat på antalet tillgängliga CPU-kärnor. Standardvärdet är `””`.

`makecheck`

  Ett booleskt värde som anger huruvida `make check` ska köras efter `make`. Standardvärdet är `False` (falskt).

`makecheck_advisory`

  Ett booleskt värde som anger huruvida fel vid körning av `make check` endast ska vara rådgivande och inte orsakar byggfel. Standardvärdet är `False` (falskt).

`makeclean`

  Ett booleskt värde som anger huruvida `make clean` ska köras före `make`. Standardvärdet är `False`.

`makedist`

  Ett booleskt värde som anger huruvida `make dist` ska köras efter `make`. Standardvärdet är `False`. Denna inställning är ekvivalent med att ange flaggan `--dist`.

`makedistcheck`

  Ett booleskt värde som anger huruvida `make distcheck` ska köras efter `make`. Standardvärdet är `False`. Denna inställning är ekvivalent med att ange flaggan `--distcheck`.

`mesonargs`

  En sträng som innehåller argument som anges till `meson`-anropet för alla moduler. Kan åsidosättas för specifika moduler via uppslagsboken `module_mesonargs`. Standardvärdet är `''`.

`module_autogenargs`

  En uppslagsbok som mappar modulnamn till strängar som anger argumenten som ska skickas till `autogen.sh`. Inställningen i `module_autogenargs` används istället för den globala `autogenargs`-inställningen. Om en viss modul inte listas i uppslagsboken kommer den globala `autogenargs` att användas.

`module_checkout_mode`

  En uppslagsbok som anger vilket utcheckningsläge som ska användas för moduler. Detta åsidosätter den globala inställningen `checkout_mode`.

`module_cmakeargs`

  En uppslagsbok som mappar modulnamn till strängar som anger argumenten som ska skickas till `cmake`. Inställningen i `module_cmakeargs` används istället för den globala `cmakeargs`-inställningen. Om en viss modul inte listas i uppslagsboken kommer den globala `cmakeargs` att användas.

`module_makeargs`

  En uppslagsbok som mappar modulnamn till strängar som anger argument som ska skickas till `make`. Inställningen `module_makeargs` ersätter värdet från `makeargs`. Om en viss modul inte finns listad i uppslagsboken kommer den globala `makeargs` att användas.

`module_makecheck`

  En uppslagsbok som mappar modulnamn till booleska värden som anger huruvida `make check` ska köras efter `make`. Inställningen `module_makecheck` ersätter värdet från `makecheck`. Om en viss modul inte finns listad i uppslagsboken kommer den globala `makecheck` att användas.

`module_mesonargs`

  En uppslagsbok som mappar modulnamn till strängar som anger argumenten som ska skickas till `meson`. Inställningen i `module_mesonargs` används istället för den globala `mesonargs`-inställningen. Om en viss modul inte listas i uppslagsboken kommer den globala `mesonargs` att användas.

`module_ninjaargs`

  En uppslagsbok som mappar modulnamn till strängar som anger argument som ska skickas till `ninja`. Inställningen `module_ninjaargs` ersätter värdet från `ninjaargs`. Om en viss modul inte finns listad i uppslagsboken kommer den globala `ninjaargs` att användas.

`module_nopoison`

  En uppslagsbok som mappar modulnamn till booleska värden. Om en modul är inställd på `True` (sant) kommer JHBuild att försöka att bygga modulberoenden även om den angivna modulen misslyckades. Inställningen `module_nopoison` ersätter värdet från `nopoison`. Om en viss modul inte listas i uppslagsboken kommer den globala `nopoison` att användas.

`module_extra_env`

  En uppslagsbok som mappar modulnamn till ordböcker med extra miljövariabler som skickas till exekverande kommandon för modulen.

`module_static_analyzer`

  Uppslagsbok som mappar modulnamn till booleska värden som indikerar huruvida statisk analys ska genomföras medan modulen byggs. Detta låter det globala konfigurationsalternativet `static_analyzer` åsidosättas.

`modules`

  En lista av strängar som ange vilka moduler som ska byggas. Listan av moduler som faktiskt byggts kommer att expanderas rekursivt till att inkludera alla beroenden om inte kommandot `buildone` används. Standardvärdet är `['meta-gnome-desktop']`.

`moduleset`

  En sträng eller lista av strängar som anger namn(en) för de moduluppsättningar som ska användas. Detta kan antingen vara filnamnet för en moduluppsättning inkluderad med JHBuild (exklusive sökvägen och filändelsen), eller en fullständig HTTP URL till en externt hanterad moduluppsättning. HTTP-URL-moduluppsättningar cachas lokalt. Om en modul med samma namn finns i mer än en moduluppsättning kommer den senast listade att ha högre prioritet. Moduluppsättningar som tillhandahålls av JHBuild uppdateras för att matcha aktuell GNOME-utvecklingsversion.

`modulesets_dir`

  En sträng som anger katalogen som innehåller moduluppsättningarna som ska användas. Standardvärdet är katalogen `modulesets/` i JHBuild-källkoden.

`nice_build`

  Kör byggen under prioriteten `SCHED_IDLE` i Linux och `nice` för andra Unix:ar. Detta kan dramatiskt förbättra skrivbordsinteraktiviteten för parallella byggen medan de har försumbar inverkan på bygghastighet.

`ninjaargs`

  En sträng som listar ytterligare argument som ska skickas till `ninja`. Standardvärdet är `''`.

`nobuild`

  Ett booleskt värde som om det är inställt på `True` (sant) kommer JHBuild inte att bygga moduler utan enbart hämta och packa upp källkoden. Standardvärdet är `False` (falskt).

`nonetwork`

  Ett booleskt värde som anger huruvida nätverksåtkomst är tillåten. Detta påverkar utcheckning eller uppdatering av CVS-moduler, hämtning av tar-arkiv och uppdatering av moduluppsättningar. Att ställa in denna på `True` (sant) är ekvivalent med att ange flaggan `--no-network`. Standardvärdet är `False` (falskt).

`nonotify`

  Ett booleskt värde som anger huruvida aviseringar ska skickas ut via aviseringsdemonen. Om denna är inställd på `False` (falskt) kommer aviseringar att skickas ut. Standardvärdet är `True` (sant).

`nopoison`

  Ett booleskt värde som om det är inställt på `True` (sant) kommer att få JHBuild att försöka bygga moduler även om en eller flera av modulens beroenden misslyckas med att bygga. Detta alternativ är ekvivalent med flaggan `--no-poison`. Standardvärdet är `False` (falskt).

`notrayicon`

  Ett booleskt värde som anger huruvida en ikon ska visas i systemfältet med hjälp av Zenity. Om detta är inställt på `False` (falskt) kommer en ikon att visas. Standardvärdet är `True` (sant).

`noxvfb`

  Ett booleskt värde som om det är inställt på `True` (sant) kommer att få JHBuild att köra grafiska tester på den riktiga X-servern snarare än att använda `Xvfb`. Denna flagga är ekvivalent med att ange `--no-xvfb`. Standardvärdet är `False` (falskt).

`partial_build`

  Ett booleskt värde som om det är inställt på `True` (sant) kommer att få JHBuild att inte bygga modulberoenden om motsvarande systempaket finns installerade och i tillräckligt ny version. Standardvärdet är `True` (sant).

`prefix`

  En sträng som anger prefixet att installera moduler i. `prefix` måste vara en absolut sökväg. Denna katalog måste vara skrivbar. Standardvärdet är `”~/jhbuild/install”`.

`pretty_print`

  Ett booleskt värde som anger huruvida underprocessers utmatning ska formateras snyggt. Endast CVS-utmatning har stöd för snygg formatering. Inaktivera om snygg formatering förorsakar problem. Standardvärdet är `True` (sant).

`print_command_pattern`

  En sträng som visas innan JHBuild kör ett kommando. `%(command)s` i strängen kommer att ersättas med kommandot som ska köras. `%(cwd)s` i strängen kommer att ersättas med aktuell arbetskatalog. Standardvärdet är `'%(command)s'`.

`progress_bar`

  Ett booleskt värde som anger huruvida en förloppsindikator ska visas i tyst läge. Standardvärdet är `True` (sant).

`quiet_mode`

  Ett booleskt värde som om det är inställt på `True` (sant) inaktiverar utmatningen av kommandon som körs. Standardvärdet är `False` (falskt).

`repos`

  En uppslagsbok som anger en alternativ arkivplats för ett visst arkiv. Denna konfigurationsvariabel är användbar för en modulutvecklare. Som standard kommer JHBuild att checka ut kod från arkiv via en anonym arkivplats. Uppslagsboksnycklarna är korta arkivnamn och värdena är strängar med de alternativa arkivplatserna. Till exempel:

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

`shallow_clone`

  Ett booleskt värde som anger huruvida JHBuild ska föredra mindre hämtningar för versionshantering. Ekvivalent med `git clone --depth 1` eller `bzr co --light`. Standardvärdet är `False`.

`skip`

  En lista över moduler som ska hoppas över. Denna kommandoradsflagga, `--skip`, utökar listan. Denna lista är tom som standard. Om listan innehåller det speciella värdet `'*'` kommer JHBuild att hoppa över alla moduler som inte uttryckligen listas i variabeln `modules`. Detta kan vara användbart om du vill bygga moduler utan deras implicita beroenden.

`static_analyzer`

  Ett booleskt värde som om det är inställt på `True` (sant) kör ett statiskt analysverktyg för varje modul medan den byggs. Standardvärdet är `False` (falskt).

`static_analyzer_outputdir`

  Rotkatalogen under vilken statiska analysrapporter kommer att sparas (om `static_analyzer` är `True` (sant)). Standardvärdet är `/tmp/jhbuild_static_analyzer`.

`static_analyzer_template`

  Kommandomall för den statiska analysatorn. Denna får enligt `printf`-stil parametrarna `outputdir` (värdet från konfigurationsvariabeln `static_analyzer_outputdir`) och `module` (namnet på modulen som byggs för närvarande) ersatta. Det resulterande kommandot används som prefix till `make` när en modul byggs. Standardvärdet är `scan-build`.

`sticky_date`

  En sträng som om den är satt och om det stöds av det underliggande versionshanteringssystemet kommer att få JHBuild att uppdatera källkodsträdet till det angivna datumet innan bygge. Ett datum enligt ISO-format krävs, t.ex. `'åååå-mm-dd'`. Standardvärdet är `None` (inget).

`svn_program`

  En sträng som anger vilket program som ska användas för subversion-utmatning. Denna kan vara `svn`, `git-svn` eller `bzr`. Standardvärdet är `svn`.

`system_libdirs`

  En lista av strängar som anger systembibliotekssökvägar. Dessa används när standardvärdet för vissa miljövariabler ställs in, till exempel `PKG_CONFIG_PATH`.

`tarballdir`

  En sträng som om den är inställd kommer att få tar-arkiv att hämtas till den angivna katalogen istället för `checkoutroot`. Detta är användbart om du har flera JHBuild-miljöer eller regelbundet rensar ur `checkoutroot` och vill reducera använd bandbredd. Standardvärdet är `'~/.cache/jhbuild/downloads'`.

`tinderbox_outputdir`

  En sträng som anger vilken katalog som används för att lagra `jhbuild tinderbox`-utmatning. Denna sträng kan åsidosättas av flaggan `--output`. Standardvärdet är `None` (ingen), så antingen måste kommandoradsflaggan eller denna variabel användas i konfigurationsfilen.

`trycheckout`

  Ett booleskt värde som om det är inställt på `True` (sant) får JHBuild att automatiskt försöka lösa fel genom att 1) köra `autogen.sh` igen eller 2) checka ut en nyare version av en modul från versionshanteringssystemet. Denna inställning är ekvivalent med att ange flaggan `--try-checkout`.

`use_local_modulesets`

  Ett booleskt värde som anger att de moduluppsättningar som checkats ut samtidigt med JHBuild-källkoden ska användas, istället för att hämta dem i farten från GNOME:s versionshanteringssystem. Standardvärdet är `False` (falskt).

`xvfbargs`

  En sträng som listar argument som ska skickas till `Xvfb` om grafiska tester ska köras.

`conditions`

  En mängd villkor (strängar) som kan påverka modulerna som byggs och flaggorna som används för att bygga dem. Du bör använda `conditions.add()` och `conditions.discard()` för att modifiera listan du vill göra ändringar i.

  Originaluppsättningen av villkor som bestäms på OS-basis och kan modifieras via kommandoradsargumentet `--conditions=`. Ändringarna som görs via `--conditions` syns när jhbuildrc läses in så du kan ställa in andra variabler baserat på det aktuella värdet för uppsättningen men `--conditions` kommer att tillämpas igen efter att nya ändringar görs från jhbuildrc.

### Andra strukturer i konfigurationsfilen

Förutom variablerna ovan finns det andra inställningar som kan finnas i konfigurationsfilen:

`os.environ`

  En uppslagsbok som representerar miljön. Denna miljö skickas vidare till processer som JHBuild startar.

  Ett par inflytelserika miljövariabler är `CPPFLAGS`, `CFLAGS` `INSTALL` och `LDFLAGS`. Till exempel:

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

`addpath`(`miljövariabel`, `sökvägsnamn`)

  Detta kommer att lägga till en katalog till miljövariabeln `PATH`. `addpath` kommer att korrekt hantera fallet när miljövariabeln är tom från början (att ha ett extra kolon i början eller slutet på en miljövariabeln kan få oförutsedda konsekvenser).

`prependpath`(`miljövariabel`, `sökvägsnamn`)

  Efter att ha behandlat konfigurationsfilen kommer JHBuild att förändra vissa sökvägar baserat på variabler så som `prefix` (t.ex. genom att lägga till `$prefix/bin` i början av `PATH`).

  Funktionen `prependpath` fungerar som `addpath` förutom att miljövariabeln modifieras efter att JHBuild har gjort sina ändringar i miljön.

## Syntax för moduluppsättningsfilen

JHBuild använder XML-filer för att beskriva beroendena mellan moduler. Ett RELAX-NG-schema och dokumenttypsdefinition inkluderas med JHBuild i katalogen `modulesets/`. RELAX-NG-schemat kan användas för att redigera moduluppsättningsfilen via `nxml-mode` i Emacs.

Toppnivåelementet i en moduluppsättningsfil är elementet `moduleset`. Ingen XML-namnrymd används. Elementen under toppnivån finns i tre typer: modulkällor, inkluderingssatser och moduldefinitioner.

Innehållet i moduluppsättningsfilen kan inkluderas villkorat genom att använda taggen <if> för att omge det villkorade innehållet. Det är för närvarande endast möjligt att styra inkluderingen med huruvida en flagga är satt eller ej genom <if condition-set='cond'> eller <if condition-unset='cond'>. Villkoren sätts som standard per OS-basis men kan påverkas genom att ange variabeln `condition` i jhbuildrc eller kommandoradsargumentet `--conditions=`.

### Modulkällor

Snarare än att lista den fullständiga platsen för varje modul listas ett antal ”modulkällor” i moduluppsättningen och de refereras sedan till vid namn i moduldefinitionerna. Detta reducerar mängden redundant information i moduluppsättningen och gör det enklare för en användare att ange en alternativ källa för de modulerna (för CVS och Subversion är det vanligt för utvecklare och användare att använda olika åtkomstmetoder för arkiv).

Elementet `repository` används för att beskriva alla typer av arkiv. Elementet `branch` används inuti moduldefinitioner för att ange ytterligare inställningar.

    <repository name="namn"
      type="typ"
      [ default="standard" ]
      [ password="lösenord" ]
      [ cvsroot="cvsrot" ]
      [ archive="arkiv" ]
      [ href="href" ]
      [ server="server" ]
      [ database="databas" ]
      [ defbranch="standardgren" ]
      [ trunk-template="stammall" ]
      [ branches-template="grenmall" ]
      [ tags-template="taggmall" ]
      [ developer-href-example="utvecklar-href-exempel" ] />

Attributet `name` är en unik identifierare för arkivet.

Attributet `default` anger huruvida detta arkiv är standardkällan för denna moduluppsättning.

Attributet `type` anger arkivtypen. Den kan vara en av: `bzr`, `cvs`, `darcs`, `fossil`, `git`, `hg`, `mnt`, `svn`, `tarball`. Andra attribut beror på `type`, så väl som `branch` som används i moduldefinitioner. Dessa beskrivs nedan i underkapitlen om arkivtyper.

Attributet `developer-href-example` används för att ange formatet för URL:en för arkivet som används av utvecklare. Detta är endast för information.

Elementet `branch` används inuti moduldefinitioner.

    <branch
      [ repo="arkiv" ]
      [ module="modulnamn" ]
      [ checkoutdir="utcheckningskatalog" ]
      [ revision="revision" ]
      [ tag="tagg" ]
      [ update-new-dirs="uppdatera-nya-kataloger" ]
      [ override-checkoutdir="åsidosätt-utcheckningskatalog" ]
      [ subdir="underkatalog" ]
      [ branch="gren" ]
      [ version="version" ]
      [ size="storlek" ]
      [ source-subdir="underkatalog-för-källkod" ]
      [ hash="hash" ]/>

Alla attribut har vettiga standardvärden och beror på modul- och arkivdefinitionerna. Vanliga attribut beskrivs här.

Attributet `repo` används för att ange arkivnamn som inte är standard.

Attributet `module` används för att ange modulnamn som ska checkas ut från arkivet. Standardvärdet är modul-ID:t.

Attributet `checkoutdir` används för att ange katalognamnet där utcheckning ska ske. Standardvärdet är modul-ID:t.

Andra attribut beskrivs nedan

#### Bazaar

Denna arkivtyp används för att definiera Bazaar-arkiv. Det rekommenderas att Bazaar 1.16 eller senare används.

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

Ytterligare attribut är: `trunk-template` (standardvärdet är `"%(module)s"`) och `branches-template` (standardvärdet är `"%(module)s/%(branch)s`"). Dessa attribut används för att ange mallar för konstruktion av URL:er. Ett `branch`-element i moduldefinitionen kan ange `branch`- och `user`-attribut. Dessa värden kommer att ersättas i mallarna. Om någotdera av dem är definierade används `branches-template`, annars används `trunk-template`. På detta sättet kan du åsidosätta arkiven som används för att bygga moduler från din personliga gren eller bygga många moduler från ett arkiv med icke-standardiserad layout.

Ett extra `branch` accepterar attributet `revspec` för att ankra vid en viss revision. Vilken giltig `bzr revspec` som helst accepteras, till exempel `date:yesterday, -5, tag:0.1` för att få första revisionen sedan igår, 5 incheckningar bakom toppen eller taggen ”0.1”. Se `bzr help revisionspec` för alla möjliga värden.

Ett exempel med ett arkiv som har `template`-attribut definierade:

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

Exempel med `branch`-element för ovanstående arkiv:

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

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

#### CVS

Denna arkivtyp används för att definiera ett CVS-arkiv.

Attributet `password` används för att ange lösenordet för arkivet.

Attributet `cvsroot` används för att ange roten för arkivet.

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

Ytterligare attribut är: `revision`, `update-new-dirs` och `override-checkoutdir`.

#### Darcs

Denna arkivtyp används för att definiera ett Darcs-arkiv.

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

#### Git

Denna arkivtyp används för att definiera ett Git-arkiv.

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

Den tillåter följande attribut för `branch`-elementet:

Attributet `revision` används för att ange en lokal eller fjärrspårande gren att växla till i uppdateringsfasen. Standardvärdet är ”master”. Det är möjligt att åsidosätta detta attribut med konfigurationsvariabeln `branches`. Växlingen kommer endast att utföras om den aktuella grenen spårar en fjärrgren för att inte förstöra ditt eget arbete.

Attributet `tag` används för att ange en revision att ovillkorligen checka ut i uppdateringsfasen. Den åsidosätter attributet `revision`.

    <branch repo="git.freedesktop.org" module="swfdec/swfdec"
            checkoutdir="swfdec"
            revision="local-or-remote-branch"
            tag="tree-ish"/>

#### Mercurial

Denna arkivtyp används för att definiera ett Mercurial-arkiv.

    <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

Denna arkivtyp används för att definiera ett Monotone-arkiv.

Attributet `server` används för att ange arkivservern.

Attributet `database` används för att ange databasen som ska användas för arkivet.

Attributet `defbranch` används för att ange grenen i arkivet som ska användas.

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

#### Subversion

Denna arkivtyp används för att definiera ett Subversion-arkiv.

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

Den tillåter en `revision` på elementet `branch`. Detta attribut definierar grenen som ska checkas ut eller, om det är ett nummer, en specifik revision att checka ut.

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

Det är möjligt att ange en anpassad `svn`-layout via `trunk-template` (standardvärdet är "%(module)s/trunk"), `branches-template` (standardvärdet är "%(module)s/branches/%(branch)s") och `tags-template` (standardvärdet är "%(module)s/tags/%(tag)s")

#### System

Denna arkivtyp används för att definiera ett falskt systemarkiv. Ett systemarkiv krävs för att skapa `systemmodules`.

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

#### Tar-arkiv

Denna arkivtyp används för att definiera ett arkiv med tar-arkiv.

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

Den tillåter följande attribut för `branch`-elementet:

Attributet `module` anger filen som ska hämtas och kompileras medan attributet `version` anger modulversionen.

Attributen `size` och `hash` så väl som det föråldrade attributet `md5sum` är valfria. Om dessa attribut finns används de för att kontrollera att källkodspaketen hämtats korrekt.

Attributet `rename-tarball` kan användas för att byta namn på tar-arkivfilen vid hämtning, ifall det ursprungliga namnet står i konflikt med en annan modul.

Ett godtyckligt antal `patch`-element kan nästlas inuti `branch`-elementet. Dessa programfixar appliceras i sekvens på källkodsträdet efter uppackning. Attributet `file` anger filnamnet för programfixen och attributet `strip` anger hur många nivåer av kataloger som ska tas bort när programfixen appliceras.

För moduluppsättningar som följer med JHBuild letas programfixfiler upp i katalogen `jhbuild/patches/`; för moduluppsättningar som refereras till via URI kommer programfixfiler att letas efter i samma katalog som moduluppsättningsfilen eller i dess underkatalog `patches/`. Det är också möjligt för attributet `file` att ange en URI, då den kommer att hämtas från den platsen.

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

Ett `branch`-element för ett tar-arkiv får också innehålla `quilt`-element vilka anger nästlade `branch` som ska importeras.

### Inkludering av andra moduluppsättningar

JHBuild tillåter en moduluppsättning att inkludera innehållet från en annan genom att referera till den via `include`-elementet.

    <include href="uri"/>

`href` är en URI-referens till moduluppsättningen som ska inkluderas, relativt till filen som innehåller `include`-elementet.

Endast moduldefinitioner importeras från den refererade moduluppsättningen - modulkällor importeras inte. Flera nivåer av inkluderingar tillåts, men inkluderingsloopar tillåts inte (det finns ingen kod som hanterar loopar för tillfället).

### Moduldefinitioner

Det finns olika typer av moduldefinitioner som kan användas i en moduluppsättningsfil och listan kan enkelt utökas. Endast de vanligaste kommer att nämnas här.

De består alla i grunden av ett `branch`-element som beskriver hur man hämtar modulen samt `dependencies`-, `suggests`- och `after`-element för att deklarera beroendena för modulen.

Moduler som listas i elementet `dependencies` kommer att läggas till i modullistan för `jhbuild build` om den inte redan finns där och säkerställa att den beroende modulen byggs först.

Efter att ha genererat modullistan kommer moduler som listas i `suggests`-elementet att användas för att vidare sortera modullistan (även om inga ytterligare moduler dras in). Detta är avsett för fall när en modul har valfria beroenden på en annan modul.

#### autotools

Elementet `autotools` används för att definiera en modul som ska kompileras via byggsystemet GNU Autotools.

    <autotools id="id"
    	      [ autogenargs="autogen-argument" ]
    	      [ makeargs="make-argument" ]
    	      [ makeinstallargs="makeinstall-argument" ]
    	      [ autogen-sh="autogen-sh" ]
    	      [ makefile="makefil" ]
    	      [ skip-autogen="hoppa-över-autogen" ]
    	      [ skip-install="hoppa-över-installation" ]
    	      [ uninstall-before-install="avinstallera-innan-installation" ]
    	      [ autogen-template="autogen-mall" ]
    	      [ check-target="check-mål" ]
    	      [ supports-non-srcdir-builds="har-stöd-för-bygge-utanför-källkodskatalogen" ]
    	      [ force-non-srcdir-builds="tvinga-bygge-utanför-källkodskatalogen" ]
    	      [ supports-unknown-configure-options="har-stöd-för-okända-configureflaggor" ]
    	      [ supports-static-analyzer="har-stöd-för-statisk-analysator" ]>

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

      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <after>
        <dep package="modulnamn"/>
        ...
      </after>

    </autotools>

Attributen `autogenargs` och `makeargs` och `makeinstallargs` används för att ange ytterligare argument som skickas till `autogen.sh`, `make` respektive `make install`.

Attributet `autogen-sh` anger namnet på autogen.sh-skriptet som ska köras. Värdet `autoreconf` kan användas om modulen inte har något `autogen.sh`-skriptekvivalent. I det fallet kommer JHBuild att köra `autoreconf -fi` följt av det riktiga `configure`-kommandot. `skip-autogen` väljer huruvida autogen.sh ska köras, det är ett booleskt värde med ett extra `never`-värde som berättar för JHBuild att det aldrig ska hoppa över att köra `autogen.sh`. `skip-install` är ett booleskt attribut som anger huruvida `make install`-kommandot ska hoppas över för modulen. `makefile` anger filnamnet på makefilen som ska användas.

`uninstall-before-install` anger att gamla installerade filer från modulen ska tas bort innan installationssteget körs. Detta kan användas för att kringgå ett problem där libtool försöker att länka ett bibliotek som det håller på att installera mot ett annat bibliotek som det installerar, men eftersom jhbuild använder DESTDIR hittas det gamla installerade biblioteket istället. Nackdelen med att ange detta är att det kan skapa problem om användaren för närvarande kör kod som beror av de installerade filerna från modulen.

Attributet `supports-non-srcdir-builds` används för att markera moduler som inte kan byggas korrekt i en separat källkodskatalog.

Attributet `force-non-srcdir-builds` används för att markera moduler som inte kan byggas korrekt från källkodskatalogen, men som kan byggas utanför den.

Attributet `autogen-template` kan användas om du behöver mer detaljkontroll över kommandoraden för autogen. Det är en python-formaterad sträng i vilken följande variabler kommer att ersättas: `srcdir`, `autogen-sh`, `prefix`, `libdir` och `autogenargs`. Här är till exempel standardmallen för autogen:

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

Attributet `check-target` måste anges (med ett falskt värde) för moduler som inte har ett `make check`-mål.

Attributet `supports-static-analyzer` måste anges (med ett falskt värde) för moduler som inte har stöd för att byggas under ett statiskt analysverktyg så som `scan-build`.

Attributet `supports-unknown-configure-options` används för att markera moduler som kommer att misslyckas med fel om en okänd flagga skickas med till `configure`. Globala flaggor för configure kommer inte att användas för den modulen.

#### cmake

Elementet `cmake` används för att definiera en modul som byggs via byggsystemet CMake.

      <cmake id="modulnamn"
                [ cmakeargs="cmake-argument" ]
                [ ninjaargs="ninja-argument" ]
                [ makeargs="make-argument" ]
                [ skip-install="hoppa-över-installation" ]
                [ cmakedir="cmake-katalog" ]
                [ use-ninja="använd-ninja" ]
                [ force-non-srcdir-builds="tvinga-icke-källkat-byggen" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <after>
        <dep package="modulnamn"/>
        ...
      </after>
    </cmake>

Attributet `cmakeargs` används för att ange ytterligare argument som ska skickas till `cmake`.

Attributet `ninjaargs` används för att ange ytterligare argument som ska skickas till `ninja`.

Attributet `makeargs` används för att ange ytterligare argument som ska skickas till `make`.

Attributet `cmakedir` anger underkatalogen där cmake kommer köras i förhållande till srcdir.

Attributet `force-non-srcdir-builds` används för att markera moduler som inte kan byggas korrekt från källkodskatalogen, men som kan byggas utanför den.

Attributet `use-ninja` används för att markera moduler som ska byggas via Ninja-bakänden för cmake, istället för Make-bakänden. Standard är att använda Ninja-bakänden.

#### Meson

Elementet `meson` används för att definiera en modul som konfigureras med byggsystemet Meson och byggs med byggverktyget Ninja.

      <meson id="modulnamn"
                [ mesonargs="meson-argument" ]
                [ ninjaargs="ninja-argument" ]
                [ skip-install="hoppa-över-installation" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <after>
        <dep package="modulnamn"/>
        ...
      </after>
    </meson>

Attributet `mesonargs` används för att ange ytterligare argument som ska skickas till `meson`.

Attributet `ninjaargs` används för att ange ytterligare argument som ska skickas till `ninja`.

#### distutils

Elementet `distutils` används för att definiera en modul som byggs med pythons distutils.

    <distutils id="modulnamn"
                [ supports-non-srcdir-builds="yes|no" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <after>
        <dep package="modulnamn"/>
        ...
      </after>
    </distutils>

#### linux

Elementet `linux` definierar en modul som används för att bygga en linux-kärna. Därtill kan en separat kärnkonfiguration väljas via underelementet `kconfig`.

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

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

      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <after>
        <dep package="modulnamn"/>
        ...
      </after>

      <kconfig [ repo="arkiv" ]
    	    version="version"
    	    [ module="modul" ]
    	    [ config="konfiguration" ] />

    </linux>

#### perl

Elementet `perl` används för att bygga perl-moduler.

Attributet `makeargs` används för att ange ytterligare argument som ska skickas till `make`.

    <perl id="modulnamn"
    	 [ makeargs="make-argument" ]>

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

      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <after>
        <dep package="modulnamn"/>
        ...
      </after>

    </perl>

#### systemmodule

Elementet `systemmodule` används för att ange moduler som måste tillhandahållas av systemet. Modulen bör finnas installerad av din distributions pakethanteringssystem.

    <systemmodule id="modulnamn">
      <pkg-config>pkg-config.pc</pkg-config>

      <branch repo="system" version="version" />
    </systemmodule>

Om systemmodulen inte tillhandahåller en pkg-config-fil kan en `systemdependencies`-tagg användas för att identifiera beroendena. Två värden stöds för `type`-attributet för `dep`-taggen:

1. Värdet `path`. Sökvägen genomsöks efter ett matchande programnamn.

2. Värdet `c_include`. C-inkluderingssökvägen genomsöks efter matchande huvudnamn. `name` får inkludera en underkatalog. C-inkluderingssökvägen kan modifieras genom att sätta `CPPFLAGS` inom konfigurationsvariablerna `cflags` eller `module_autogenargs`.

    <systemmodule id="modulnamn">
      <branch repo="system" version="version" />
      <systemdependencies>
        <dep type="path" name="körbart-program" />
      </systemdependencies>
    </systemmodule>

    <systemmodule id="modulnamn">
      <branch repo="system" version="version" />
      <systemdependencies>
        <dep type="c_include" name="huvudnamn" />
      </systemdependencies>
    </systemmodule>

Om systemmodulen kan installeras på olika platser eller installeras under olika namn av olika distributioner kan taggen `altdep` användas som underelement till `dep`-taggen för att ange alternativa platser eller namn. Taggen `altdep` har stöd för samma attribut som taggen `dep`.

    <systemmodule id="modulnamn">
      <branch repo="system" version="version" />
      <systemdependencies>
        <dep type="path" name="körbart-programnamn">
          <altdep type="path" name="alternativt-körbart-programnamn-1" />
          <altdep type="path" name="alternativt-körbart-programnamn-2" />
          ...
        <dep>
      </systemdependencies>
    </systemmodule>

    <systemmodule id="modulnamn">
      <branch repo="system" version="version" />
      <systemdependencies>
        <dep type="c_include" name="huvudnamn">
          <altdep type="c_include" name="alternativt-huvudnamn-1" />
          <altdep type="c_include" name="alternativt-huvudnamn-2" />
          ...
        <dep>
      </systemdependencies>
    </systemmodule>

#### waf

Elementet `waf` används för att definiera en modul som byggs med byggsystemet Waf.

Attributet `waf-command` används för att ange waf-kommandoskriptet som ska användas; standardvärdet är `waf`.

Attributet `python-command` används för att ange vilket körbart Python-program som ska användas; standardvärdet är `python`. Detta är användbart för att bygga moduler med version 3 av Python.

    <waf id="modulnamn">
    	 [ python-command="python-kommando" ]
    	 [ waf-command="waf-kommando" ]>
      <branch [ ... ] >
        [...]
      </branch>

      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <after>
        <dep package="modulnamn"/>
        ...
      </after>
    </waf>

#### testmodule

Elementet `testmodule` används för att skapa en modul som kör en svit av tester via LDTP eller Dogtail.

    <testmodule id="id"
    	       type="typ">

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

      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <after>
        <dep package="modulnamn"/>
        ...
      </after>

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

    </testmodule>

Attributet `type` anger typen av tester som ska köras i modulen. ”dogtail” använder python för att anropa alla .py-filer. ”ldtp” anropar ”ldtprunner run.xml”.

Om inte noxvfb-konfigurationsflaggan är inställd kommer en Xvfb-server att startas för att köra testerna i.

#### metamodule

Elementet `metamodule` definierar en modul som egentligen inte gör någonting. Det enda syftet med en modul av denna typ är dess beroenden.

meta-gnome-desktop beror till exempel på alla nyckelkomponenter i GNOME-skrivbordet, så om du berättar för JHBuild att det ska installeras så installeras den fullständiga skrivbordsmiljön.

    <metamodule id="modulnamn">
      <dependencies>
        <dep package="modulnamn"/>
        ...
      </dependencies>
      <suggests>
        <dep package="modulnamn"/>
        ...
      </suggests>
    </metamodule>

Attributet `id` anger namnet på modulen. Barnelementen hanteras på samma sätt som för `autotools`.

### Föråldrade element

#### Modulkällor

##### cvsroot

Elementet `cvsroot` är nu föråldrat - elementet `repository` bör användas istället.

Elementet `cvsroot` används för att beskriva ett CVS-arkiv.

      <cvsroot name="rotnamn"
               [ default="yes|no" ]
               root="anonym-cvrot"
               password="anonymt-lösenord"/>

Attributet `name` bör vara en unik identifierare för CVS-arkivet.

Attributet `default` berättar huruvida detta är standardmodulkällan för den moduluppsättningsfilen.

Attributet `root` listar CVS-roten som används för anonym tillgång till detta arkiv, och attributet `password` anger lösenordet som ska användas för anonym tillgång.

##### svnroot

Elementet `svnroot` är nu föråldrat - elementet `repository` bör användas istället.

Elementet `svnroot` används för att beskriva ett Subversion-arkiv.

      <svnroot name="rotnamn"
               [ default="yes|no" ]
               href="anonym-svn-rot"/>

Attributet `name` bör vara en unik identifierare för Subversion-arkivet.

Attributet `default` berättar huruvida detta är standardmodulkällan för den moduluppsättningsfilen.

Attributet `href` listar bas-URL:en för arkivet. Detta kommer troligtvis antigen att vara en `http`-, `https`- eller en `svn`-URL.

#### Föråldrade modultyper

Detta avsnitt beskriver föråldrade element, de kanske fortfarande används i existerande moduluppsättningar men det rekommenderas att inte använda dem längre.

##### tar-arkiv

Detta föråldrade element är bara ett tunt omslag kring både modultypen `autotools` och arkivtypen `tarball`.

Elementet `tarball` används för att definiera en modul som ska byggas från ett tar-arkiv.

      <tarball id="modulnamn"
                  [ version="version" ]
                  [ checkoutdir="utcheckningskatalog" ]
                  [ autogenargs="autogen-argument" ]
                  [ makeargs="make-argument" ]
                  [ autogen-sh="autogen-sh" ]
                  [ supports-non-srcdir-builds="yes|no" ]>
        <source href="käll-url"
                [ size="källstorlek" ]
                [ hash="källalgoritm:källhash" ]
                [ md5sum="käll-md5sum" ]/>
        <patches>
          <patch file="filnamn" strip="nivå"/>
          ...
        </patches>
        <dependencies>
          <dep package="modulnamn"/>
          ...
        </dependencies>
        <suggests>
          <dep package="modulnamn"/>
          ...
        </suggests>
      </tarball>

Attributen `id` och `version` används för att identifiera modulen.

Elementet `source` anger filen som ska hämtas och kompileras. Attributet `href` är obligatoriskt medan `size` och `hash`, så väl som det föråldrade `md5sum`-attributet är frivilligt. Om dessa två sista attribut finns med används de för att kontrollera att källpaketet hämtades korrekt.

Elementet `patches` används för att ange en eller flera programfixar som ska appliceras på källträdet efter uppackning, `file`-attributet ger filnamnet för programfixen och attributet `strip` säger hur många nivåer av kataloger som ska tas bort när programfixen appliceras.

För moduluppsättningar som följer med JHBuild letas programfixfiler upp i katalogen `jhbuild/patches/`; för moduluppsättningar som refereras till via URI kommer programfixfiler att letas efter i samma katalog som moduluppsättningsfilen eller i dess underkatalog `patches/`. Det är också möjligt för attributet `file` att ange en URI, då den kommer att hämtas från den platsen.

De andra attributen och elementen `dependencies`, `suggests` och `after` behandlas som för autotools.