<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!--*- mode: nxml -*-->
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- process to HTML with: xmlto xhtml-nochunks -m ../custom.xsl index.docbook -->
<article id="index" lang="sv">
  <articleinfo>
    <title>Handbok för JHBuild</title>
    <authorgroup>
      <author role="maintainer"><firstname>James</firstname> <surname>Henstridge</surname></author>
      <author><firstname>C.J.</firstname> <surname>Adams-Collier</surname></author>
      <author><firstname>Frederic</firstname> <surname>Peters</surname></author>
      <author><firstname>David</firstname> <surname>Turner</surname></author>
    </authorgroup>
    <copyright><year>2004, 2008</year> <holder>James Henstridge</holder></copyright>
    <revhistory>
      <revision><revnumber>Handbok för JHBuild v0.5</revnumber> <date>Januari 2008</date></revision>
      <revision><revnumber>Handbok för JHBuild v0.1</revnumber> <date>Augusti 2007</date></revision>
    </revhistory>
    <abstract role="description">
      <para>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.</para>
    </abstract>
  
    <othercredit class="translator">
      <personname>
        <firstname>Daniel Nylander</firstname>
      </personname>
      <email>po@danielnylander.se</email>
    </othercredit>
    <copyright>
      
        <year>2008</year>
      
      <holder>Daniel Nylander</holder>
    </copyright>
  
    <othercredit class="translator">
      <personname>
        <firstname>Anders Jonsson</firstname>
      </personname>
      <email>anders.jonsson@norsjovallen.se</email>
    </othercredit>
    <copyright>
      
        <year>2016</year>
      
      <holder>Anders Jonsson</holder>
    </copyright>
  
    <othercredit class="translator">
      <personname>
        <firstname>Sebastian Rasmussen</firstname>
      </personname>
      <email>sebras@gmail.com</email>
    </othercredit>
    <copyright>
      
        <year>2016</year>
      
      <holder>Sebastian Rasmussen</holder>
    </copyright>
  </articleinfo>

  <section id="introduction">
    <title>Introduktion</title>

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

    <para>JHBuild skrev från början för att bygga <ulink url="http://www.gnome.org">GNOME</ulink>, men har sedan dess blivit utökat för att vara användbart för andra projekt. En <quote>moduluppsättnings</quote>-fil kan sparas på en webbserver vilket låter byggregler vara oberoende av JHBuild-projektet.</para>

    <para>JHBuild kan bygga moduler från en uppsjö av källor, inklusive <ulink url="http://www.cvshome.org/">CVS</ulink>-, <ulink url="http://subversion.tigris.org/">Subversion</ulink>-, <ulink url="http://www.bazaar-vcs.org/">Bazaar</ulink>-, <ulink url="http://darcs.net/">Darcs</ulink>-, <ulink url="http://git.or.cz/">Git</ulink>- och <ulink url="http://www.selenic.com/mercurial/">Mercurial</ulink>-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.</para>

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

  <section id="getting-started">
    <title>Komma igång</title>

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

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

      <para>JHBuild kräver en Python-exekveringsmiljö. Verifiera att Python &gt;= 2.3 är installerat.</para>

      <para>Det rekommenderade sättet att hämta JHBuild är via versionshanteringssystemet <command>git</command>. 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. <filename>~/jhbuild/checkout</filename>.</para>

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

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

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

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

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

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

      <para>För att permanent lägga till <filename>~/.local/bin</filename> till variabeln <envar>PATH</envar>, kör följande kommando:</para>

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

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

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

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

      <para>Konfigurationsvariabler finns dokumenterade i <xref linkend="config-reference"/>. De vanligast använda variablerna är:</para>

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

<programlisting>repos['git.gnome.org'] = 'ssh://<replaceable>användarnamn</replaceable>@git.gnome.org/git/'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-moduleset"><varname>moduleset</varname></link></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-modules"><varname>modules</varname></link></term>
          <listitem>
            <simpara>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 <link linkend="command-reference-buildone"> <command>buildone</command></link> används. Standardvärdet är <literal>['meta-gnome-desktop']</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-checkoutroot"><varname>checkoutroot</varname></link></term>
          <listitem>
            <simpara>En sträng som anger katalogen att packa upp källträden i. Om <link linkend="cfg-buildroot"> <varname>buildroot</varname></link> är inställt till <constant>None</constant> kommer byggen också att ske i denna katalog. Standardvärdet är <filename>~/jhbuild/checkout</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-prefix"><varname>prefix</varname></link></term>
          <listitem>
            <simpara>En sträng som anger prefixet att installera moduler i. <varname>prefix</varname> måste vara en absolut sökväg. Denna katalog måste vara skrivbar. Standardvärdet är <literal>”~/jhbuild/install”</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-autogenargs"><varname>autogenargs</varname></link></term>
          <listitem>
            <simpara>En sträng som innehåller argument som angetts till skriptet <command>autogen.sh</command> för alla moduler. Kan åsidosättas för specifika moduler via uppslagsboken <link linkend="cfg-module-autogenargs"> <varname>module_autogenargs</varname></link>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><link linkend="cfg-makeargs"><varname>makeargs</varname></link></term>
          <listitem>
            <simpara>En sträng som listar ytterligare argument som ska anges till <command>make</command>. JHBuild kommer automatiskt att lägga till den parallella exekveringsflaggan (<option>-j</option>) baserat på antalet tillgängliga CPU-kärnor. Standardvärdet är <literal>””</literal>.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="getting-started-bootstrap">
      <title>Byggförutsättningar</title>

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

      <para>JHBuild kan kontrollera att verktygen är installerade via kommandot <command>sanitycheck</command>:</para>

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

      <para>Om detta kommando visar några meddelanden, installera paketet som krävs från din distributions arkiv. En lista över <ulink url="http://live.gnome.org/JhbuildDependencies">paketnamn </ulink> för olika distributioner underhålls på GNOME:s wiki. Kör kommandot <command>sanitycheck</command> på nytt efter att du installerat distributionens paket för att säkerställa att verktygen är installerade.</para>
    </section>

    <section id="getting-started-use">
      <title>Att använda JHBuild</title>

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

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

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

      <note>
        <simpara>Att hoppa över en modul kommer att förorsaka att de moduler som beror på modulen misslyckas.</simpara>
      </note>

      <para>Nedan finns ett exempel på menyn som visas:</para>

