Archivo de sintaxis del conjunto de módulos
JHBuild usa archivos XML para describir las dependencias entre módulos. En JHBuild se incluyen esquemas RELAX-NG y Definición de Tipo de Documento en la carpeta modulesets/. El esquema RELAX-NG se puede usar para editar los archivos del conjunto de módulos usando nxml-mode en Emacs.
El elemento superior del archivo de un conjunto de módulos es el elemento moduleset. No se usa ningún nombre de espacio XML. El elemento a continuación del superior tiene tres tipos: fuentes de módulos, sentencias «include» y definiciones de módulos.
7.1. Repositorios de módulos
En lugar de listar la ubicación completa de todos los módulos, se muestra un número de «fuentes del módulo» en el conjunto de módulos, y se referencian por nombre en las definiciones de módulos. Aparte de reducir la cantidad de información redundante en el conjunto de módulos, hace más fácil para el usuario el especificar una fuente alternativa para esos módulos (para CVS y Subversion, es frecuente que desarrolladores y usuarios usen diferentes métodos de acceso al repositorio).
El elemento repositorio se usa para describir todos los tipos de repositorios. El elemento rama se usa dentro de la definición del módulo para indicar configuraciones adicionales.
<repository name="nombre" type="tipo" [ default="predeterminado" ] [ password="contraseña" ] [ cvsroot="cvsroot" ] [ archive="archivo" ] [ href="href" ] [ server="servidor" ] [ database="base de datos" ] [ defbranch="rama predeterminada" ] [ trunk-template="principal-plantilla" ] [ branches-template="ramas-plantilla" ] [ tags-template="etiquetas-plantilla" ] [ developer-href-example="ejemplo-href-desarrollador" ] />
El atributo nombre es un identificador único del repositorio.
El atributo predeterminado especifica si este repositorio es el predeterminado para este conjunto de módulos.
El atributo type especifica el tipo de repositorio. Puede ser uno de estos: arch, bzr, cvs, darcs, fossil, git, hg, mnt, svn, tarball. Hay otros atributos que dependen de type, así como de branch usados dentro de las definiciones de los módulos. Se describen a continuación en las subsecciones de tipo de repositorios.
El atributo developer-href-example se usa para especificar el formato del URL del repositorio usado por los desarrolladores. Esto es sólo informativo.
El elemento rama se usa dentro de las definiciones del módulo.
<branch [ repo="repositorio" ] [ module="nombre del módulo" ] [ checkoutdir="carpeta de descarga" ] [ revision="revisión" ] [ tag="etiqueta" ] [ update-new-dirs="actualizar carpetas nuevas" ] [ override-checkoutdir="omitir carpeta de descarga" ] [ subdir="subcarpeta" ] [ branch="rama" ] [ version="versión" ] [ size="tamaño" ] [ source-subdir="subcarpeta de fuentes" ] [ hash="hash" ]/>
Todos los atributos tienen valores predeterminados correctos y dependen del módulo y de las definiciones del repositorio. Aquí se describen los atributos comunes.
El atributo repo se usa para especificar un nombre de repositorio no predeterminado.
El atributo module se usa para especificar el nombre del módulo que descargar del repositorio. Su valor predeterminado es el identificador del módulo.
El atributo checkoutdir se usa para especificar la carpeta de descarga que usar. Su valor predeterminado es el identificador del módulo.
A continuación se describen otros atributos
- 7.1.1. Arch
- 7.1.2. Bazaar
- 7.1.3. CVS
- 7.1.4. Darcs
- 7.1.5. Git
- 7.1.6. Mercurial
- 7.1.7. Monotone
- 7.1.8. Subversion
- 7.1.9. Archivos tar
7.1.1. Arch
El tipo de repositorio se usa para definir un repositorio Arch.
El atributo archive se usa para especificar el archivo que usar.
El atributo href se usa para especificar el URL del repositorio.
<repository type="arch" name="rhythmbox" archive="rhythmbox-devel@gnome.org--2004" href="http://web.rhythmbox.org/arch/2004"/>
7.1.2. Bazaar
This repository type is used to define a Bazaar repository. It is recommended to have Bazaar 1.16 or higher.
<repository type="bzr" name="launchpad.net" href="lp:"/>
Additional attributes are: trunk-template (defaults to "%(module)s") and branches-template (defaults to "%(module)s/%(branch)s"). These attributes are used to specify templates for constructing URL. A branch element in the module definitions can specify branch and user attributes. These values will be substitued in the templates. If either of those are defined branches-template is used, otherwise trunk-template is used. This way you can ovveride repository to build modules from your personal branch or build many modules fron a repository with non-standard layout.
An addition branch element accepts revspec attibute to anchor on a particular revision. Any valid bzr revspec is accepted, for example date:yesterday, -5, tag:0.1 to get first revision since yesterday, 5 commits behind the tip or tag "0.1". See bzr help revisionspec for all possible values.
Ejemplo de repositorio con los atributos template definidos:
<repository type="bzr" name="launchpad.net" href="lp:" trunk-template="~bzr-pqm/%(module)s/bzr.dev" branches-template="~bzr-pqm/%(module)s/%(branch)s"/>
Ejemplo de elementos de la branch para el anterior repositorio:
<branch repo="launchpad.net" module="bzr" checkoutdir="bzr-next"/>
<branch repo="launchpad.net" module="bzr" branch="2.2" checkoutdir="bzr-beta"/>
7.1.3. CVS
El tipo de repositorio se usa para definir un repositorio CVS.
El atributo password se usa para especificar la contraseña del repositorio.
El atributo cvsroot se usa para especificar la raíz del repositorio.
<repository type="cvs" name="tango.freedesktop.org" cvsroot=":pserver:anoncvs@anoncvs.freedesktop.org:/cvs/tango" password=""/>
Los atributos adicionales son: revision, update-new-dirs y override-checkoutdir.
7.1.4. Darcs
El tipo de repositorio se usa para definir un repositorio Darcs.
<repository type="darcs" name="telepathy.freedesktop.org" href="http://projects.collabora.co.uk/darcs/telepathy/"/>
7.1.5. Git
El tipo de repositorio se usa para definir un repositorio Git.
<repository type="git" name="git.freedesktop.org" href="git://anongit.freedesktop.org/git/"/>
Permite los siguientes atributos en el elemento branch:
The revision attribute is used to specify a local or remote-tracking branch to switch to in the update phase. It defaults to 'master'. It is possible to override this attribute with the branches configuration variable. The switch will only be performed, if the current branch is tracking a remote branch, to not disturb your own work.
The tag attribute is used to specify a revision to unconditionally check out in the update phase. It overrides the revision attribute.
<branch repo="git.freedesktop.org" module="swfdec/swfdec" checkoutdir="swfdec" revision="local-or-remote-branch" tag="tree-ish"/>
7.1.6. Mercurial
El tipo de repositorio se usa para definir un repositorio Mercurial.
<repository type="hg" name="hg.gtk-vnc" href="http://gtk-vnc.codemonkey.ws/hg/" />
<branch repo="hg.gtk-vnc" module="outgoing.hg" checkoutdir="gtk-vnc"/>
7.1.7. Monotone
El tipo de repositorio se usa para definir un repositorio Monotone.
El atributo server se usa para especificar el servidor del repositorio.
El atributo database se usa para especificar la base de datos que usar por el repositorio.
El atributo defbranch se usa para especificar la rama del repositorio que usar.
<repository type="mtn" name="pidgin.im" server="pidgin.im" database="pidgin.im.mtn" defbranch="im.pidgin.pidgin"/>
7.1.8. Subversion
El tipo de repositorio se usa para definir un repositorio Subversion.
<repository type="svn" name="svn.gnome.org" default="yes" href="http://svn.gnome.org/svn/"/>
Permite una revision en el elemento branch. Este atributo define la rama que se descargará o, si es un número, una revisión específica para descargar.
<branch revision="gnome-2-20"/>
Es posible especificar una disposición de svn personalizada usando trunk-template (el predeterminado es «%(module)s/trunk»), branches-template (el predeterminado es «%(module)s/branches/%(branch)s») y tags-template (el predeterminado es «%(module)s/tags/%(tag)s»)
7.1.9. Archivos tar
El tipo de repositorio se usa para definir un repositorio de archivos tar.
<repository type="tarball" name="dbus/dbus-python" href="http://dbus.freedesktop.org/releases/dbus-python/"/>
Permite los siguientes atributos en el elemento branch:
El atributo module especifica el archivo que se descargará y compilará; el atributo version especifica la versión del módulo.
Los atributos size y hash, al igual que el obsoleto md5sum, son opcionales. Si estos atributos están presentes, se usan para comprobar que el paquete fuente se ha descargado correctamente.
El elemento patches se utiliza para especificar uno o más parches para aplicarlos al árbol de fuentes después de descomprimirlo. El atributo file contiene el nombre el nombre de archivo del parche y el atributo strip dice a cuántos niveles de carpetas se descenderá al aplicar el parche.
Para conjuntos de módulos empaquetados con JHBuild, los archivos de parches se buscan en la carpeta jhbuild/patches/; para conjuntos de módulos referidos por el URI, los archivos de parches se buscan en la misma carpeta que el archivo del conjunto de módulos, o en su subcarpeta patches/. También es posible que el atributo file especifique un URI, en cuyo caso se descargará de esa ubicación.
<branch module="dbus-python-0.80.2.tar.gz" version="0.80.2" repo="dbus/dbus-python" hash="md5:2807bc85215c995bd595e01edd9d2077" size="453499"> <patches> <patch file="dbus-glib-build.patch" strip="1" /> </patches> <branch>
7.2. Incluir otros conjuntos de módulos
JHBuild permite un conjunto de módulos para incluir los contenidos referidos por otro usando el elemento include.
<include href="uri"/>
El atributo href es una referencia al URI del conjunto de módulos que se incluirá, relativa al archivo que contiene el elemento include.
Desde el conjunto de módulos referenciado sólo se importan definiciones de módulos; no fuentes de módulos. Se permiten múltiples niveles de inclusión, pero no bucles (en este momento no hay ningún código para manejar bucles).
7.3. Definiciones de módulos
Hay varios tipos de definiciones de módulos que se pueden usar en un archivo de conjunto de módulos, y la lista se puede extender fácilmente. Aquí sólo se mencionan los más comunes.
Todos ellos están compuestos básicamente de un elemento branch que describe cómo obtener el módulo y unos elementos dependencies, suggests y after para declarar las dependencias del módulo.
jhbuild build añadirá a la lista de módulos todos los módulos listados en el elemento dependencies, si no están ya incluidos, y se asegurará que los módulos dependientes se construyen primero.
Después de generar la lista de módulos, los módulos listados en el elemento suggests se usarán para ordenar la futura lista de módulos (aunque no añadirá módulos adicionales). Esto se hace para casos en que un módulo tiene dependencias opcionales en otro módulo.
- 7.3.1. autotools
- 7.3.2. cmake
- 7.3.3. distutils
- 7.3.4. linux
- 7.3.5. perl
- 7.3.6. waf
- 7.3.7. Ant
- 7.3.8. testmodule
- 7.3.9. metamodule
7.3.1. autotools
El elemento autotools se usa para definir un módulo que se compila usando el sistema de construcción GNU Autotools.
<autotools id="id" [ autogenargs="argumentos de autogen" ] [ makeargs="argumentos de make" ] [ makeinstallargs="argumentos de make install" ] [ autogen-sh="autogen-sh" ] [ makefile="makefile" ] [ skip-autogen="skip-autogen" ] [ autogen-template="plantilla autogen" ] [ check-target="check-target" ] [ supports-non-srcdir-builds="supports-non-srcdir-builds" ]> <branch [ ... ] > [...] </branch> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <after> <dep package="nombre del módulo"/> ... </after> </autotools>
Los atributos autogenargs, makeargs y makeinstallargs se usan para especificar argumentos adicionales para pasarlos a autogen.sh, make y make install respectivamente.
El atributo autogen-sh especifica el nombre del script autogen.sh que se ejecutará. Se puede usar el valor autoreconf si su módulo no tiene un script autogen.sh equivalente. En este caso, JHBuild ejecutará autoreconf -i, seguido del configure apropiado. skip-autogen decide si se ejecuta autogen.sh o no, es un valor booleano con un valor never adicional para indicar a JHBuild que nunca omita la ejecución de autogen.sh. makefile especifica el nombre del makefile que se usará.
El atributo supports-non-srcdir-builds se usa para marcar módulos que no se pueden construir limpiamente usando una carpeta de fuentes por separado.
El atributo autogen-template se puede usar si necesita mayor control sobre el comando autogen. Es una cadena en formato Python que se sustituirá con las siguientes variables: srcdir, autogen-sh, prefix, libdir y autogenargs. Por ejemplo, esta es la plantilla predeterminada de autogen:
%(srcdir)s/%(autogen-sh)s --prefix %(prefix)s --libdir %(libdir)s %(autogenargs)s
El atributo check-target se debe especificar (con un valor «false») para aquellos módulos que no tienen un objetivo make check.
7.3.2. cmake
El elemento cmake se usa para definir un módulo que se construirá usando el sistema de construcción CMake.
<cmake id="nombre del módulo"> <branch [ ... ] > [...] </branch> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <after> <dep package="nombre del módulo"/> ... </after> </cmake>
7.3.3. distutils
El elemento distutils se usa para definir un módulo que se construirá usando las distutils de python.
<distutils id="nombre del módulo" [ supports-non-srcdir-builds="sí|no" ]> <branch [ ... ] > [...] </branch> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <after> <dep package="nombre del módulo"/> ... </after> </distutils>
7.3.4. linux
El elemento linux define un módulo usado para construir un kernel linux. Además, se puede seleccionar una configuración del kernel aparte usando el subelemento kconfig.
<linux id="id" [ makeargs="argumentos de make" ]> <branch [ ... ] > [...] </branch> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <after> <dep package="nombre del módulo"/> ... </after> <kconfig [ repo="repositorio" ] version="versión" [ module="módulo" ] [ config="configuración" ] /> </linux>
7.3.5. perl
El elemento perl se usa para construir módulos perl.
El atributo makeargs se usa para especificar argumentos adicionales para pasárselos a make.
<perl id="nombre del módulo" [ makeargs="makeargs" ]> <branch [ ... ] > [...] </branch> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <after> <dep package="nombre del módulo"/> ... </after> </perl>
7.3.6. waf
El elemento waf se usa para definir un módulo que se construirá con el sistema de construcción Waf.
El atributo waf-command se usa para especificar el script del comando waf a usar; el predeterminado es waf.
<waf id="nombre del módulo"> [ waf-command="waf-command" ]> <branch [ ... ] > [...] </branch> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <after> <dep package="nombre del módulo"/> ... </after> </waf>
7.3.7. Ant
El elemento ant se usa para definir un módulo que se construirá usando Ant, la herramienta de construcción basada en Java.
<ant id="nombre del módulo"> <branch [ ... ] > [...] </branch> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <after> <dep package="nombre del módulo"/> ... </after> </ant>
7.3.8. testmodule
El elemento testmodule se usa para crear un módulo que ejecute un conjunto de pruebas usado LDTP o Dogtail.
<testmodule id="id" type="tipo"> <branch [ ... ] > [...] </branch> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <after> <dep package="nombre del módulo"/> ... </after> <testedmodules> <tested package="paquete" /> </testedmodules> </testmodule>
El atributo type contiene el tipo de pruebas que ejecutar en el módulo. «dogtail» usa Python para invocar a todos los archivos .py. «ldtp» invoca «ldtprunner run.xml».
A menos que la opción de configuración «noxvfb» esté establecida, se inicia un servidor Xvfb para ejecutar las pruebas en él
7.3.9. metamodule
El elemento metamodule define un módulo que actualmente no hace nada. El único propósito de un módulo de este tipo son sus dependencias.
Por ejemplo, meta-gnome-desktop depende de todos los elementos clave del escritorio GNOME, por lo que actualmente, decirle a JHBuild que lo instale, instala el escritorio completo.
<metamodule id="nombre del módulo"> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <suggests> <dep package="nombre del módulo"/> ... </suggests> </metamodule>
El atributo id proporciona el nombre del módulo. Los elementos hijos se manejan igual que para autotools.
7.4. Elementos obsotelos
- 7.4.1. Repositorios de módulos
- 7.4.2. Tipos de módulos obsoletos
7.4.1. Repositorios de módulos
- 7.4.1.1. cvsroot
- 7.4.1.2. svnroot
- 7.4.1.3. arch-archive
7.4.1.1. cvsroot
El elemento cvsroot está obsoleto; en su lugar, se debe usar el elemento repository.
El elemento cvsroot se usa para describir un repositorio CVS.
<cvsroot name="nombre del raíz" [ default="sí|no" ] root="cvsroot-anónimo" password="contraseña-anónima"/>
El atributo name debe ser un identificador único para el repositorio CVS.
El atributo default indica si es el repositorio de módulos predeterminados para ese archivo de conjuntos de módulos.
El atributo root lista la raíz de CVS usada para acceso anónimo a este repositorio, y el atributo password da la contraseña usada para el acceso anónimo.
7.4.1.2. svnroot
El elemento svnroot está obsoleto; en su lugar se debe usar el elemento repository.
El elemento svnroot se usa para describir un repositorio de Subversion.
<svnroot name="nombre del raíz" [ default="sí|no" ] href="svnroot-anónimo"/>
El atributo name debe ser un identificador único para el repositorio de Subversion.
Si el atributo default indica si si este repositorio es el predeterminado para este conjunto de módulos.
El atributo href lista el URL base del repositorio. Probablemente será un URL http, https o svn.
7.4.1.3. arch-archive
El elemento arch-archive está obsoleto; en su lugar se debe usar el elemento repository.
El elemento arch-archive se usa para describir un archivo de GNU Arch.
<arch-archive name="nombre del archivo" [ default="sí|no" ] href="url del repositorio"/>
El atributo name debe ser un nombre de archivo Arch.
Si el atributo default indica si si este repositorio es el predeterminado para este conjunto de módulos.
El atributo href lista el URL de un repositorio del archivo.
7.4.2. Tipos de módulos obsoletos
Esta sección describe elementos obsoletos, aún se deben usar en conjuntos de módulos existentes, pero se recomienda que no se usen más.
- 7.4.2.1. archivo tar
7.4.2.1. archivo tar
El elemento obsoleto es sólo una fina envoltura alrededor del tipo de módulo autotools y del tipo de repositorio tarball.
El elemento tarball se usa para definir un módulo que se construirá a partir de un archivo tar.
<tarball id="nombre del módulo" [ version="versión" ] [ checkourdir="carpeta de descarga" ] [ autogenargs="argumentos de autogen" ] [ makeargs="argumentos de make" ] [ autogen-sh="autogen-sh" ] [ supports-non-srcdir-builds="sí|no" ]> <source href="url fuente" [ size="tamaño fuente" ] [ hash="algoritmo-del-fuente:hash-del-fuente" ] [ md5sum="suma md5 del fuente" ]/> <patches> <patch file="nombre del archivo" strip="nivel"/> ... </patches> <dependencies> <dep package="nombre del módulo"/> ... </dependencies> <suggests> <dep package="nombre del módulo"/> ... </suggests> </tarball>
Los atributos id y version se usan para identificar el módulo.
El elemento source especifica el archivo que se descargará y compilará. El atributo href es obligatorio mientras que los atributos size y hash, al igual que el obsoleto md5sum, son opcionales. Si los dos últimos están presentes, se usan para comprobar que el paquete fuente se ha descargado correctamente.
El elemento patches se utiliza para especificar uno o más parches para aplicarlos al árbol de fuentes después de descomprimirlo. El atributo file contiene el nombre el nombre de archivo del parche y el atributo strip dice a cuántos niveles de carpetas se descenderá al aplicar el parche.
Para conjuntos de módulos empaquetados con JHBuild, los archivos de parches se buscan en la carpeta jhbuild/patches/; para conjuntos de módulos referidos por el URI, los archivos de parches se buscan en la misma carpeta que el archivo del conjunto de módulos, o en su subcarpeta patches/. También es posible que el atributo file especifique un URI, en cuyo caso se descargará de esa ubicación.
Los otros atributos y los elementos dependencies, suggests y after se procesan igual que para autotools.