Syntax för moduluppsättningsfilen

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

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

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

7.1. Modulkällor

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

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

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

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

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

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

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

Elementet branch används inuti moduldefinitioner.

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

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

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

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

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

Andra attribut beskrivs nedan

7.1.1. Bazaar

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

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

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

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

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

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

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

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

7.1.2. CVS

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

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

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

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

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

7.1.3. Darcs

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

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

7.1.4. Git

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

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

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

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

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

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

7.1.5. Mercurial

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

<repository type="hg" name="hg.gtk-vnc"
    href="http://gtk-vnc.codemonkey.ws/hg/" />
<branch repo="hg.gtk-vnc" module="outgoing.hg" checkoutdir="gtk-vnc"/>

7.1.6. Monotone

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

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

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

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

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

7.1.7. Subversion

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

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

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

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

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

7.1.8. System

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

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

7.1.9. Tar-arkiv

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

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

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

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

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

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

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

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

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

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

7.2. Inkludering av andra moduluppsättningar

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

<include href="uri"/>

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

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

7.3. Moduldefinitioner

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

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

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

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

7.3.1. autotools

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

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

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

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

</autotools>

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

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

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

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

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

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

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

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

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

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

7.3.2. cmake

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

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

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

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

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

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

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

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

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

7.3.3. Meson

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

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

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

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

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

7.3.4. distutils

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

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

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

7.3.5. linux

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

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

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

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

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

</linux>

7.3.6. perl

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

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

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

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

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

</perl>

7.3.7. systemmodule

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

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

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

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

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

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

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

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

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

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

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

7.3.8. waf

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

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

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

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

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

7.3.9. testmodule

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

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

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

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

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

</testmodule>

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

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

7.3.10. metamodule

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

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

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

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

7.4. Föråldrade element

7.4.1. Modulkällor

7.4.1.1. cvsroot

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

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

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

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

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

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

7.4.1.2. svnroot

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

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

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

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

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

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

7.4.2. Föråldrade modultyper

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

7.4.2.1. tar-arkiv

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

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

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

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

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

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

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

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