<screen>  [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”
<prompt>val:</prompt> </screen>

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

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

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

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

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

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

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

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

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

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

      <para>För att få information om en vissa modul, använda kommandot <command>info</command>:</para>

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

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

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

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

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

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

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

      <para>För att starta ett skal med samma miljö som används av JHBuild, använd kommandot <command>shell</command>:</para>

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

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

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

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

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

      <itemizedlist>
        <listitem>
          <simpara>DocBook XML DTD och XSLT-stilmallar. Detta måste registreras i XML-katalogen (<filename>/etc/xml/catalog</filename>).</simpara>
        </listitem>
        <listitem>
          <simpara>X-bibliotek.</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libsmbclient</filename> från Samba (används för att bläddra i Windows-nätverk).</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libbz2</filename> från bzip2.</simpara>
        </listitem>
        <listitem>
          <simpara><filename>libpng</filename>, <filename>libjpeg</filename> och <filename>libtiff</filename> (använda för bildinläsning).</simpara>
        </listitem>
      </itemizedlist>

      <para>Om du ska installera distributionspaket och om det gäller för din distribution, installera motsvarande <quote>dev</quote>- eller <quote>devel</quote>-paket. En lista över <ulink url="http://live.gnome.org/JhbuildDependencies">paketnamn</ulink> för olika distribution underhålls på GNOME:s wiki.</para>
    </section>

    <section id="running-single-application">
      <title>Kör ett enstaka GNOME-program</title>

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

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

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

      <para>Bekräfta att rätt program kommer köras. Till exempel:</para>

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

      <para>Kör programmet:</para>

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

      <para>Alternativ, kör programmet med <command>run</command>-kommandot:</para>

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

    <section id="running-gnome">
      <title>Att köra GNOME-skrivbordsmiljön</title>

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

      <para>Ställ in JHBuild för det nya <systemitem class="username">gnomedev</systemitem>-kontot. Kopiera eller mjuklänka <filename>~/.config/jhbuildrc</filename> och <filename>~/.local/bin/jhbuild</filename> till hemkatalogen för <systemitem class="username">gnomedev</systemitem>.</para>

      <para>Öppna en terminal som användaren <systemitem class="username">gnomedev</systemitem>. För att permanent lägga till <filename>~/.local/bin</filename> till <envar>PATH</envar>-variabeln, kör följande kommando:</para>

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

      <para>Testa att JHBuild fungerar:</para>

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

      <section>
        <title>Ställ in GNOME att köra från displayhanteraren</title>

        <para>Bygg och installera JHBuild GNOME.</para>

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

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

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

<programlisting>#!/bin/sh

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

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

jhbuild run gnome-session
</programlisting>

        <para>Gör filen <filename>/usr/bin/gnome-jhbuild-session</filename> körbar:</para>

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

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

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

        <para>Starta om <command>gdm</command>.</para>

        <para/>
      </section>

      <section>
        <title>Kör GNOME från displayhanteraren</title>

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

    <section id="static-analysis">
      <title>Statisk analys</title>

      <para>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 <varname>static_analyzer</varname> på <constant>True</constant> i konfigurationsfilen <filename>.jhbuildrc</filename>.</para>

      <para>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 <filename>/tmp/jhbuild_static_analyzer</filename> (som standard; sökvägen kan ändras via konfigurationsvariabeln <varname>static_analyzer_outputdir</varname>).</para>

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

  <section id="buildbot-integration">
    <title>Buildbot-integration</title>

    <para>Tillsammans med <ulink url="http://buildbot.net">Buildbot</ulink>-projektet kan JHBuild också fungerar som ett kontinuerlig-integrationsverktyg. Buildbot-konfigurationen används GNOME-projektet på <ulink url="http://build.gnome.org">build.gnome.org</ulink>.</para>

    <section id="buildbot-slave">
      <title>Konfigurera en Buildbot-slav</title>

      <para>En buildbot-slav är en variant av en normal JHBuild-installation som hanterar begäran från en Buildbot-master. Det rekommenderas att ställa in JHBuild och slutföra ett bygge med de flesta moduler byggda framgångsrikt innan Buildbot-anpassningar läggs till.</para>

      <para>Buildbot-kommandon är alternativ till kommandot <command>bot</command>. För att hämta och installera den extra programvara som krävs kör följande kommando:</para>

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

      <para>När detta steg har slutförts framgångsrikt krävs tre nya konfigurationsvariabler i <filename>~/.config/jhbuildrc</filename>.</para>

      <note>
        <para>Det är inte möjligt att använda en alternativ konfigurationsfil, <link linkend="option-file"><option>--file</option></link> kommer att inte att få de önskade effekterna.</para>
      </note>

<programlisting>
jhbuildbot_master = 'build.gnome.org:9070'
jhbuildbot_slavename = 'slavnamn'
jhbuildbot_password = 'lösenord'
</programlisting>

      <para><varname>jhbuildbot_master</varname> är en sträng som anger Buildbot master-servern; standardvärdet är <literal>'build.gnome.org:9070'</literal>. <varname>jhbuildbot_slavename</varname> och <varname>jhbuildbot_password</varname> identifierar slaven på masterservern. Kontakta administratören för Buildbot-masterservern för att få tag i slavnamnet och lösenordet.</para>

      <note>
        <para>Administratörerna för <ulink url="http://build.gnome.org">build.gnome.org</ulink> kan nås via sändlistan <ulink url="mailto:build-brigade-list@gnome.org">Build Brigade</ulink>.</para>
      </note>
    </section>

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

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

    <para>JHBuild använder en kommandoradssyntax i stil med verktyg så som CVS:</para>

    <cmdsynopsis><command>jhbuild</command> <arg><replaceable>globala-flaggor</replaceable></arg> <arg choice="plain"><replaceable>kommando</replaceable></arg> <arg><replaceable>kommandoargument</replaceable></arg></cmdsynopsis>

    <para>De globala JHBuild-flaggorna är:</para>

    <variablelist>
      <varlistentry id="option-file">
        <term><option>-f</option>, <option>--file</option> <replaceable>konfiguration</replaceable></term>
        <listitem>
          <simpara>Använd en alternativ konfigurationsfil istället för standardvärdet <filename>~/.config/jhbuildrc</filename>.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-m</option>, <option>--moduleset</option> <replaceable>moduluppsättning</replaceable></term>
        <listitem>
          <simpara>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.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--no-interact</option></term>
        <listitem>
          <simpara>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.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--exit-on-error</option></term>
        <listitem>
          <simpara>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.</simpara>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--conditions</option></term>
        <listitem>
          <simpara>Modifiera villkorsflaggorna till att vara andra än de som bestämts baserat på OS och de som angetts i jhbuildrc. Modifieringar anges som <literal>-wayland</literal> eller <literal>+docs</literal> för att ta bort eller lägga till villkor. Flera modifieringar kan separeras med ett komma i stil med <command>--conditions=+docs,-wayland</command> eller så kan du dela upp dem i flera <command>--conditions</command>-argument.</simpara>
        </listitem>
      </varlistentry>
    </variablelist>

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

    <variablelist>
      <varlistentry>
        <term><envar>JHBUILD_RUN_AS_ROOT</envar></term>
        <listitem>
          <simpara>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 <envar>JHBUILD_RUN_AS_ROOT</envar> kommer att inaktivera kontrollen av användar-ID vid uppstart.</simpara>
        </listitem>
      </varlistentry>
    </variablelist>

    <para>Kommandospecifika flaggor listas nedan.</para>

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

      <para>Kommandot <command>autobuild</command> bygger automatiskt modulerna så som de angetts i konfigurationsfilen och skickar sedan upp resultaten till JhAutobuild.</para>

      <cmdsynopsis><command>jhbuild autobuild</command> <arg>--autogen</arg> <arg>--clean</arg> <arg>--distcheck</arg> <arg rep="repeat">--skip=<replaceable>modul</replaceable></arg> <arg>--start-at=<replaceable>modul</replaceable></arg> <arg>--report-url=<replaceable>rapport-url</replaceable></arg> <arg>--verbose</arg></cmdsynopsis>

      <para>Flaggorna <option>--autogen</option>, <option>--clean</option>, <option>--distcheck</option>, <option>--skip</option> och <option>--start-at</option> behandlas enligt kommandot <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>--report-url=<replaceable>rapport-url</replaceable></option>, <option>-r <replaceable>rapport-url</replaceable></option></term>
          <listitem>
            <simpara>Denna flagga anger JhAutobuild-URL:en att rapportera till.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--verbose</option>, <option>-v</option></term>
          <listitem>
            <simpara>Om angiven kommer JHBuilds utmatning att vara utförligare.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>Kommandot <command>bootstrap</command> installerar en uppsättning av byggverktyg. Byggverktygen inkluderar <application>autoconf</application>, <application>automake</application> och liknande verktyg. Den rekommenderade metoden att installera byggverktygen är via din distributions pakethanteringssystem. <command>bootstrap</command> bör bara användas om byggverktygen inte tillhandahålls av din distributions pakethanteringssystem, till exempel på <systemitem class="osname">Mac OS</systemitem>.</para>

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

      <para>Kommandot <command>bootstrap</command> bygger moduler via samma metod som kommandot <command>build</command> men använder moduluppsättningen <filename>bootstrap.modules</filename> istället.</para>

      <para>Se kommandodokumentationen för <link linkend="command-reference-build"><command>build</command></link> för tillgängliga flaggor.</para>
    </section>

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

      <para>Kommandot <command>build</command> bygger ett eller flera paket samt deras beroenden.</para>

      <cmdsynopsis><command>jhbuild build</command> <arg>--autogen</arg> <arg>--clean</arg> <arg>--check</arg> <arg>--dist</arg> <arg>--distcheck</arg> <arg>--distclean</arg> <arg>--ignore-suggests</arg> <arg>--no-network</arg> <arg rep="repeat">--skip=<replaceable>modul</replaceable></arg> <arg>--start-at=<replaceable>modul</replaceable></arg> <arg>--tags=<replaceable>taggar</replaceable></arg> <arg>-D <replaceable>datum</replaceable></arg> <arg>--no-xvfb</arg> <arg>--try-checkout</arg> <arg>--no-poison</arg> <arg>--force</arg> <arg>--build-optional-modules</arg> <arg>--min-age=<replaceable>tid</replaceable></arg> <arg>--nodeps</arg> <arg rep="repeat">modul</arg></cmdsynopsis>

      <para>Om inga modulnamn anges på kommandoraden kommer listan <link linkend="cfg-modules">moduler</link> från konfigurationsfilen att användas.</para>

      <variablelist>
        <varlistentry>
          <term><option>-a</option>, <option>--autogen</option></term>
          <listitem>
            <simpara>Kör alltid <command>autogen.sh</command> innan du bygger moduler.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-c</option>, <option>--clean</option></term>
          <listitem>
            <simpara>Kör <command>make clean</command> innan du bygger moduler.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--check</option></term>
          <listitem>
            <simpara>Kör <command>make check</command> efter moduler har byggts.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-d</option>, <option>--dist</option></term>
          <listitem>
            <simpara>Kör <command>make dist</command> efter moduler har byggts.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--distcheck</option></term>
          <listitem>
            <simpara>Kör <command>make distcheck</command> efter moduler har byggts.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--distclean</option></term>
          <listitem>
            <simpara>För git-moduler, kör <command>git clean -dfx</command> innan du bygger modulerna. För andra moduler, kör <command>make distclean</command> innan du bygger modulerna.</simpara>

            <note>
              <simpara>Denna flagga kommer att ta bort alla ändringar som inte checkats in.</simpara>
            </note>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--ignore-suggests</option></term>
          <listitem>
            <simpara>Bygg inte mjuka beroenden.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-n</option>, <option>--no-network</option></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-s</option>, <option>--skip</option>=<replaceable>modul,…</replaceable></term>
          <listitem>
            <simpara>Bygg inte de listade modulerna. Används för att hoppa över att bygga specifika beroenden.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--tags</option>=<replaceable>tagg,…</replaceable></term>
          <listitem>
            <simpara>Ignorera moduler som inte matchar <replaceable>tagg</replaceable>. Moduler får automatiskt en tagg som matchar namnet på modulens moduluppsättning.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-t</option>, <option>--start-at</option>=<replaceable>modul</replaceable></term>
          <listitem>
            <simpara>Börja med den namngivna modulen snarare än i början av listan. Denna flagga är användbar om bygget avbröts.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-D</option> <replaceable>datum</replaceable></term>
          <listitem>
            <simpara>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. <literal>"2009-09-18 02:32Z"</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-x</option>, <option>--no-xvfb</option></term>
          <listitem>
            <simpara>Kör grafiska tester på den riktiga X-servern snarare än i en simulerad Xvfb.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-C</option>, <option>--try-checkout</option></term>
          <listitem>
            <simpara>Om bygget misslyckas och om det stöds av versionshanteringssystemet, tvinga en utcheckning och kör <command>autogen.sh</command> innan du försöker bygga igen.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-N</option>, <option>--no-poison</option></term>
          <listitem>
            <simpara>Om en eller flera av en moduls beroenden misslyckas, tvingar denna flagga JHBuild att försöka bygga modulen ändå.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-f</option>, <option>--force</option></term>
          <listitem>
            <simpara>Bygg modulerna även om policyn säger att det inte krävs.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--build-optional-modules</option></term>
          <listitem>
            <simpara>Moduler listade som valfria beroenden, kanske inte behövs för att bygga modulen. Denna flagga tvingar JHBuild att bygga valfria beroenden.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--min-age</option>=<replaceable>tid</replaceable></term>
          <listitem>
            <simpara>Hoppa över moduler som installerats senare än det angivna relativa datumet. Strängformatet för <replaceable>tid</replaceable> ä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 <option>--min-age=2h</option> att hoppa över moduler som byggts de senaste två timmarna.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--nodeps</option></term>
          <listitem>
            <simpara>Hoppa över saknade systemberoenden. För att ignorera ett enstaka systemberoende lägg till modulen i <link linkend="cfg-skip"><varname>skip</varname></link>.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>Kommandot <command>make</command> 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 <command>buildone -nf $(basename $(pwd))</command>.</para>

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

      <para>Flaggorna är de samma som de som finns tillgängliga för kommandot <link linkend="command-reference-build"><command>buildone</command></link>.</para>
    </section>

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

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

      <cmdsynopsis><command>jhbuild buildone</command> <arg>--autogen</arg> <arg>--clean</arg> <arg>--check</arg> <arg>--distcheck</arg> <arg>--distclean</arg> <arg>--no-network</arg> <arg>-D <replaceable>datum</replaceable></arg> <arg>--no-xvfb</arg> <arg>--force</arg> <arg>--min-age=<replaceable>tid</replaceable></arg> <arg>--nodeps</arg> <arg choice="plain" rep="repeat">modul</arg></cmdsynopsis>

      <para>Flaggorna <option>--autogen</option>, <option>--check</option>, <option>--clean</option>, <option>-d</option>, <option>--distcheck</option>, <option>--distclean</option>, <option>--no-network</option>, <option>-D</option>, <option>-x</option> och <option>--nodeps</option> behandlas på samma sätt som för kommandot <link linkend="command-reference-build"><command>build</command></link>.</para>

      <para>Åtminstone en modul måste listas på kommandoraden.</para>
    </section>

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

      <para><command>checkbranches</command> kontrollerar att modulens grenar är korrekt definierade i versionshanteringssystemet och att grenarna stämmer överens med moduluppsättningen.</para>

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

      <variablelist>
        <varlistentry>
          <term><option>--branch</option>=<replaceable>gren</replaceable>, <option>-b</option> <replaceable>gren</replaceable></term>
          <listitem>
            <simpara>Grenen som ska kontrolleras.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

<screen><prompt>$</prompt> <userinput>jhbuild -m gnome-2.20 checkbranches</userinput>
libgnomecanvas saknar grendefinition för gnome-2-20
<prompt>$</prompt></screen>
    </section>

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

      <para>Kommandot <command>clean</command> tömmer byggkatalogerna för en eller flera moduler.</para>

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

      <para>Om inga modulnamn anges på kommandoraden kommer listan <link linkend="cfg-modules">moduler</link> från konfigurationsfilen att användas.</para>

      <para>Se kommandodokumentationen för <link linkend="command-reference-build"><command>build</command></link> för en beskrivning över tillgängliga flaggor.</para>
    </section>

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

      <para>Kommandot <command>dot</command> genererar en fil som beskriver den riktade grafen över beroenden mellan en uppsättning av moduler. Denna fil kan sedan behandlas av programvaran <ulink url="http://www.graphviz.org/">GraphViz</ulink> för att producera ett diagram.</para>

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

      <para>Om inga modulnamn anges på kommandoraden kommer listan <link linkend="cfg-modules">moduler</link> från konfigurationsfilen att användas.</para>

      <para>Flaggan <option>--soft-deps</option> lägger till streckade linjer från modulerna till de mjuka beroendena. Flaggan <option>--clusters</option> grupperar moduler från <link linkend="moduleset-syntax-defs-metamodule">metamoduler</link> tillsammans.</para>

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

<screen><prompt>$</prompt> <userinput>jhbuild dot <replaceable>moduler</replaceable> | dot -Tps &gt; beroenden.ps</userinput></screen>

      <para>Eller en PNG-bild:</para>

<screen><prompt>$</prompt> <userinput>jhbuild dot <replaceable>moduler</replaceable> | dot -Tpng &gt; beroenden.png</userinput></screen>

      <figure id="sample-dot-output">
        <title>Exempelutmatning från JHBuild dot</title>
        <screenshot>
          <mediaobject>
            <imageobject>
              <imagedata fileref="figures/jhbuild_sample_dot_output.png" format="PNG"/>
            </imageobject>
          </mediaobject>
        </screenshot>
      </figure>
    </section>

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

      <para>Kommandot <command>gui</command> 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.</para>

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

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

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

      <para>Kommandot <command>info</command> visar information om en eller flera moduler.</para>

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

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

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

      <para>Om flaggan <option>--installed</option> 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.</para>

      <note>
        <simpara>Om flaggan <option>--installed</option> 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.</simpara>
      </note>
    </section>

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

      <para>Kommandot <command>list</command> skriver ut den expanderade listan över moduler som kommandot <command>build</command> hade byggt.</para>

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

      <para>Om inga modulnamn anges på kommandoraden kommer listan <link linkend="cfg-modules">moduler</link> från konfigurationsfilen att användas.</para>

      <para>Flaggorna <option>--skip</option>, <option>--start-at</option>, <option>--tags</option> och <option>--ignore-suggests</option> behandlas på samma sätt som för kommandot <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>-a</option>, <option>--all-modules</option></term>
          <listitem>
            <simpara>Lista alla modulerna från en moduluppsättning oavsett byggberoenden.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>-r</option>, <option>--show-revision</option></term>
          <listitem>
            <simpara>Om en modul är inställd på en gren, visa grennamnet med modulnamnet.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--list-optional-modules</option></term>
          <listitem>
            <simpara>Denna flagga tvingar JHBuild att lista valfria beroenden.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>Kommandot <command>rdepends</command> visar de omvända beroendena för en modul.</para>

      <cmdsynopsis><command>jhbuild rdepends</command> <arg>modul</arg></cmdsynopsis>

      <variablelist>
        <varlistentry>
          <term><option>--dependencies</option></term>
          <listitem>
            <simpara>Visa beroendesökvägen intill modulerna.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><option>--direct</option></term>
          <listitem>
            <simpara>Begränsa utskriften till moduler som direkt beror på den angivna modulen.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>Kommandot <command>run</command> kör det angivna kommandot i samma miljö som JHBuild använder för att bygga moduler.</para>

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

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

      <variablelist>
        <varlistentry>
          <term><option>--in-builddir</option>=<replaceable>modul</replaceable></term>
          <listitem>
            <simpara>Kör kommandot i byggkatalogen för den angivna modulen.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

      <variablelist>
        <varlistentry>
          <term><option>--in-checkoutdir</option>=<replaceable>modul</replaceable></term>
          <listitem>
            <simpara>Kör kommandot i källkodskatalogen för den angivna modulen.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>Kommandot <command>sanitycheck</command> utför ett antal kontroller för att verifiera att byggmiljön är OK.</para>

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

      <para>Dessa kontroller inkluderar:</para>

      <itemizedlist>
        <listitem>
          <simpara>Att utchecknings- och installationsprefixen är skrivbara.</simpara>
        </listitem>
        <listitem>
          <simpara>Att de byggverktyg som krävs är installerade.</simpara>
        </listitem>
        <listitem>
          <simpara>Att vissa vanliga makron är tillgängliga i sökvägar för <command>aclocal</command> förknippat med de olika versionerna av <command>automake</command>.</simpara>
        </listitem>
        <listitem>
          <simpara>XML-katalogen innehåller DocBook DTD och stilmallar.</simpara>
        </listitem>
      </itemizedlist>
    </section>

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

      <para>Kommandot <command>shell</command> startar användarens skal med samma miljö som JHBuild använder för att bygga moduler.</para>

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

      <para>Detta kommando är ekvivalent med följande:</para>

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

      <para>Miljövariabeln <envar>UNDER_JHBUILD</envar> 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 <filename>.bashrc</filename>:</para>

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

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

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

      <para>Kommandot <command>sysdeps</command> visar:</para>

      <orderedlist>
        <listitem>
          <simpara>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.</simpara>
        </listitem>
        <listitem>
          <simpara>en lista över paket som krävs. För att påbörja ett bygge måste paketen tillhandahållas av ditt system.</simpara>
        </listitem>
        <listitem>
          <simpara>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 <link linkend="cfg-partial-build"><varname>partial_build</varname></link> är <constant>False</constant> (falsk).</simpara>
        </listitem>
      </orderedlist>

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

      <variablelist>
        <varlistentry>
          <term><option>--install</option></term>
          <listitem>
            <simpara>Denna flagga installerar systemberoenden som är beroenden från moduluppsättningen. Installationsmetoden beror på din distribution. Systempaket installeras via <application>PackageKit</application> om tillgängligt. För distributioner som använder <application>APT</application> så som <systemitem class="osname">Debian</systemitem> och <systemitem class="osname">Ubuntu</systemitem> kräver denna flagga att <application>apt-file</application> är installerat.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>

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

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

      <para>Kommandot <command>tinderbox</command> liknar <command>build</command> 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.</para>

      <cmdsynopsis><command>jhbuild tinderbox</command> <arg>--autogen</arg> <arg>--clean</arg> <arg>--distclean</arg> <arg>--no-network</arg> <arg>--output=<replaceable>katalog</replaceable></arg> <arg rep="repeat">--skip=<replaceable>modul</replaceable></arg> <arg>--start-at=<replaceable>modul</replaceable></arg> <arg>-D <replaceable>datum</replaceable></arg> <arg>-C</arg> <arg>-N</arg> <arg>-f</arg> <arg>--nodeps</arg> <arg rep="repeat">modul</arg></cmdsynopsis>

      <para>Flaggorna <option>--autogen</option>, <option>--clean</option>, <option>--distclean</option>, <option>--no-network</option>, <option>--skip</option>, <option>--start-at</option>, <option>-D</option>, <option>-C</option>, <option>-N</option>, <option>-f</option> och <option>--nodeps</option> behandlas på samma sätt som för kommandot <link linkend="command-reference-build"><command>build</command></link>.</para>

      <variablelist>
        <varlistentry>
          <term><option>-o</option>, <option>--output</option>=<replaceable>katalog</replaceable></term>
          <listitem>
            <simpara>Katalogen som HTML-filer skrivs till. JHBuild kommer att skapa ett index (<filename>index.html</filename>) och en HTML-fil för varje modul.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

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

      <para>Kommandot <command>uninstall</command> avinstallerar en eller flera moduler.</para>

      <cmdsynopsis><command>jhbuild uninstall</command> <arg choice="plain" rep="repeat">modul</arg></cmdsynopsis>
    </section>

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

      <para>Kommandot <command>update</command> liknar <command>build</command> men utför bara hämtnings- eller uppdateringssteget för moduler utan att bygga dem.</para>

      <cmdsynopsis><command>jhbuild update</command> <arg rep="repeat">--skip=<replaceable>modul</replaceable></arg> <arg>--start-at=<replaceable>modul</replaceable></arg> <arg>--tags=<replaceable>taggar</replaceable></arg> <arg>--ignore-suggests</arg> <arg>-D <replaceable>datum</replaceable></arg> <arg rep="repeat">modul</arg></cmdsynopsis>

      <para>Flaggorna <option>--skip</option>, <option>--start-at</option>, <option>--tags</option>, <option>--ignore-suggests</option> och <option>-D</option> behandlas på samma sätt som för kommandot <link linkend="command-reference-build"><command>build</command></link>.</para>
    </section>

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

      <para>Kommandot <command>updateone</command> liknar <command>update</command> men det uppdaterar inte modulberoenden. Det är användbart för att uppdatera en eller flera moduler.</para>

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

      <para>Flaggan <option>-D</option> behandlas på samma sätt som för kommandot <link linkend="command-reference-build"><command>build</command></link>.</para>

      <para>Åtminstone en modul måste listas på kommandoraden.</para>
    </section>
  </section>

  <section id="config-reference">
    <title>Referensmanual för konfigurationsfil</title>

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

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

<programlisting>use_local_modulesets = True</programlisting>

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

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

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

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

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

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

    <section id="config-reference-variables">
      <title>Konfigurationsvariabler</title>

      <variablelist>
<?dbhtml list-presentation="table"?>
        <varlistentry id="cfg-alwaysautogen">
          <term><varname>alwaysautogen</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som är inställt på <constant>True</constant> (sant) kommer alltid att köra <command>autogen.sh</command>. Detta är ekvivalent med att ange flaggan <option>--autogen</option> till JHBuild. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-autogenargs">
          <term><varname>autogenargs</varname></term>
          <listitem>
            <simpara>En sträng som innehåller argument som anges till skriptet <command>autogen.sh</command> för alla moduler. Kan åsidosättas för specifika moduler via uppslagsboken <varname>module_autogenargs</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-branches">
          <term><varname>branches</varname></term>
          <listitem>
            <simpara>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.</simpara>

            <simpara>Definitionen av grenar beror på VCS-modulen:</simpara>

            <itemizedlist>
              <listitem>
                <simpara>CVS: revision. T.ex. <literal>'GREN-PROJEKT-0_8'</literal></simpara>
              </listitem>
              <listitem>
                <simpara>Bazaar: URI:n för modulgrenen. T.ex. <literal>'http://bzr.example.net/projekt/gnome-2-28'</literal></simpara>
              </listitem>
              <listitem>
                <simpara>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. <literal>('git://git.example.net/project', 'gnome-2-28')</literal></simpara>

                <example>
                  <title>Enkelt exempel</title>
<programlisting>branches['modulnamn'] = (None, 'grennamn')</programlisting>
                </example>
              </listitem>
              <listitem>
                <simpara>Subversion: URI:n för modulgrenen. T.ex. <literal>'svn://svn.example.net/projekt/gnome-2-28'</literal></simpara>
              </listitem>
            </itemizedlist>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-builddir-pattern">
          <term><varname>builddir_pattern</varname></term>
          <listitem>
            <simpara>Ett formateringsmönster i <function>printf</function>-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. <literal>%s</literal> i formateringssträngen kommer att ersättas med <varname>checkoutdir</varname>. Standardvärdet är <literal>'%s'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-buildroot">
          <term><varname>buildroot</varname></term>
          <listitem>
            <simpara>En sträng som anger den överordnade katalogen som byggträd placeras i. Standardvärdet är <filename>~/.cache/jhbuild/build</filename>. Att ställa in värdet till <constant>None</constant> (ingen) får byggen att utföras i källkodsträden.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-buildscript">
          <term><varname>buildscript</varname></term>
          <listitem>
            <simpara>En sträng som ange vilket byggskript som ska användas. Den rekommenderade inställningen är standardvärdet, <literal>terminal</literal>. Bör framför allt inte ställs in till <literal>gtk</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-build-policy">
          <term><varname>build_policy</varname></term>
          <listitem>
            <simpara>En sträng som anger vilka moduler som ska byggas. De tre möjliga alternativen är <literal>all</literal>, för att bygga alla moduler som begärs, <literal>updated</literal> för att endast bygga de moduler som har ändrats eller <literal>updated-deps</literal> för att bygga moduler som har ändrats eller som har beroenden som har ändrats. Standardvärdet är <literal>updated-deps</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-checkoutroot">
          <term><varname>checkoutroot</varname></term>
          <listitem>
            <simpara>En sträng som anger vilken katalog som källkodsträd ska packas upp i. Om värdet inte är <varname>buildroot</varname> (byggrot) kommer byggen att ske i denna katalog också. Standardvärdet är <filename>~/checkout/gnome</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-checkout-mode">
          <term><varname>checkout_mode</varname></term>
          <listitem>
            <simpara>En sträng som anger hur utcheckningen görs för kataloger under versionshantering. Standardvärdet är <literal>update</literal>. Detta kan ställas in för varje modul via <varname>module_checkout_mode</varname>. Möjliga värden är <literal>update</literal> (uppdatera katalog med utcheckning i), <literal>clobber</literal> (töm katalog innan källkod checkas ut), <literal>export</literal> (töm katalogen, skapa sedan en oversionerad kopia av källkoden) och <literal>copy</literal> (checka ut i en annan katalog än den som kommer att byggas).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-copy-dir">
          <term><varname>copy_dir</varname></term>
          <listitem>
            <simpara>En sträng som anger vilken katalog som ska kopieras till om kopian <link linkend="cfg-checkout-mode"> <varname>checkout_mode</varname></link> används. Standardvärdet är utcheckningskatalogen.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-cvs-program">
          <term><varname>cvs_program</varname></term>
          <listitem>
            <simpara>En sträng som anger vilket program som ska användas för CVS-stöd. Detta kan vara <literal>git-cvsimport</literal> eller <literal>cvs</literal>. Standardvärdet är <literal>cvs</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-disable-Werror">
          <term><varname>disable_Werror</varname></term>
          <listitem>
            <simpara>Ett booleskt värde (standardvärdet är <literal>True</literal> (sant)) som styr om <literal>--disable-Werror</literal> kommer att skickas till automake-byggen. Många paket använder denna flagga som ett sätt att inaktivera ödesdigra kompilatorvarningar. Värdet <literal>True</literal> (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 <literal>False</literal> (falskt) kan vara vettigt för de som använder jhbuild som en del av ett kontinuerligt integrations- eller testsystem.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-dvcs-mirror-dir">
          <term><varname>dvcs_mirror_dir</varname></term>
          <listitem>
            <simpara>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 <command>update</command> och <command>updateone</command> 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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="exit-on-error">
          <term><varname>exit_on_error</varname></term>
          <listitem>
            <simpara>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 <constant>True</constant> (sant) är ekvivalent med att ange flaggan <option>--exit-on-error</option>. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-extra-prefixes">
          <term><varname>extra_prefixes</varname></term>
          <listitem>
            <simpara>En lista av strängar som anger i precedensordning listan över extra prefix. JHBuild ställer in många miljövariabler (så som <envar>LD_LIBRARY_PATH</envar>, <envar>PKG_CONFIG_PATH</envar> och <envar>XDG_DATA_DIRS</envar>) baserat på variabeln <varname>prefix</varname>. Att lägga till kataloger till <varname>extra_prefixes</varname> kommer att förorsaka att dessa prefix också kommer att inkluderas, vid en lägre precedens än den för JHBuild <varname>prefix</varname>, men vid en högre precedens än systemkatalogerna. Denna variabel är tom som standard förutom på system som installerar programvara i <filename>/usr/local</filename> då den innehåller denna katalog.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-help-website">
          <term><varname>help_website</varname></term>
          <listitem>
            <simpara>En tupel som anger namn och URL för en hjälpwebbplats. Webbplatsen visas i tinderbox-html för misslyckade moduler. <varname>%(module)s</varname> i URL:en kommer att ersättas med modulnamnet. För att inaktivera ställ in <varname>help_website</varname> till <literal>None</literal> (ingen). Standardvärdet är <literal>('Gnome Live!', 'http://live.gnome.org/JhbuildIssues/%(module)s')</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-installprog">
          <term><varname>installprog</varname></term>
          <listitem>
            <simpara>En sträng som anger vilket program som ska användas som ersättning för <literal>/usr/bin/install</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-ignore-suggests">
          <term><varname>ignore_suggests</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida mjuka beroenden ska hoppas över när beroendeträdet beräknas. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-interact">
          <term><varname>interact</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida bygget ska interagera med användaren. Om detta värde ställs in på <constant>False</constant> (falskt) är det ekvivalent med att ange flaggan <option>--no-interact</option>. Standardvärdet är <constant>True</constant> (sant).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makeargs">
          <term><varname>makeargs</varname></term>
          <listitem>
            <simpara>En sträng som listar ytterligare argument som ska anges till <command>make</command>. JHBuild kommer automatiskt att lägga till den parallella exekveringsflaggan (<option>-j</option>) baserat på antalet tillgängliga CPU-kärnor. Standardvärdet är <literal>””</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makecheck">
          <term><varname>makecheck</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida <command>make check</command> ska köras efter <command>make</command>. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makecheck-advistory">
          <term><varname>makecheck_advisory</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida fel vid körning av <command>make check</command> endast ska vara rådgivande och inte orsakar byggfel. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makeclean">
          <term><varname>makeclean</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida <command>make clean</command> ska köras före <command>make</command>. Standardvärdet är <constant>False</constant>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makedist">
          <term><varname>makedist</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida <command>make dist</command> ska köras efter <command>make</command>. Standardvärdet är <constant>False</constant>. Denna inställning är ekvivalent med att ange flaggan <option>--dist</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-makedistcheck">
          <term><varname>makedistcheck</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida <command>make distcheck</command> ska köras efter <command>make</command>. Standardvärdet är <constant>False</constant>. Denna inställning är ekvivalent med att ange flaggan <option>--distcheck</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-autogenargs">
          <term><varname>module_autogenargs</varname></term>
          <listitem>
            <simpara>En uppslagsbok som mappar modulnamn till strängar som anger argumenten som ska skickas till <command>autogen.sh</command>. Inställningen i <varname>module_autogenargs</varname> används istället för den globala <varname>autogenargs</varname>-inställningen. Om en viss modul inte listas i uppslagsboken kommer den globala <varname>autogenargs</varname> att användas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-checkout-mode">
          <term><varname>module_checkout_mode</varname></term>
          <listitem>
            <simpara>En uppslagsbok som anger vilket utcheckningsläge som ska användas för moduler. Detta åsidosätter den globala inställningen <varname>checkout_mode</varname>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-makeargs">
          <term><varname>module_makeargs</varname></term>
          <listitem>
            <simpara>En uppslagsbok som mappar modulnamn till strängar som anger argument som ska skickas till <command>make</command>. Inställningen <varname>module_makeargs</varname> ersätter värdet från <varname>makeargs</varname>. Om en viss modul inte finns listad i uppslagsboken kommer den globala <varname>makeargs</varname> att användas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-makecheck">
          <term><varname>module_makecheck</varname></term>
          <listitem>
            <simpara>En uppslagsbok som mappar modulnamn till booleska värden som anger huruvida <command>make check</command> ska köras efter <command>make</command>. Inställningen <varname>module_makecheck</varname> ersätter värdet från <varname>makecheck</varname>. Om en viss modul inte finns listad i uppslagsboken kommer den globala <varname>makecheck</varname> att användas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-nopoison">
          <term><varname>module_nopoison</varname></term>
          <listitem>
            <simpara>En uppslagsbok som mappar modulnamn till booleska värden. Om en modul är inställd på <constant>True</constant> (sant) kommer JHBuild att försöka att bygga modulberoenden även om den angivna modulen misslyckades. Inställningen <varname>module_nopoison</varname> ersätter värdet från <varname>nopoison</varname>. Om en viss modul inte listas i uppslagsboken kommer den globala <varname>nopoison</varname> att användas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-extra-env">
          <term><varname>module_extra_env</varname></term>
          <listitem>
            <simpara>En uppslagsbok som mappar modulnamn till ordböcker med extra miljövariabler som skickas till exekverande kommandon för modulen.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-module-static-analyzer">
          <term><varname>module_static_analyzer</varname></term>
          <listitem>
            <simpara>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 <varname>static_analyzer</varname> åsidosättas.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-modules">
          <term><varname>modules</varname></term>
          <listitem>
            <simpara>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 <link linkend="command-reference-buildone"> <command>buildone</command></link> används. Standardvärdet är <literal>['meta-gnome-desktop']</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-moduleset">
          <term><varname>moduleset</varname></term>
          <listitem>
            <simpara>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.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-modulesets-dir">
          <term><varname>modulesets_dir</varname></term>
          <listitem>
            <simpara>En sträng som anger katalogen som innehåller moduluppsättningarna som ska användas. Standardvärdet är katalogen <filename>modulesets/</filename> i JHBuild-källkoden.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nice-build">
          <term><varname>nice_build</varname></term>
          <listitem>
            <simpara>Kör byggen under prioriteten <constant>SCHED_IDLE</constant> i Linux och <command>nice</command> för andra Unix:ar. Detta kan dramatiskt förbättra skrivbordsinteraktiviteten för parallella byggen medan de har försumbar inverkan på bygghastighet.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nobuild">
          <term><varname>nobuild</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som om det är inställt på <constant>True</constant> (sant) kommer JHBuild inte att bygga moduler utan enbart hämta och packa upp källkoden. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nonetwork">
          <term><varname>nonetwork</varname></term>
          <listitem>
            <simpara>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å <constant>True</constant> (sant) är ekvivalent med att ange flaggan <option>--no-network</option>. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nonotify">
          <term><varname>nonotify</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida aviseringar ska skickas ut via aviseringsdemonen. Om denna är inställd på <constant>False</constant> (falskt) kommer aviseringar att skickas ut. Standardvärdet är <constant>True</constant> (sant).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-nopoison">
          <term><varname>nopoison</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som om det är inställt på <constant>True</constant> (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 <option>--no-poison</option>. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-notrayicon">
          <term><varname>notrayicon</varname></term>
          <listitem>
            <simpara>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å <constant>False</constant> (falskt) kommer en ikon att visas. Standardvärdet är <constant>True</constant> (sant).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-noxvfb">
          <term><varname>noxvfb</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som om det är inställt på <constant>True</constant> (sant) kommer att få JHBuild att köra grafiska tester på den riktiga X-servern snarare än att använda <command>Xvfb</command>. Denna flagga är ekvivalent med att ange <option>--no-xvfb</option>. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-partial-build">
          <term><varname>partial_build</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som om det är inställt på <constant>True</constant> (sant) kommer att få JHBuild att inte bygga modulberoenden om motsvarande systempaket finns installerade och i tillräckligt ny version. Standardvärdet är <constant>True</constant> (sant).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-prefix">
          <term><varname>prefix</varname></term>
          <listitem>
            <simpara>En sträng som anger prefixet att installera moduler i. <varname>prefix</varname> måste vara en absolut sökväg. Denna katalog måste vara skrivbar. Standardvärdet är <literal>”~/jhbuild/install”</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-pretty-print">
          <term><varname>pretty_print</varname></term>
          <listitem>
            <simpara>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 <literal>True</literal> (sant).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-print-command-pattern">
          <term><varname>print_command_pattern</varname></term>
          <listitem>
            <simpara>En sträng som visas innan JHBuild kör ett kommando. <varname>%(command)s</varname> i strängen kommer att ersättas med kommandot som ska köras. <varname>%(cwd)s</varname> i strängen kommer att ersättas med aktuell arbetskatalog. Standardvärdet är <literal>'%(command)s'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-progress-bar">
          <term><varname>progress_bar</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som anger huruvida en förloppsindikator ska visas i <link linkend="cfg-quiet-mode">tyst läge</link>. Standardvärdet är <literal>True</literal> (sant).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-quiet-mode">
          <term><varname>quiet_mode</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som om det är inställt på <constant>True</constant> (sant) inaktiverar utmatningen av kommandon som körs. Standardvärdet är <literal>False</literal> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-repos">
          <term><varname>repos</varname></term>
          <listitem>
            <simpara>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:</simpara>

<programlisting>repos['git.gnome.org'] = 'ssh://username@git.gnome.org/git/'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-skip">
          <term><varname>skip</varname></term>
          <listitem>
            <simpara>En lista över moduler som ska hoppas över. Denna kommandoradsflagga, <option>--skip</option>, utökar listan. Denna lista är tom som standard. Om listan innehåller det speciella värdet <literal>'*'</literal> kommer JHBuild att hoppa över alla moduler som inte uttryckligen listas i variabeln <varname>modules</varname>. Detta kan vara användbart om du vill bygga moduler utan deras implicita beroenden.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer">
          <term><varname>static_analyzer</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som om det är inställt på <constant>True</constant> (sant) kör ett statiskt analysverktyg för varje modul medan den byggs. Standardvärdet är <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer-outputdir">
          <term><varname>static_analyzer_outputdir</varname></term>
          <listitem>
            <simpara>Rotkatalogen under vilken statiska analysrapporter kommer att sparas (om <varname>static_analyzer</varname> är <constant>True</constant> (sant)). Standardvärdet är <filename>/tmp/jhbuild_static_analyzer</filename>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-static-analyzer-template">
          <term><varname>static_analyzer_template</varname></term>
          <listitem>
            <simpara>Kommandomall för den statiska analysatorn. Denna får enligt <function>printf</function>-stil parametrarna <varname>outputdir</varname> (värdet från konfigurationsvariabeln <varname>static_analyzer_outputdir</varname>) och <varname>module</varname> (namnet på modulen som byggs för närvarande) ersatta. Det resulterande kommandot används som prefix till <command>make</command> när en modul byggs. Standardvärdet är <command>scan-build</command>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-sticky-date">
          <term><varname>sticky_date</varname></term>
          <listitem>
            <simpara>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. <literal>'<replaceable>åååå</replaceable>-<replaceable>mm</replaceable>-<replaceable>dd</replaceable>'</literal>. Standardvärdet är <constant>None</constant> (inget).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-svn-program">
          <term><varname>svn_program</varname></term>
          <listitem>
            <simpara>En sträng som anger vilket program som ska användas för subversion-utmatning. Denna kan vara <literal>svn</literal>, <literal>git-svn</literal> eller <literal>bzr</literal>. Standardvärdet är <literal>svn</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-system-libdirs">
          <term><varname>system_libdirs</varname></term>
          <listitem>
            <simpara>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 <envar>PKG_CONFIG_PATH</envar>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-tarballdir">
          <term><varname>tarballdir</varname></term>
          <listitem>
            <simpara>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 <varname>checkoutroot</varname>. Detta är användbart om du har flera JHBuild-miljöer eller regelbundet rensar ur <varname>checkoutroot</varname> och vill reducera använd bandbredd. Standardvärdet är <literal>'~/.cache/jhbuild/downloads'</literal>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-tinderbox-outputdir">
          <term><varname>tinderbox_outputdir</varname></term>
          <listitem>
            <simpara>En sträng som anger vilken katalog som används för att lagra <command>jhbuild tinderbox</command>-utmatning. Denna sträng kan åsidosättas av flaggan <option>--output</option>. Standardvärdet är <constant>None</constant> (ingen), så antingen måste kommandoradsflaggan eller denna variabel användas i konfigurationsfilen.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-trycheckout">
          <term><varname>trycheckout</varname></term>
          <listitem>
            <simpara>Ett booleskt värde som om det är inställt på <constant>True</constant> (sant) får JHBuild att automatiskt försöka lösa fel genom att 1) köra <command>autogen.sh</command> igen eller 2) checka ut en nyare version av en modul från versionshanteringssystemet. Denna inställning är ekvivalent med att ange flaggan <option>--try-checkout</option>.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-use-local-modulesets">
          <term><varname>use_local_modulesets</varname></term>
          <listitem>
            <simpara>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 <constant>False</constant> (falskt).</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-xvfbargs">
          <term><varname>xvfbargs</varname></term>
          <listitem>
            <simpara>En sträng som listar argument som ska skickas till <command>Xvfb</command> om grafiska tester ska köras.</simpara>
          </listitem>
        </varlistentry>
        <varlistentry id="cfg-conditions">
          <term><varname>conditions</varname></term>
          <listitem>
            <simpara>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 <literal>conditions.add()</literal> och <literal>conditions.discard()</literal> för att modifiera listan du vill göra ändringar i.</simpara>
            <simpara>Originaluppsättningen av villkor som bestäms på OS-basis och kan modifieras via kommandoradsargumentet <option>--conditions=</option>. Ändringarna som görs via <option>--conditions</option> 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 <option>--conditions</option> kommer att tillämpas igen efter att nya ändringar görs från jhbuildrc.</simpara>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>

    <section id="config-reference-other">
      <title>Andra strukturer i konfigurationsfilen</title>

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

      <variablelist>
        <varlistentry id="cfg-os-environ">
          <term><varname>os.environ</varname></term>
          <listitem>
            <para>En uppslagsbok som representerar miljön. Denna miljö skickas vidare till processer som JHBuild startar.</para>

            <para>Ett par inflytelserika miljövariabler är <envar>CPPFLAGS</envar>, <envar>CFLAGS</envar> <envar>INSTALL</envar> och <envar>LDFLAGS</envar>. Till exempel:</para>

<programlisting>os.environ['CFLAGS'] = '-O0 -g'</programlisting>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><function>addpath</function>(<parameter>miljövariabel</parameter>, <parameter>sökvägsnamn</parameter>)</term>
          <listitem>
            <para>Detta kommer att lägga till en katalog till miljövariabeln <envar>PATH</envar>. <function>addpath</function> 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).</para>
          </listitem>
        </varlistentry>
        <varlistentry>
          <term><function>prependpath</function>(<parameter>miljövariabel</parameter>, <parameter>sökvägsnamn</parameter>)</term>
          <listitem>
            <para>Efter att ha behandlat konfigurationsfilen kommer JHBuild att förändra vissa sökvägar baserat på variabler så som <varname>prefix</varname> (t.ex. genom att lägga till <literal>$prefix/bin</literal> i början av <envar>PATH</envar>).</para>

            <para>Funktionen <function>prependpath</function> fungerar som <function>addpath</function> förutom att miljövariabeln modifieras efter att JHBuild har gjort sina ändringar i miljön.</para>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>
  </section>

  <section id="moduleset-syntax">
    <title>Syntax för moduluppsättningsfilen</title>

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

    <para>Toppnivåelementet i en moduluppsättningsfil är elementet <sgmltag class="element">moduleset</sgmltag>. Ingen XML-namnrymd används. Elementen under toppnivån finns i tre typer: modulkällor, inkluderingssatser och moduldefinitioner.</para>

    <para>Innehållet i moduluppsättningsfilen kan inkluderas villkorat genom att använda taggen &lt;if&gt; 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 &lt;if condition-set='cond'&gt; eller &lt;if condition-unset='cond'&gt;. Villkoren sätts som standard per OS-basis men kan påverkas genom att ange variabeln <varname>condition</varname> i jhbuildrc eller kommandoradsargumentet <command>--conditions=</command>.</para>

    <section id="moduleset-syntax-sources">
      <title>Modulkällor</title>

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

      <para>Elementet <sgmltag class="element">repository</sgmltag> används för att beskriva alla typer av arkiv. Elementet <sgmltag class="element">branch</sgmltag> används inuti moduldefinitioner för att ange ytterligare inställningar.</para>

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

      <para>Attributet <sgmltag class="attribute">name</sgmltag> är en unik identifierare för arkivet.</para>

      <para>Attributet <sgmltag class="attribute">default</sgmltag> anger huruvida detta arkiv är standardkällan för denna moduluppsättning.</para>

      <para>Attributet <sgmltag class="attribute">type</sgmltag> anger arkivtypen. Den kan vara en av: <literal>bzr</literal>, <literal>cvs</literal>, <literal>darcs</literal>, <literal>fossil</literal>, <literal>git</literal>, <literal>hg</literal>, <literal>mnt</literal>, <literal>svn</literal>, <literal>tarball</literal>. Andra attribut beror på <sgmltag class="attribute">type</sgmltag>, så väl som <sgmltag class="element">branch</sgmltag> som används i moduldefinitioner. Dessa beskrivs nedan i underkapitlen om arkivtyper.</para>

      <para>Attributet <sgmltag class="attribute">developer-href-example</sgmltag> 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.</para>

      <para>Elementet <sgmltag class="element">branch</sgmltag> används inuti moduldefinitioner.</para>

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

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

      <para>Attributet <sgmltag class="attribute">repo</sgmltag> används för att ange arkivnamn som inte är standard.</para>

      <para>Attributet <sgmltag class="attribute">module</sgmltag> används för att ange modulnamn som ska checkas ut från arkivet. Standardvärdet är modul-ID:t.</para>

      <para>Attributet <sgmltag class="attribute">checkoutdir</sgmltag> används för att ange katalognamnet där utcheckning ska ske. Standardvärdet är modul-ID:t.</para>

      <para>Andra attribut beskrivs nedan</para>

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

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

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

        <para>Ytterligare attribut är: <sgmltag class="attribute">trunk-template</sgmltag> (standardvärdet är <literal>"%(module)s"</literal>) och <sgmltag class="attribute">branches-template</sgmltag> (standardvärdet är <literal>"%(module)s/%(branch)s</literal>"). Dessa attribut används för att ange mallar för konstruktion av URL:er. Ett <sgmltag class="element">branch</sgmltag>-element i moduldefinitionen kan ange <sgmltag class="attribute">branch</sgmltag>- och <sgmltag class="attribute">user</sgmltag>-attribut. Dessa värden kommer att ersättas i mallarna. Om någotdera av dem är definierade används <sgmltag class="attribute">branches-template</sgmltag>, annars används <sgmltag class="attribute">trunk-template</sgmltag>. 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.</para>

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

        <para>Ett exempel med ett arkiv som har <sgmltag class="attribute">template</sgmltag>-attribut definierade:</para>

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

        <para>Exempel med <sgmltag class="element">branch</sgmltag>-element för ovanstående arkiv:</para>

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

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

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

        <para>Denna arkivtyp används för att definiera ett CVS-arkiv.</para>

        <para>Attributet <sgmltag class="attribute">password</sgmltag> används för att ange lösenordet för arkivet.</para>

        <para>Attributet <sgmltag class="attribute">cvsroot</sgmltag> används för att ange roten för arkivet.</para>

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

<!-- TODO describe these attributes -->

        <para>Ytterligare attribut är: <sgmltag class="attribute">revision</sgmltag>, <sgmltag class="attribute">update-new-dirs</sgmltag> och <sgmltag class="attribute">override-checkoutdir</sgmltag>.</para>
      </section>

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

        <para>Denna arkivtyp används för att definiera ett Darcs-arkiv.</para>

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

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

        <para>Denna arkivtyp används för att definiera ett Git-arkiv.</para>

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

        <para>Den tillåter följande attribut för <sgmltag class="element">branch</sgmltag>-elementet:</para>

        <para>Attributet <sgmltag class="attribute">revision</sgmltag> 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 <varname>branches</varname>. 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.</para>

        <para>Attributet <sgmltag class="attribute">tag</sgmltag> används för att ange en revision att ovillkorligen checka ut i uppdateringsfasen. Den åsidosätter attributet <sgmltag class="attribute">revision</sgmltag>.</para>

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

<programlisting>
&lt;branch repo="git.freedesktop.org" module="swfdec/swfdec"
        checkoutdir="swfdec"
        revision="<replaceable>local-or-remote-branch</replaceable>"
        tag="<replaceable>tree-ish</replaceable>"/&gt;
        </programlisting>
      </section>

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

        <para>Denna arkivtyp används för att definiera ett Mercurial-arkiv.</para>

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

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

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

        <para>Denna arkivtyp används för att definiera ett Monotone-arkiv.</para>

        <para>Attributet <sgmltag class="attribute">server</sgmltag> används för att ange arkivservern.</para>

        <para>Attributet <sgmltag class="attribute">database</sgmltag> används för att ange databasen som ska användas för arkivet.</para>

        <para>Attributet <sgmltag class="attribute">defbranch</sgmltag> används för att ange grenen i arkivet som ska användas.</para>

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

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

        <para>Denna arkivtyp används för att definiera ett Subversion-arkiv.</para>

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

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

        <para>Den tillåter en <sgmltag class="attribute">revision</sgmltag> på elementet <sgmltag class="element">branch</sgmltag>. Detta attribut definierar grenen som ska checkas ut eller, om det är ett nummer, en specifik revision att checka ut.</para>

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

        <para>Det är möjligt att ange en anpassad <literal>svn</literal>-layout via <sgmltag class="attribute">trunk-template</sgmltag> (standardvärdet är "%(module)s/trunk"), <sgmltag class="attribute">branches-template</sgmltag> (standardvärdet är "%(module)s/branches/%(branch)s") och <sgmltag class="attribute">tags-template</sgmltag> (standardvärdet är "%(module)s/tags/%(tag)s")</para>
      </section>

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

        <para>Denna arkivtyp används för att definiera ett falskt systemarkiv. Ett systemarkiv krävs för att skapa <link linkend="moduleset-syntax-defs-systemmodule"><sgmltag class="element">systemmodules</sgmltag></link>.</para>

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

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

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

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

        <para>Den tillåter följande attribut för <sgmltag class="element">branch</sgmltag>-elementet:</para>

        <para>Attributet <sgmltag class="attribute">module</sgmltag> anger filen som ska hämtas och kompileras medan attributet <sgmltag class="attribute">version</sgmltag> anger modulversionen.</para>

        <para>Attributen <sgmltag class="attribute">size</sgmltag> och <sgmltag class="attribute">hash</sgmltag> så väl som det föråldrade attributet <sgmltag class="attribute">md5sum</sgmltag> är valfria. Om dessa attribut finns används de för att kontrollera att källkodspaketen hämtats korrekt.</para>

        <para>Attributet <sgmltag class="attribute">rename-tarball</sgmltag> 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.</para>

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

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

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

        <para>Ett <sgmltag class="element">branch</sgmltag>-element för ett tar-arkiv får också innehålla <sgmltag class="element">quilt</sgmltag>-element vilka anger nästlade <sgmltag class="element">branch</sgmltag> som ska importeras.</para>
      </section>
    </section>

    <section id="moduleset-syntax-includes">
      <title>Inkludering av andra moduluppsättningar</title>

      <para>JHBuild tillåter en moduluppsättning att inkludera innehållet från en annan genom att referera till den via <sgmltag class="element">include</sgmltag>-elementet.</para>

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

      <para><sgmltag class="attribute">href</sgmltag> är en URI-referens till moduluppsättningen som ska inkluderas, relativt till filen som innehåller <sgmltag class="element">include</sgmltag>-elementet.</para>

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

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

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

      <para>De består alla i grunden av ett <sgmltag class="element">branch</sgmltag>-element som beskriver hur man hämtar modulen samt <sgmltag class="element">dependencies</sgmltag>-, <sgmltag class="element">suggests</sgmltag>- och <sgmltag class="element">after</sgmltag>-element för att deklarera beroendena för modulen.</para>

      <para>Moduler som listas i elementet <sgmltag class="element">dependencies</sgmltag> kommer att läggas till i modullistan för <command>jhbuild build</command> om den inte redan finns där och säkerställa att den beroende modulen byggs först.</para>

      <para>Efter att ha genererat modullistan kommer moduler som listas i <sgmltag class="element">suggests</sgmltag>-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.</para>

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

        <para>Elementet <sgmltag class="element">autotools</sgmltag> används för att definiera en modul som ska kompileras via byggsystemet GNU Autotools.</para>

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

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

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

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

        <para>Attributen <sgmltag class="attribute">autogenargs</sgmltag> och <sgmltag class="attribute">makeargs</sgmltag> och <sgmltag class="attribute">makeinstallargs</sgmltag> används för att ange ytterligare argument som skickas till <command>autogen.sh</command>, <command>make</command> respektive <command>make install</command>.</para>

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

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

        <para>Attributet <sgmltag class="attribute">supports-non-srcdir-builds</sgmltag> används för att markera moduler som inte kan byggas korrekt i en separat källkodskatalog.</para>

        <para>Attributet <sgmltag class="attribute">force-non-srcdir-builds</sgmltag> används för att markera moduler som inte kan byggas korrekt från källkodskatalogen, men som kan byggas utanför den.</para>

        <para>Attributet <sgmltag class="attribute">autogen-template</sgmltag> 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:  <varname>srcdir</varname>, <varname>autogen-sh</varname>, <varname>prefix</varname>, <varname>libdir</varname> och <varname>autogenargs</varname>. Här är till exempel standardmallen för autogen:</para>

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

        <para>Attributet <sgmltag class="attribute">check-target</sgmltag> måste anges (med ett falskt värde) för moduler som inte har ett <command>make check</command>-mål.</para>

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

        <para>Attributet <sgmltag class="attribute">supports-unknown-configure-options</sgmltag> används för att markera moduler som kommer att misslyckas med fel om en okänd flagga skickas med till <filename>configure</filename>. Globala flaggor för configure kommer inte att användas för den modulen.</para>
      </section>

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

        <para>Elementet <sgmltag class="element">cmake</sgmltag> används för att definiera en modul som byggs via byggsystemet CMake.</para>

<programlisting>
  &lt;cmake id="<replaceable>modulnamn</replaceable>"
            [ skip-install="<replaceable>hoppa-över-installation</replaceable>" ]
            [ cmakedir="<replaceable>cmakekat</replaceable>" ]
            [ force-non-srcdir-builds="<replaceable>tvinga-icke-källkat-byggen</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

  &lt;dependencies&gt;
    &lt;dep package="<replaceable>modulnamn</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;after&gt;
    &lt;dep package="<replaceable>modulnamn</replaceable>"/&gt;
    ...
  &lt;/after&gt;
&lt;/cmake&gt;
</programlisting>

        <para>Attributet <sgmltag class="attribute">cmakedir</sgmltag> anger underkatalogen där cmake kommer köras i förhållande till srcdir.</para>

        <para>Attributet <sgmltag class="attribute">force-non-srcdir-builds</sgmltag> används för att markera moduler som inte kan byggas korrekt från källkodskatalogen, men som kan byggas utanför den.</para>
      </section>

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

        <para>Elementet <sgmltag class="element">meson</sgmltag> används för att definiera en modul som byggs via byggsystemet Meson.</para>

<programlisting>
  &lt;meson id="<replaceable>modulnamn</replaceable>"
            [ skip-install="<replaceable>hoppa-över-installation</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

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

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

        <para>Elementet <sgmltag class="element">distutils</sgmltag> används för att definiera en modul som byggs med pythons distutils.</para>

<programlisting>
&lt;distutils id="<replaceable>modulnamn</replaceable>"
            [ supports-non-srcdir-builds="<replaceable>yes|no</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

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


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

        <para>Elementet <sgmltag class="element">distutils</sgmltag> används för att definiera en modul som byggs med pythons distutils</para>

<programlisting>
&lt;distutils id="<replaceable>modulnamn</replaceable>"
            [ supports-non-srcdir-builds="<replaceable>yes|no</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

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

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

        <para>Elementet <sgmltag class="element">linux</sgmltag> 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 <sgmltag class="element">kconfig</sgmltag>.</para>

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

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

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

  &lt;kconfig [ repo="<replaceable>arkiv</replaceable>" ]
	    version="<replaceable>version</replaceable>"
	    [ module="<replaceable>modul</replaceable>" ]
	    [ config="<replaceable>konfiguration</replaceable>" ] /&gt;

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

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

        <para>Elementet <sgmltag class="element">perl</sgmltag> används för att bygga perl-moduler.</para>

        <para>Attributet <sgmltag class="attribute">makeargs</sgmltag> används för att ange ytterligare argument som ska skickas till <command>make</command>.</para>

<programlisting>
&lt;perl id="<replaceable>modulnamn</replaceable>"
	 [ makeargs="<replaceable>make-argument</replaceable>" ]&gt;

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

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

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

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

        <para>Elementet <sgmltag class="element">systemmodule</sgmltag> används för att ange moduler som måste tillhandahållas av systemet. Modulen bör finnas installerad av din distributions pakethanteringssystem.</para>

<programlisting>
&lt;systemmodule id="<replaceable>modulnamn</replaceable>"&gt;
  &lt;pkg-config&gt;<replaceable>pkg-config</replaceable>.pc&lt;/pkg-config&gt;

  &lt;branch repo="<replaceable>system</replaceable>" version="<replaceable>version</replaceable>" /&gt;
&lt;/systemmodule&gt;
</programlisting>

        <para>Om systemmodulen inte tillhandahåller en pkg-config-fil kan en <sgmltag class="element">systemdependencies</sgmltag>-tagg användas för att identifiera beroendena. Två värden stöds för <sgmltag class="attribute">type</sgmltag>-attributet för <sgmltag class="element">dep</sgmltag>-taggen:</para>

        <orderedlist>
          <listitem>
            <simpara>Värdet <sgmltag class="attvalue">path</sgmltag>. Sökvägen genomsöks efter ett matchande programnamn.</simpara>
          </listitem>
          <listitem>
            <simpara>Värdet <sgmltag class="attvalue">c_include</sgmltag>. C-inkluderingssökvägen genomsöks efter matchande huvudnamn. <sgmltag class="attribute">name</sgmltag> får inkludera en underkatalog. C-inkluderingssökvägen kan modifieras genom att sätta <varname>CPPFLAGS</varname> inom konfigurationsvariablerna <varname>cflags</varname> eller <link linkend="cfg-module-autogenargs"><varname>module_autogenargs</varname></link>.</simpara>
          </listitem>
        </orderedlist>

<programlisting>
&lt;systemmodule id="<replaceable>modulnamn</replaceable>"&gt;
  &lt;branch repo="<replaceable>system</replaceable>" version="<replaceable>version</replaceable>" /&gt;
  &lt;systemdependencies&gt;
    &lt;dep type="path" name="<replaceable>körbart-program</replaceable>" /&gt;
  &lt;/systemdependencies&gt;
&lt;/systemmodule&gt;

&lt;systemmodule id="<replaceable>modulnamn</replaceable>"&gt;
  &lt;branch repo="<replaceable>system</replaceable>" version="<replaceable>version</replaceable>" /&gt;
  &lt;systemdependencies&gt;
    &lt;dep type="c_include" name="<replaceable>huvudnamn</replaceable>" /&gt;
  &lt;/systemdependencies&gt;
&lt;/systemmodule&gt;
</programlisting>

        <para>Om systemmodulen kan installeras på olika platser eller installeras under olika namn av olika distributioner kan taggen <sgmltag class="element">altdep</sgmltag> användas som underelement till <sgmltag class="element">dep</sgmltag>-taggen för att ange alternativa platser eller namn. Taggen <sgmltag class="element">altdep</sgmltag> har stöd för samma attribut som taggen <sgmltag class="element">dep</sgmltag>.</para>

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

&lt;systemmodule id="<replaceable>modulnamn</replaceable>"&gt;
  &lt;branch repo="<replaceable>system</replaceable>" version="<replaceable>version</replaceable>" /&gt;
  &lt;systemdependencies&gt;
    &lt;dep type="c_include" name="<replaceable>huvudnamn</replaceable>"&gt;
      &lt;altdep type="c_include" name="<replaceable>alternativt-huvudnamn-1</replaceable>" /&gt;
      &lt;altdep type="c_include" name="<replaceable>alternativt-huvudnamn-2</replaceable>" /&gt;
      ...
    &lt;dep&gt;
  &lt;/systemdependencies&gt;
&lt;/systemmodule&gt;
</programlisting>
      </section>

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

        <para>Elementet <sgmltag class="element">waf</sgmltag> används för att definiera en modul som byggs med byggsystemet Waf.</para>

        <para>Attributet <sgmltag class="attribute">waf-command</sgmltag> används för att ange waf-kommandoskriptet som ska användas; standardvärdet är <command>waf</command>.</para>

        <para>Attributet <sgmltag class="attribute">python-command</sgmltag> används för att ange vilket körbart Python-program som ska användas; standardvärdet är <command>python</command>. Detta är användbart för att bygga moduler med version 3 av Python.</para>

<programlisting>
&lt;waf id="<replaceable>modulnamn</replaceable>"&gt;
	 [ python-command="<replaceable>python-kommando</replaceable>" ]
	 [ waf-command="<replaceable>waf-kommando</replaceable>" ]&gt;
  &lt;branch [ ... ] &gt;
    [...]
  &lt;/branch&gt;

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

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

        <para>Elementet <sgmltag class="element">testmodule</sgmltag> används för att skapa en modul som kör en svit av tester via LDTP eller Dogtail.</para>

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

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

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

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

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

        <para>Attributet <sgmltag class="attribute">type</sgmltag> 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”.</para>

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

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

        <para>Elementet <sgmltag class="element">metamodule</sgmltag> definierar en modul som egentligen inte gör någonting. Det enda syftet med en modul av denna typ är dess beroenden.</para>

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

<programlisting>
&lt;metamodule id="<replaceable>modulnamn</replaceable>"&gt;
  &lt;dependencies&gt;
    &lt;dep package="<replaceable>modulnamn</replaceable>"/&gt;
    ...
  &lt;/dependencies&gt;
  &lt;suggests&gt;
    &lt;dep package="<replaceable>modulnamn</replaceable>"/&gt;
    ...
  &lt;/suggests&gt;
&lt;/metamodule&gt;
</programlisting>

        <para>Attributet <sgmltag class="attribute">id</sgmltag> anger namnet på modulen. Barnelementen hanteras på samma sätt som för <link linkend="moduleset-syntax-defs-autotools"><sgmltag class="element">autotools</sgmltag></link>.</para>
      </section>
    </section>

    <section id="moduleset-deprecated-elements">
      <title>Föråldrade element</title>

      <section id="moduleset-deprecated-elements-syntax-sources">
        <title>Modulkällor</title>

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

          <para>Elementet <sgmltag class="element">cvsroot</sgmltag> är nu föråldrat - elementet <sgmltag class="element">repository</sgmltag> bör användas istället.</para>

          <para>Elementet <sgmltag class="element">cvsroot</sgmltag> används för att beskriva ett CVS-arkiv.</para>

<programlisting>
  &lt;cvsroot name="<replaceable>rotnamn</replaceable>"
           [ default="<replaceable>yes|no</replaceable>" ]
           root="<replaceable>anonym-cvrot</replaceable>"
           password="<replaceable>anonymt-lösenord</replaceable>"/&gt;
</programlisting>

          <para>Attributet <sgmltag class="attribute">name</sgmltag> bör vara en unik identifierare för CVS-arkivet.</para>

          <para>Attributet <sgmltag class="attribute">default</sgmltag> berättar huruvida detta är standardmodulkällan för den moduluppsättningsfilen.</para>

          <para>Attributet <sgmltag class="attribute">root</sgmltag> listar CVS-roten som används för anonym tillgång till detta arkiv, och attributet <sgmltag class="attribute">password</sgmltag> anger lösenordet som ska användas för anonym tillgång.</para>
        </section>

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

          <para>Elementet <sgmltag class="element">svnroot</sgmltag> är nu föråldrat - elementet <sgmltag class="element">repository</sgmltag> bör användas istället.</para>

          <para>Elementet <sgmltag class="element">svnroot</sgmltag> används för att beskriva ett Subversion-arkiv.</para>

<programlisting>
  &lt;svnroot name="<replaceable>rotnamn</replaceable>"
           [ default="<replaceable>yes|no</replaceable>" ]
           href="<replaceable>anonym-svn-rot</replaceable>"/&gt;
</programlisting>

          <para>Attributet <sgmltag class="attribute">name</sgmltag> bör vara en unik identifierare för Subversion-arkivet.</para>

          <para>Attributet <sgmltag class="attribute">default</sgmltag> berättar huruvida detta är standardmodulkällan för den moduluppsättningsfilen.</para>

          <para>Attributet <sgmltag class="attribute">href</sgmltag> listar bas-URL:en för arkivet. Detta kommer troligtvis antigen att vara en <literal>http</literal>-, <literal>https</literal>- eller en <literal>svn</literal>-URL.</para>
        </section>
      </section>

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

      <section>
        <title>Föråldrade modultyper</title>

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

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

          <important>
            <para>Detta föråldrade element är bara ett tunt omslag kring både modultypen <sgmltag class="element">autotools</sgmltag> och arkivtypen <sgmltag class="element">tarball</sgmltag>.</para>
          </important>

          <para>Elementet <sgmltag class="element">tarball</sgmltag> används för att definiera en modul som ska byggas från ett tar-arkiv.</para>

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

          <para>Attributen <sgmltag class="attribute">id</sgmltag> och <sgmltag class="attribute">version</sgmltag> används för att identifiera modulen.</para>

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

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

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

          <para>De andra attributen och elementen <sgmltag class="element">dependencies</sgmltag>, <sgmltag class="element">suggests</sgmltag> och <sgmltag class="element">after</sgmltag> behandlas som för <link linkend="moduleset-syntax-defs-autotools">autotools</link>.</para>
        </section>
      </section>

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

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