# JHBuild マニュアル

## はじめに

JHBuild は モジュール(modules) と呼ばれる、ソース パッケージのあつまりを、簡単にビルドできるように作られたツールです。JHBuild はビルドできるモジュールの記述に、モジュール セット(module set) というファイルを使います。モジュール セット ファイルには、JHBuild があるモジュールをビルドするのに、何を必要としているかを見つけるための、依存関係の情報が含まれています。

JHBuild のオリジナルは GNOME をビルドするために作られましたが、その後、他のプロジェクトでも使用できるように拡張されています。モジュール セット ファイルはウェブ サーバー上に置くことができるので、JHBuild プロジェクトのビルド ルールとは独立させることができます。

JHBuild can build modules from a variety of sources, including CVS, Subversion, Bazaar, Darcs, Git and Mercurial repositories, as well as Tar and Zip archives hosted on web or FTP sites. JHBuild can build modules using a variety of build systems, including Autotools, CMake, WAF, Python Distutils and Perl Makefiles.

JHBuild は、ディストリビューションのパッケージ管理システムを置き換えるものではありません。JHBuild は、インストール先を prefix によって分離することにより、システムの他の部分に影響を及ぼすことなくソフトウェアをビルドするのを簡単にします。

## さあ、はじめましょう

JHBuild でソフトウェアをビルドする前に、いくつかのセットアップを実行する必要があります。JHBuild には前提条件となるいくつかのソフトウェアがあるので、モジュールの取得やビルドに必要な、それらのツールをインストールする必要があります。

### JHBuild のインストール

JHBuild には Python の実行環境が必要です。Python >= 2.3 がインストールされていることを確認してください。

JHBuild のダウンロードは、`git` バージョン管理システムからダウンロードする方法を推奨します。これは、以下のコマンドにより行うことができます。コマンドは、`~/checkout/gnome` のような、すべてのソースコードのインストール先となる、新しいディレクトリから実行することを推奨します。

    $ git clone git://git.gnome.org/jhbuild
    ...
    $

これにより、現在のディレクトリ配下に `jhbuild` という新しいディレクトリが作成され、そこに JHBuild がダウンロードされます。次に JHBuild のビルド、およびインストールを行います:

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

If gnome-common, yelp-tools and autotools are available, `autogen.sh` will configure JHBuild to install via autotools. If gnome-common, yelp-tools and autotools are not available, `autogen.sh` will configure JHBuild to install via a plain Makefile. To always use the plain Makefile method pass `--simple-install` to `autogen.sh`.

上記の手順が正常に終了すると、JHBuild を起動するための小さなシェルスクリプトが、`~/.local/bin` にインストールされるので、`~/.local/bin` を `PATH` に加えます:

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

常に `~/.local/bin` を `PATH` に追加したい場合は、以下のコマンドを実行してください:

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

JHBuild を実行する前に、`~/.jhbuildrc` という設定ファイルをセットアップする必要があります。

### JHBuild の設定

The `~/.jhbuildrc` file uses Python syntax to set configuration variables for JHBuild. An example is provided with JHBuild, see `examples/sample.jhbuildrc`. Copy `examples/sample.jhbuildrc` to `~/.jhbuildrc` and customize as required.

The sample configuration will make JHBuild build the meta-gnome-core and meta-gnome-apps-tested modules and dependencies from the `gnome-apps` module set. JHBuild will unpack source trees to `~/checkout/gnome` and install all files to subdirectories of `/opt/gnome`. The two directories must be writable.

設定の変数については、config-reference を参照してください。最も一般的に使用される変数には、以下のものがあります:

`repos`

- あるリポジトリにたいして、リポジトリの場所を指定するディクショナリ (訳注:Python の辞書型のこと。他言語での連想配列に相当) です。この変数はモジュール開発者にとって便利です。デフォルトでは、JHBuild は匿名のリポジトリからコードをチェックアウトします。ディクショナリのキーはリポジトリの略称で、値は代わりとなるリポジトリの場所をあらわす文字列です。例:

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

`moduleset`

- モジュール セットの名前を指定する文字列、または文字列のリスト(配列)です。これは JHBuild に含まれるファイル名(パスと拡張子を除く)、または 外部で管理されているモジュール セットの完全な HTTP URL のどちらでも構いません。HTTP URL のモジュール セットは、ローカルにキャッシュされます。2つ以上のモジュールセットに対して同じ名前が与えられていた場合は、最後のセットが優先されます。JHBuild により提供されるモジュール セットは、その時の GNOME の開発リリースに合わせて更新されます。

`modules`

- A list of strings specifying the modules to build. The list of modules actually built will be recursively expanded to include all the dependencies unless the `buildone` command is used. Defaults to `['meta-gnome-desktop']`.

`checkoutroot`

- A string specifying the directory to unpack source trees to. Unless `buildroot` is set, builds will occur in this directory too. Defaults to `~/checkout/gnome`.

`prefix`

- A string specifying the prefix to install modules to. `prefix` must be an absolute path. This directory must be writable. Defaults to `'/opt/gnome'`.

`autogenargs`

- A string containing arguments passed to the `autogen.sh` script of all modules. Can be overridden for particular modules using the `module_autogenargs` dictionary.

`makeargs`

- `make` に渡す追加の引数の文字列リストです。デフォルトは `''` です。

### ビルドの前提条件

Before any modules can be built, it is necessary to have certain build tools installed. Common build tools include the GNU Autotools (autoconf, automake, libtool and gettext), The GNU Toolchain (binutils, gcc, g++), make, pkg-config and Python, depending on which modules will be built.

JHBuild は `sanitycheck` コマンドを使用することにより、ツールがインストールされているかをチェックすることができます:

    $ jhbuild sanitycheck

もしこのコマンドが何らかのメッセージを表示した場合、以下の2つのうちどちらかの方法でエラーを修正することができます:

1. ディストリビューションのリポジトリから、必要なパッケージをインストールします。各ディストリビューションの パッケージの名前 の一覧は、GNOME wiki で保守されています。ディストリビューションの必要なパッケージをインストールしたと確信できたら、`sanitycheck` コマンドを再び実行してください。

2. `bootstrap` コマンドを実行して、ビルドの前提条件となるツールをダウンロード、ビルド、そしてインストールします:

       $ jhbuild bootstrap

   完了したら、`sanitycheck` コマンドを実行して、必要なツールが存在するか確認します。

   `bootstrap` コマンドは、必要なビルド ツールが依存するパッケージすべてのビルドはしません。あなたのディストリビューションが必要なパッケージを提供していない場合は、それらを JHBuild の環境の外でビルドする必要があります。

   ビルド ツールの依存関係には、m4、perl そして C コンパイラ (例えば、gcc) が含まれます。

### JHBuild を使用する

セットアップが完了すると、ソフトウェアをビルドするのに JHBuild を使用できるようになります。`~/.jhbuildrc` ファイルで選択されたモジュールをすべてビルドするには、以下のコマンドを実行します:

    $ jhbuild build

JHBuild は、それぞれのモジュールのダウンロード、configure、コンパイル、そしてインストールを行います。どこかのステージでエラーが発生した場合、JHBuild はメニューを表示して、何をするべきかを尋ねます。選択肢にはエラーを訂正するためにシェルを開く、さまざまなステージからのビルドの再実行、そのモジュールを諦める、エラーを無視して処理を続行する、などが含まれます。

「このモジュールをビルドしない」を選択した場合、そのモジュールに依存するモジュールのビルドも失敗することになります。

表示されるメニューの例です:

      [1] Rerun phase build
      [2] Ignore error and continue to install
      [3] Give up on module
      [4] Start shell
      [5] Reload configuration
      [6] Go to phase "wipe directory and start over"
      [7] Go to phase "configure"
      [8] Go to phase "clean"
      [9] Go to phase "distclean"
    choice:

`build` コマンドの引数にモジュールの名前を渡すことにより、異なるモジュール セットと依存するモジュールをビルドすることができます。例えば 、以下は gtk+ をビルドする例です:

    $ jhbuild build gtk+

もしビルドの途中で JHBuild がキャンセルされた場合、`--start-at` オプションを使用して特定のモジュールからビルドを再開することができます:

    $ jhbuild build --start-at=pango

1つ(または複数)のモジュールを、依存関係を無視してビルドするために、JHBuild は `buildone` コマンドを提供しています。`buildone` コマンドが正常に終了するには、依存するモジュールが事前にビルド、インストールされているか、ディストリビューションのパッケージが提供されていなければなりません。

    $ jhbuild buildone gtk+

When actively developing a module, you are likely in a source working directory. The `make` will invoke the build system and install the module. This will be a key part of your edit-compile-install-test cycle.

    $ jhbuild make

もしビルドの途中で JHBuild がキャンセルされた場合、`--start-at` オプションを使用して特定のモジュールからビルドを再開することができます:

JHBuild がビルドしようとするモジュールと依存関係、その他のビルドされるモジュールの一覧を得るためには、`list` コマンドを使用します:

    $ jhbuild list

特定のモジュールの情報を取得するには、`info` コマンドを使用します:

    $ jhbuild info gtk+

ビルドせずにソフトウェアのソースをダウンロード、更新だけを行うには、`update` コマンドを使用します。`update` コマンドはビルドする前にソースを修正する機会を提供します。またインターネットの帯域幅が変化する場合に便利です。

    $ jhbuild update

後から、JHBuild はソースをダウンロードしたり更新することなく、すべてをビルドすることができます:

    $ jhbuild build --no-network

JHBuild で使用しているのと同じ環境で特定のコマンドを実行するには、`run` コマンドを使用します:

    $ jhbuild run program

JHBuild で使用しているのと同じ環境でシェルを起動するには、`shell` コマンドを使用します:

    $ jhbuild shell

## JHBuild と GNOME

このセクションでは、GNOME をビルド、インストール、実行するガイダンスを提供します。

### GNOME をビルドする

GNOME をビルドするためには、以下に示すようないくつかの開発用パッケージが必要となります:

- XML カタログ(`/etc/xml/catalog`)を登録するために、DocBook XML DTD と XSLT スタイル シートが必要です。

- X ライブラリ

- Samba のための `libsmbclient`(Windows ネットワークのブラウジングで使用)。

- bzip2 のための `libbz2`。

- `libpng`、`libjpeg`、`libtiff` (イメージのロードで使用)。

ディストリビューションのパッケージをインストールする場合、ディストリビューションに適合するようならば、対応する dev、または devel パッケージをインストールしてください。それぞれのディストリビューションのために、パッケージの名前 のリストが GNOME wiki で保守されています。

### GNOME アプリケーションを単独で実行する

ここでは、単独の GNOME アプリケーションを実行する方法について説明します。アプリケーションは現在のデスクトップ環境で実行できるはずです。アプリケーションを JHBuild で構築した GNOME で実行する方法については、running-gnome を参照してください。

JHBuild のシェルを起動してください。JHBuild のシェルには、必要となるすべての環境変数が設定されています。

    $ jhbuild shell

実行するアプリケーションが正しいことを確認します。例:

    $ which gedit
    /opt/gnome/bin/gedit

アプリケーションを実行します:

    $ gedit &

`run` コマンドでアプリケーションを実行することもできます:

    $ jhbuild run gedit

### GNOME デスクトップ環境の実行

JHBuild の GNOME を実行するための、新しいアカウントを作成します。ホーム ディレクトリに保存された設定に起因する問題を無視するために、JHBuild の GNOME のために異なるユーザー アカウントを使用することを推奨します。このマニュアルでは、新しいアカウントを `gnomedev` として説明します。

新しく作成した `gnomedev` アカウントの、JHBuild 環境をセットアップします。`gnomedev` のホーム ディレクトリに、`~/.jhbuildrc` と `~/.local/bin/jhbuild` のソフト リンクを作成します。

`gnomedev` ユーザーで端末を開いてください。以下のコマンドにより、`PATH` 変数に `~/.local/bin` を追加します:

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

JHBuild が動作することを確認します:

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

#### GNOME をディスプレイ マネージャーで実行するためのセットアップ

JHBuild の GNOME をビルド、およびインストールします。

システム サービスを有効にします。JHBuild の GNOME は、`/usr/bin` のシステム D-Bus デーモンと、`/usr/share/dbus-1/system-services/` のシステム サービスを使用します。また、JHBuild の GNOME は、JHBuild のセッション D-Bus デーモンと、``/opt/gnome`/share/dbus-1/services/` のサービスを使用します。以下のコマンドで、GNOME の `prefix` (インストール先)を置き換えてください:

    $ rm -rf /opt/gnome/var/run/dbus
    $ ln -s /var/run/dbus /opt/gnome/var/run/dbus
    $ rm -rf /opt/gnome/var/lib/dbus/machine-id
    $ ln -s /var/lib/dbus/machine-id /opt/gnome/var/lib/dbus/machine-id

以下の内容で GNOME の起動スクリプト `/usr/bin/gnome-jhbuild-session` を作成してください。GNOME は `prefix` (インストール先)で置き換えます:

    #!/bin/sh

    GNOME=/opt/gnome

    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

`/usr/bin/gnome-jhbuild-session` のモードを実行可能に設定します:

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

ディスプレイ マネージャーに新しいセッションを追加するために、`/usr/share/xsessions/gnome-jhbuild.desktop` を作成して、以下を入力します:

    [Desktop Entry]
    Name=GNOME (JHBuild)
    Comment=This session logs you into GNOME testing session
    TryExec=/usr/bin/gnome-jhbuild-session
    Exec=/usr/bin/gnome-jhbuild-session
    Icon=
    Type=Application

`gdm` を再起動します。

#### ディスプレイ マネージャーから GNOME を起動する

JHBuild の GNOME を実行するには、`gnomedev` のログイン情報を入力する前に、ディスプレイ マネージャーで GNOME (JHBuild) セションを選択します。成功した場合は、JHBuild の GNOME が表示されます。不成功の場合は、`~gnomedev/.xsession-errors` ファイルのログを確認してください。

## Buildbot との統合

Buildbot と共に使用することにより、JHBuild を継続的な統合ツールとして機能させることができます。Buildbot の設定は、build.gnome.org の GNOME プロジェクトで使用されています。

### Buildbot スレーブ を設定する

Buildbot スレーブは、JHBuild の通常インストールのバリエーションであり、Buildbot マスターへのリクエストを提供します。Buildbot のカスタマイズを追加する前に、JHBuild をセットアップして、ほとんどのモジュールを正常にビルドできるようにしておくことを推奨します。

Buildbot コマンドは、`bot` コマンドのオプションとして指定します。必要なソフトウェアを追加でダウンロード、インストールするには、以下のコマンドを実行します:

    $ jhbuild bot --setup

このステップが1度正常に完了すると、`~/.jhbuildrc` に3つの新しい設定が必要になります。

かわりの設定ファイルを使用することはできません。`--file` は期待した効果をもたらしません。

    jhbuildbot_master = 'build.gnome.org:9070'
    jhbuildbot_slavename = 'slavename'
    jhbuildbot_password = 'password'

`jhbuildbot_master` は Buildbot マスター サーバーを指定する文字列です; デフォルトは `'build.gnome.org:9070'` です。`jhbuildbot_slavename` と `jhbuildbot_password` は、マスター サーバーでスレーブを識別するためのものです。スレーブの名前とパスワードについては、Buildbot マスターの管理者に連絡してください。

build.gnome.org の管理者には、Build Brigade mailing list で連絡することができます。

## コマンド リファレンス

JHBuild は CVS のようなツールと似たコマンド ライン構文を使用します:

    jhbuild
          global-options
          command
          command-arguments

以下は JHBuild 全体のオプションです:

`-f`, `--file` `config`

- `~/.jhbuildrc` のかわりに、指定された設定ファイルを使用します。

`-m`, `--moduleset` `moduleset`

- 設定ファイルに記述されたモジュール セットではなく、指定されたモジュール セットを使用します。このオプションは、モジュール セットが JHBuild のモジュール セット フォルダーにある場合は相対パスで指定することができます。それ以外の場所にある場合は、絶対パスで指定します。

`--no-interact`

- ユーザーに入力を求めません。このオプションは、ビルドが中断されないことが保証されるので、無人でビルドを行うような場合に便利です。

コマンドごとのオプションについては、以下で説明します。

### autobuild

`autobuild` コマンドは、設定ファイルで指定されたモジュールを自動的にビルドして、結果を JhAutobuild にアップロードします。

    jhbuild autobuild
            --autogen
            --clean
            --distcheck
            --skip=module
            --start-at=module
            --report-url=reporturl
            --verbose

`--autogen`、`--clean`、`--distcheck`、`--skip`、および `--start-at` のオプションは、`build` コマンドに引き渡されます。

`--report-url=`reporturl``, `-r `reporturl``

- このオプションは、報告先である JhAutobuild の URL を指定します。

`--verbose`, `-v`

- 指定された場合、JHBuild は、より詳細な出力を生成します。

### bootstrap

`bootstrap` command コマンドは、ほとんどのモジュールのビルドに必要となる、一連のビルド ユーティリティをインストールします(例 autoconf、automake、等)。

    jhbuild bootstrap

`bootstrap` コマンドがモジュールをビルドする方法は、`build` コマンドと同様ですが、`bootstrap.modules` モジュール セットを使用します。

利用可能なオプションについては、`build` コマンドを参照してください。

### build

`build` コマンドは1つ(または複数)のパッケージを、それらの依存関係も含めてビルドします。

    jhbuild build
            --autogen
            --clean
            --check
            --dist
            --distcheck
            --ignore-suggests
            --no-network
            --skip=module
            --start-at=module
            --tags=tags
            -D date
            --no-xvfb
            --try-checkout
            --no-poison
            --force
            --build-optional-modules
            --min-age=time
            module

コマンドラインでモジュールの名前が指定されなかった場合、設定ファイルの modules のリストが使用されます。

`-c`, `--clean`

- モジュールをビルドする前に、`make clean` を実行します。

`--check`

- モジュールをビルドした後に、`make check` を実行します。

`-d`, `--dist`

- モジュールをビルドした後に、`make dist` を実行します。

`--distcheck`

- モジュールをビルドした後に、`make distcheck` を実行します。

`--ignore-suggests`

- 推奨の依存関係をビルドしません。

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

- モジュールをビルドするときに、ネットワークにアクセスしません。これによりビルドのステージで、ダウンロードと更新がスキップされます。ネットワークにアクセスしないとモジュールをビルドできない場合、モジュールのビルドは失敗します。

`-s`, `--skip`=`module,...`

- 指定されたモジュールをビルドしません。依存関係のビルドをスキップするのに使用されます。

`--tags`=`tag,...`

- `tag` タグにマッチしないモジュールを無視します。tag とモジュールのモジュール セットの名前が、自動的にマッチングされます。

`-t`, `--start-at`=`module`

- リストの先頭からではなく、名前で指定されたモジュールから開始します。このオプションはビルドを中断したときなどに便利です。

`-D` `date`

- バージョン管理システムでサポートされていれば、ビルドの前にソース ツリーを指定された日時に更新します。ISO の日時フォーマットが要求されます。例 `"2009-09-18 02:32Z"`。

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

- Xvfb によりシミュレートされたものではなく、実際の X サーバーでグラフィカルなテストを実行します。

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

- もしビルドが失敗したとき、バージョン管理システムがサポートしている場合はビルドを再試行する前に、強制的にチェックアウトして `autogen.sh` を実行します。

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

- 1つ(または複数)のモジュールの依存関係のビルドに失敗した場合、とにかくモジュールをビルドするよう JHBuild に強制します。

`-f`, `--force`

- ビルドを要求しないポリシーでも、指定されたモジュールをビルドします。

`--build-optional-modules`

- モジュールをビルドするのに必須ではないモジュールは、オプショナルな依存関係としてリストされます。このオプションは JHBuild にたいして、オプショナルな依存関係のビルドを強制します。

`--min-age`=`time`

- 指定された相対時間より最近にインストールされたモジュールをスキップします。`time` の文字列書式は、単位を付加した数字です。付加する単位は、次のものがサポートされています: 秒 (s)、分 (m)、時間 (h)、日 (d)。例えば、`--min-age=2h` は2時間前以降にビルドされたモジュールをスキップします。

### make

The `make` command is for actively developing on a particular module. It requires the current directory be a source checkout, and does the equivalent of `buildone -nf $(basename $(pwd))`.

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

The options are the same as those available for the `buildone` command.

### buildone

`buildone` コマンドは、`build` と似ていますが、依存するモジュールをビルドしません。このコマンドは、1つ(または複数)のモジュールをリビルドするときに便利です。

    jhbuild buildone
            --clean
            --check
            --distcheck
            --no-network
            -D date
            --no-xvfb
            --force
            --min-age=time
            module

The `--check`, `--clean`, `-d`, `--distcheck`, `--no-network`, `-D` and `-x` options are processed as per the `build` command.

コマンドラインで、少なくとも1つのモジュールを指定しなければなりません。

### checkbranches

`checkbranches` は、バージョン管理システムでブランチが正しく定義されているか、およびブランチのモジュール セットに矛盾がないかをチェックします。

    jhbuild checkbranches
            --branch=branch

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

- チェックするブランチを指定します。

    $ jhbuild -m gnome-2.20 checkbranches
    libgnomecanvas is missing branch definition for gnome-2-20
    $

### clean

`clean` コマンドは1つ(または複数)のビルド ディレクトリをクリーンします。

    jhbuild clean
            --skip=module
            --start-at=module

コマンドラインでモジュールの名前が指定されなかった場合、設定ファイルの modules のリストが使用されます。

利用可能なオプションについては `build` コマンドのドキュメントの説明を参照してください。

### dot

`dot` コマンドは、モジュール間の依存関係によって形成された、有向グラフが記述されたファイルを生成します。このファイルは、ダイアグラムを生成する GraphViz ソフトウェアで処理することができます。

    jhbuild dot
            --soft-deps
            --clusters
            module

コマンドラインでモジュールの名前が指定されなかった場合、設定ファイルの modules のリストが使用されます。

`--soft-deps` オプションはモジュールから、推奨される依存関係への点線を追加します。`--clusters` オプションは metamodules によりモジュールをグループ化します。

dot コマンドの出力は、dot ユーティリティにパイプすることにより、PostScript ファイルを生成することができます:

    $ jhbuild dot modules | dot -Tps > dependencies.ps

PNG イメージを生成することもできます:

    $ jhbuild dot modules | dot -Tpng > dependencies.png

#### JHBuild dot コマンドの出力例

### gui

`gui` コマンドは、JHBuild のためにモジュールを選択したり、いくつかのビルド オプションを変更できる、グラフィカルなインターフェースを起動します。

    jhbuild gui

グラフィカルなインターフェースの描画には GTK を使用しているので、追加のサポート ライブラリが必要です。

### info

`info` コマンドは、1つ(または複数)のモジュールの情報を表示します。

    jhbuild info
            module

このコマンドはモジュールの名前、タイプ、依存関係、依存するパッケージ、JHBuild で最後にインストールされた日時を表示します。もし可能なら、そのモジュールの CVS リポジトリやダウンロード元の URL などの、具体的な情報も表示されます。

コマンドにモジュールが指定されなかった場合、モジュール セットで定義されたすべてのモジュールについての情報が表示されます。

### list

`list` コマンドは、`build` コマンドがビルドするモジュールのリストを、展開して表示します。

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

コマンドラインでモジュールの名前が指定されなかった場合、設定ファイルの modules のリストが使用されます。

`--skip`、`--start-at`、`--tags`、および `--ignore-suggests` のオプションは、`build` コマンドに引き渡されます。

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

- ビルドの依存関係に関わらず、モジュール セットのモジュールをすべて一覧します。

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

- モジュールがブランチとして設定されている場合、モジュール名とともにブランチ名が表示されます。

`--list-optional-modules`

- このオプションは JHBuild にたいして、オプショナルな依存関係の一覧を強制します。

### rdepends

`rdepends` コマンドは、モジュールの依存関係を逆方向に表示します。

    jhbuild rdepends
            module

`--dependencies`

- モジュールの横に、依存関係のパスを表示します。

`--direct`

- 指定されたモジュールと直接の依存関係にあるモジュールに、表示を限定します。

### run

`run` コマンドは、JHBuild がモジュールをビルドするのに使用するのと同じ環境で、指定したコマンドを実行します。

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

GNOME をビルドするのに JHBuild を使用する場合、このコマンドは X の起動スクリプトなどで便利です。

`--in-builddir`=`module`

- 指定したモジュールの、ビルド ディレクトリでコマンドを実行します。

`--in-checkoutdir`=`module`

- 指定したモジュールの、ソース ディレクトリでコマンドを実行します。

### sanitycheck

`sanitycheck` コマンドは、ビルド環境に問題がないことを確認するために、いくつかのチェックを行います。

    jhbuild sanitycheck

以下のチェックが含まれます:

- チェックアウト先とインストール先が書き込み可能か。

- 必要なビルド ツールがインストールされているか。

- さまざまなバージョンの `automake` に関連付けられている `aclocal` コマンドの検索パスで、よく使用されるマクロが利用可能か。

- XML カタログに DocBook の DTD と スタイル シートが含まれているか。

### shell

`shell` コマンドは、JHBuild がモジュールをビルドするのと同じ環境で、ユーザー シェルを起動します。

    jhbuild shell

このコマンドは以下のコマンドと同じです:

    $ jhbuild run $SHELL

このシェルが実行されている場合、環境変数 `UNDER_JHBUILD` が "true" に設定されます。これを利用すれば、JHBuild の制御下にあるシェルであることが確信できるように、あなたのシェルのプロンプトをカスタマイズできます。例えば、あなたの `.bashrc` に、以下のような設定をしたいと思うでしょう:

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

これにより、あなたの bash シェルは、通常のプロンプトの前に `[jhbuild]` を表示するようになるので、どのシェルが JHBuild の制御下にあるかを識別しやすくなります。

### sysdeps

The `sysdeps` command displays a list of dependency modules that are provided by installed system packages. JHBuild will not build the modules from source if the configuration variable `partial_build` is `True`.

The `sysdeps` command also displays a list of dependency modules where the installed system packages are too old. JHBuild will build newer modules from source.

The `sysdeps` command also displays a list of dependency modules with no matching system package installed.

    jhbuild sysdeps
            --install

`--install`

- This option installs system packages which are dependencies of the moduleset. The system packages are installed using PackageKit.

#### `sysdeps` example

    $ jhbuild sysdeps
    System installed packages which are new enough:
      speex (required=1.2rc1, installed=1.2rc1)
      libdiscid (required=0.2.2, installed=0.2.2)
      telepathy-farsight (required=0.0.14, installed=0.0.16)
      lcms2 (required=2.2, installed=2.2)
    ...
    System installed packages which are too old:
      webkitgtk-3.0 (required=1.5.1, installed=1.4.0)
      ...
    No matching system package installed:
      libvala-0.14 (required=0.13.1)
      ...

### tinderbox

`tinderbox` コマンドは、`build` コマンドに似ていますが、すべての端末出力を、ウェブサイトで発行しやすいような HTML ファイルに出力します。このコマンドは Mozilla の Tinderbox や、Debian の Buildd と同じようにシステムをセットアップします。

    jhbuild tinderbox
            --clean
            --no-network
            --output=directory
            --skip=module
            --start-at=module
            -D date
            -C
            -N
            -f
            module

The `--clean`, `--no-network`, `--skip`, `--start-at`, `-D`, `-C`, `-N` and `-f` options are processed as per the `build` command.

`-o`, `--output`=`directory`

- HTML ファイルを出力するディレクトリです。

### uninstall

`uninstall` コマンドは、1つ(または複数)のモジュールをアン インストールします。

    jhbuild uninstall
            module

### update

`update` コマンドは `build` コマンドに似ていますが、モジュールのビルドは行わずに、ダウンロードと更新のステージのみ実行します。

    jhbuild update
            --skip=module
            --start-at=module
            --tags=tags
            --ignore-suggests
            -D date
            module

`--skip`、`--start-at`、`--tags`、`--ignore-suggests`、および `-D` options オプションは、 `build` コマンドで処理されます。

### updateone

`updateone` コマンドは `update` と似ていますが、依存するモジュールをビルドしません。このコマンドは、1つ(または複数)のモジュールをビルドするときに便利です。

    jhbuild updateone
            -D date
            module

`-D` オプションは、`build` コマンドで処理されます。

コマンドラインで、少なくとも1つのモジュールを指定しなければなりません。

## 設定ファイル リファレンス

`~/.jhbuildrc` ファイルでは、標準的な Python 構文を使用します。このファイルは実行されて、ネーム スペースで定義された変数の結果は、 JHBuild がどのように動作するかを制御するために使用されます。一連のデフォルト値は、ユーザーの設定ファイルの実行前にネーム スペースに挿入されます。

変数にブール値をセットする場合、以下の例で示す構文が使用されます:

    use_local_modulesets = True

変数に文字列をセットする場合、以下の例で示す構文が使用されます:

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

リストへ設定値をセットする場合、以下の例で示す構文が使用されます:

    skip = ['mozilla'、'pulseaudio']

ディクショナリへ設定値をセットする場合、以下の例で示す構文が使用されます:

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

### 設定変数

`autogenargs`

- すべてのモジュールの `autogen.sh` スクリプトに渡す引数を指定する文字列です。特定のモジュールに別の引数を指定したい場合は、`module_autogenargs` ディクショナリでオーバーライドできます。

`branches`

- A dictionary specifying which branch to use for specific modules. This is useful if you are making some changes on a branch of a module and want JHBuild to build that branch instead of the one listed in the module set.

  ブランチの定義の仕方は、バージョン管理システムに依存します:

  - CVS: リビジョンを指定します。例: `'BRANCH-PROJECT-0_8'`

  - Bazaar: モジュール ブランチの URI を指定します。例: `'http://bzr.example.net/project/gnome-2-28'`

  - Git: タプル で指定します。最初の部分はオプションのリポジトリ(または None 値)、2番目にはブランチの名前です。例: `('git://git.example.net/project'、'gnome-2-28')`

    #### Simple example

        branches['modulename'] = (None, 'branchname')

  - Subversion: モジュール ブランチの URI を指定します。例: `'svn://svn.example.net/project/gnome-2-28'`

`builddir_pattern`

- ビルド ディレクトリの名前を生成するための、`printf` スタイルの書式設定パターンです。これはソースとビルド ツリーが違う場合のみ使用します。書式の中の `%s` は、`checkoutdir` で置き換えられます。デフォルトは `'%s'` です。

`buildroot`

- ビルド ツリーの親ディレクトリを指定する文字列です。デフォルトは `None` で、ビルドはソース ツリーで実行されます。

`buildscript`

- どのビルド スクリプトを使用するかを指定する文字列です。推奨の設定はデフォルトの `terminal` です。特に `gtk` に設定しないでください。

`build_policy`

- どのモジュールをビルドするかを指定する文字列です。利用可能なオプションは、要求されたモジュールをすべてビルドする `all`、変更されたモジュールだけをビルドする `updated`、モジュール または 依存するモジュールが変更されたときにモジュールをビルドする `updated-deps` の3つです。デフォルトは `updated-deps` です。

`checkoutroot`

- ソース ツリーを展開するディレクトリを指定する文字列です。`buildroot` がセットされていない場合は、ビルドにもこのディレクトリが使用されます。デフォルトは `~/checkout/gnome` です。

`checkout_mode`

- バージョン管理されているディレクトリにたいして、どのようにチェックアウトを行うかを指定する文字列です。デフォルトは `update` です。モジュールごとに指定する場合は、`module_checkout_mode` を使用できます。利用可能な値は `update` (チェックアウト ディレクトリを更新する)、`clobber` (ソースをチェックアウトする前にディレクトリを掃除する)、`export` (ディレクトリを掃除した後にソースのバージョン管理外コピーを作成する)、そして `copy` (ディレクトリにビルドされるものとは別にチェックアウトします)です。

`copy_dir`

- A string specifying the directory to copy to, if the copy `checkout_mode` is in use. Defaults to the checkout directory.

`cvs_program`

- cvs をサポートするために、どのプログラムを使用するかを指定する文字列です。`git-cvsimport`、または `cvs` が指定できます。デフォルトは `cvs` です。

`dvcs_mirror_dir`

- ローカルミラーのディレクトリを指定する文字列です。JHBuild は指定されたディレクトリにリポジトリのローカルミラーを作成します。ミラーは複数のリポジトリグループによって共有することができ、ローカルのクローンにたいしてハードリンクが使用されるため領域と時間の節約につながります。`update` および `updateone` コマンドはミラーを作成し、オンラインのリポジトリから新規のコミットをフェッチします。このオプションは Git および Bazaar リポジトリにたいしてのみサポートされます。

`installprog`

- `/usr/bin/install` のかわりに使用するプログラムを指定する文字列です。利用可能な場合、デフォルトは JHBuild により提供される`install-check` ラッパーです。`install-check` ラッパーはヘッダーのインストールを最適化することにより、リビルドにかかる時間を短縮します。

`ignore_suggests`

- 依存ツリーを計算するときに、推奨される依存関係を無視するかどうかを指定するブール値です。デフォルトは `False` です。

`interact`

- ユーザーと対話するかどうかを指定するブール値です。この値を `False` に設定することは、`--no-interact` オプションを指定するのと同じです。デフォルトは `True` です。

`makeargs`

- `make` に渡す追加の引数の文字列リストです。デフォルトは `''` です。

`makecheck`

- `make` の後に、`make check` を実行するかどうかを指定するブール値です。デフォルトは `False` です。

`makecheck_advisory`

- `make check` が失敗したときに、ビルドを失敗させない(メッセージの表示のみ)にするかどうかを指定する文字列です。デフォルトは `False` です。

`makeclean`

- `make` の前に、`make clean` を実行するかどうかを指定するブール値です。デフォルトは `False` です。

`makedist`

- `make` の後に、`make dist` を実行するかどうかを指定するブール値です。デフォルトは `False` です。これは `--dist` オプションを指定するのと同じです。

`makedistcheck`

- `make` の後に、`make distcheck` を実行するかどうかを指定するブール値です。デフォルトは `False` です。これは `--distcheck` オプションを指定するのと同じです。

`module_autogenargs`

- モジュールの名前と、`autogen.sh` に渡す引数をマッピングするディクショナリです。`module_autogenargs` の設定は、`autogenargs` のグローバルな設定より優先されます。モジュールがディクショナリに指定されていないときは、グローバルな `autogenargs` が使用されます。

`module_checkout_mode`

- チェックアウト モードをモジュールごとに指定するためのディクショナリです。この設定はグローバルな `checkout_mode` の設定より優先されます。

`module_makeargs`

- モジュールの名前と、`make` に渡す引数をマッピングするディクショナリです。`module_makeargs` の設定は、`makeargs` の値を置き換えます。モジュールがディクショナリに指定されていないときは、グローバルな `makeargs` が使用されます。

`module_makecheck`

- モジュールの名前と、`make` の後に `make check` を実行するかどうかの指定をマッピングするディクショナリです。`module_makecheck` の設定は、`makecheck` の値より優先されます。モジュールがディクショナリに指定されていないときは、グローバルな `makecheck` の設定が使用されます。

`module_nopoison`

- モジュールの名前とブール値をマッピングするディクショナリです。モジュールに `True` が設定されている場合、JHBuild は指定されたモジュールのビルドが失敗しても、依存するモジュールをビルドしようと試みます。`module_nopoison` の設定は、`nopoison` の設定より優先されます。モジュールがディクショナリに指定されていないときは、グローバルな `nopoison` の設定が使用されます。

`module_extra_env`

- モジュールの名前と、追加の環境変数と値のディクショナリをマッピングするディクショナリです。モジュールのためにコマンドを実行するときに使用されます。

`modules`

- A list of strings specifying the modules to build. The list of modules actually built will be recursively expanded to include all the dependencies unless the `buildone` command is used. Defaults to `['meta-gnome-desktop']`.

`moduleset`

- モジュール セットの名前を指定する文字列、または文字列のリスト(配列)です。これは JHBuild に含まれるファイル名(パスと拡張子を除く)、または 外部で管理されているモジュール セットの完全な HTTP URL のどちらでも構いません。HTTP URL のモジュール セットは、ローカルにキャッシュされます。2つ以上のモジュールセットに対して同じ名前が与えられていた場合は、最後のセットが優先されます。JHBuild により提供されるモジュール セットは、その時の GNOME の開発リリースに合わせて更新されます。

`modulesets_dir`

- モジュール セットのあるディレクトリを指定する文字列です。デフォルトは JHBuild のソースの `modulesets/` ディレクトリです。

`nice_build`

- Run builds under the `SCHED_IDLE` priority on Linux, `nice` on other Unix. This can dramatically improve desktop interactivity for parallel builds while having only a negligible impact on build throughput.

`nobuild`

- ブール値です。`True` に設定した場合、JHBuild はモジュールのビルドを行わず、ソースのダウンロードと展開のみ行います。デフォルトは `False` です。

`nonetwork`

- ネットワークにアクセスするかどうかを指定するブール値です。この設定は CVS モジュールのチェックアウトと更新、および tarball のダウンロードと、モジュール セットの更新に影響を与えます。`True` に設定した場合、`--no-network` オプションを指定したのと同じです。デフォルトは `False` です。

`nonotify`

- A boolean value specifying whether to emit notifications using the notification daemon. If set to `False`, notifications are emitted. Defaults to `True`.

`nopoison`

- ブール値です。`True` に設定された場合、依存関係にある1つ以上のモジュールのビルドに失敗しても、JHBuild はビルドを試みます。このオプションは `--no-poison` を引数で指定するのと同じです。デフォルトは `False` です。

`notrayicon`

- A boolean value specifying whether to show an icon in the system tray using Zenity. If set to `False`, notifications are emitted. Defaults to `True`.

`noxvfb`

- ブール値です。`True` に設定した場合、JHBuild は `Xvfb` を使用せずに、実際の X サーバーでグラフィック テストを実行します。このオプションは、`--no-xvfb` を指定するのと同じです。デフォルトは `False` です。

`partial_build`

- A boolean value, if set to `True` JHBuild will not build dependency modules if corresponding system packages are installed and sufficient version. Defaults to `True`.

`prefix`

- A string specifying the prefix to install modules to. `prefix` must be an absolute path. This directory must be writable. Defaults to `'/opt/gnome'`.

`pretty_print`

- サブ プロセスの出力を、綺麗にプリントするかどうかを指定するブール値です。CVS の出力のみをサポートします。この指定により問題が発生する場合は無効にしてください。デフォルトは `True` です。

`print_command_pattern`

- A string displayed before JHBuild executes a command. `%(command)s` in the string will be replaced with the command about to be executed. `%(cwd)s` in the string will be replaced with the current working directory. Defaults to `'%(command)s'`.

`progress_bar`

- quiet mode で、プログレスバーを表示するかどうかを指定するブール値です。デフォルトは `True` です。

`quiet_mode`

- ブール値です。`True` に設定した場合、コマンドの出力を抑止します。デフォルトは `False` です。

`repos`

- 特定のリポジトリにたいして、かわりのリポジトリ ロケーションを指定するディクショナリです。この設定変数は、モジュール開発者にとって便利です。デフォルトでは、JHBuild は匿名のリポジトリ ロケーションから、コードをチェックアウトします。ディクショナリのキーはリポジトリの略称で、値はリポジトリ ロケーションの文字列です。例:

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

`skip`

- スキップするモジュールを、リストで指定します。これは `--skip` のコマンドライン オプションをリスト型に拡張したものです。デフォルトではこのリストは空です。

`sticky_date`

- 文字列型です。もし指定された場合、背後のバージョン管理システムがサポートしていれば、JHBuild はビルドの前に、ソース ツリーを指定された日付に更新します。ここで指定できるのは ISO の日付書式です。例: `'`yyyy`-`mm`-`dd`'`。デフォルトは `None` です。

`svn_program`

- subversion をサポートするために、どのプログラムを使用するかを指定する文字列です。`svn`、または `git-svn` が指定できます。デフォルトは `svn` です。

`tarballdir`

- 文字列型です。指定された場合、tarball を `checkoutroot` ではなく、指定されたディレクトリにダウンロードします。これは JHBuild で複数の環境を使用していたり、`checkoutroot` を定期的にクリーンしていて、なおかつ帯域幅の使用を減らしたい場合などに便利です。

`tinderbox_outputdir`

- `jhbuild tinderbox` の出力を保存するディレクトリを指定する文字列です。この設定は `--output` オプションより優先されます。デフォルトは `None` なので、コマンドライン オプションで指定するか、設定ファイルの中でこれが指定されていなければなりません。

`trycheckout`

- ブール値です。`True` を指定した場合、JHBuild は失敗したときに次の解決を自動的に試みます。 1) `autogen.sh` コマンドを再実行する 2) バージョン管理システムから新しいバージョンをチェック アウトする。この設定は `--try-checkout` オプションを指定するのと同じです。

`use_lib64`

- `lib64` ディレクトリにライブラリをインストールするかどうかを指定するブール値です。設定した場合、configure のオプションに `--libdir=\${exec_prefix}/lib64` を引き渡します。`x86_64`、`ppc64`、`s390x` で Linux を実行している場合のデフォルトは `True` です。これ以外のシステムの場合、デフォルトは `False` です。

`use_local_modulesets`

- GNOME のバージョン管理システムから、オン ザ フライでモジュール セットを取得するのではなく、JHBuild のソースコードと一緒にチェックアウトしたモジュール セットを使用するかどうかを指定するブール値です。デフォルトは `False` です。

`xvfbargs`

- グラフィック テストを `Xvfb` で実行する場合の引数を指定するリスト型です。

### その他の設定ファイルの構造

上述の変数に加えて、以下の文字列が設定ファイルで指定できます:

`os.environ`

- 環境をあらわすディクショナリです。この環境は JHBuild により 生成されたプロセスに引き渡されます。

  `CPPFLAGS`、`CFLAGS`、`INSTALL`、そして `LDFLAGS` を含む、影響のある環境変数が含まれます。例:

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

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

- `PATH` 環境変数にディレクトリを追加します。`addpath` は、環境変数の初期値が空の場合を確実に処理します(環境変数の先頭、もしくは末尾にある単独のコロンは予期せぬ結果をもたらすことがあります)。

  `addpath` は、パスが `-I `pathname`` の形式であることを期待する `ACLOCAL_FLAGS` 環境変数のために特別な処理を行います。

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

- 設定ファイルを処理した後、JHBuild は `prefix` のような変数に基づくパスに対して変更を加えます(例: `PATH` の先頭に `$prefix/bin` を追加する)。

  `prependpath` は `addpath` と同じように動作しますが、JHBuild が環境に対して行った変更の後に環境変数への変更が適用される点が異なります。

## モジュール セット ファイルの構文

JHBuild は モジュール間の依存関係を XML ファイルに記述します。RELAX-NG スキーマとドキュメント タイプの定義は、JHBuild の `modulesets/` ディレクトリにあります。RELAX-NG スキーマにより、Emacs の `nxml-mode` でモジュール セットファイルを編集できます。

モジュール セット ファイルのトップレベル要素は、`moduleset` という要素です。XML のネームスペースは使用されておらず、トップレベル要素の下には、モジュール ソース、インクルード文、モジュール定義 の3つのタイプがあります。

### モジュール ソース

それぞれのモジュールの場所をすべてリストするよりは、いくつかの "モジュール ソース" をモジュール セットに記述し、モジュール定義でその名前を参照するほうが簡単です。同様に、モジュール セットの冗長な情報を減らすことにより、それらのモジュールの代替ソースを指定するのが簡単になります(開発者やユーザーにとって CVS や Subversion などは、異なるリポジトリにアクセスする方法として一般的です)。

`repository` 要素は、すべてのタイプのリポジトリを説明するのに使用します。`branch` 要素は、モジュール定義の内部で、追加の設定を指定するのに使用します。

    <repository name="name"
      type="type"
      [ default="default" ]
      [ password="password" ]
      [ cvsroot="cvsroot" ]
      [ archive="archive" ]
      [ href="href" ]
      [ server="server" ]
      [ database="database" ]
      [ defbranch="defbranch" ]
      [ trunk-template="trunk-template" ]
      [ branches-template="branches-template" ]
      [ tags-template="tags-template" ]
      [ developer-href-example="developer-href-example" ] />

`name` 属性により、リポジトリを一意に識別します。

`default` 属性により、そのモジュールに対するデフォルトのソースがどこにあるかを指定します。

The `type` attribute specifies the type of repository. It can be one of: `bzr`, `cvs`, `darcs`, `fossil`, `git`, `hg`, `mnt`, `svn`, `tarball`. Other attributes depend on the `type`, as well as the `branch` used inside module definitions. Those are described below in the repository type sub-sections.

`developer-href-example` 属性は、開発者が使うリポジトリの URL の書式を指定します。この属性は情報の提供のためだけに使用されます。

`branch` 要素は、モジュール定義の内部で使用します。

    <branch
      [ repo="repository" ]
      [ module="module name" ]
      [ checkoutdir="checkoutdir" ]
      [ revision="revision" ]
      [ tag="tag" ]
      [ update-new-dirs="update-new-dirs" ]
      [ override-checkoutdir="override-checkoutdir" ]
      [ subdir="subdir" ]
      [ branch="branch" ]
      [ version="version" ]
      [ size="size" ]
      [ source-subdir="source-subdir" ]
      [ hash="hash" ]/>

すべての属性には実用的なデフォルト値があり、それらはモジュールとリポジトリの定義に依存します。以下は、一般的な属性についての説明です。

`repo` 属性は、リポジトリのサーバーを指定します。

`module` 属性は、リポジトリからチェックアウトするモジュールの名前を指定します。デフォルトはモジュール ID です。

`checkoutdir` 属性は、チェックアウト ディレクトリの名前を指定します。デフォルトはモジュール ID です。

その他の属性については、以下で説明します

#### Bazaar

このリポジトリ タイプは、Bazaar リポジトリを定義します。Bazaar 1.16 以降を推奨します。

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

追加の属性は: `trunk-template` (defaults to `"%(module)s"`) と `branches-template` (defaults to `"%(module)s/%(branch)s`") です。これらの属性は、URL を構築するために使用します。モジュール定義内の `branch` 要素では、`branch` と `user` 属性を指定できます。もしこれらが `branches-template` や `trunk-template` で使用されている場合は、設定した値でテンプレートを置き換えることができます。この方法で、リポジトリをオーバーライドしてあなたの個人的なブランチからモジュールをビルドしたり、非標準的なレイアウトのリポジトリから多くのモジュールをビルドすることができます。

さらに `branch` 要素は、特定のリビジョンにたいするアンカーとして `revspec` 属性を指定できます。有効な `bzr revspec` を指定することができます。例えば、`date:yesterday,-5,tag:0.1` は、昨日以降で、tag が "0.1"、5回前に コミットされたリビジョンを取得します。指定可能な値については `bzr help revisionspec` を参照してください。

`template` 属性が定義された、リポジトリの例です:

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

上記のリポジトリにたいする、`branch` 要素の例です:

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

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

#### CVS

このリポジトリ タイプは、CVS リポジトリを定義します。

`password` 属性は、リポジトリのパスワードを指定します。

`cvsroot` 属性は、リポジトリの root を指定します。

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

追加の属性は: `revision`、`update-new-dirs`、および `override-checkoutdir` です。

#### Darcs

このリポジトリ タイプは、Darcs リポジトリを定義します。

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

#### Git

このリポジトリ タイプは、Git リポジトリを定義します。

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

`branch` 要素には、以下の属性を指定できます:

`revision` 属性には、更新のフェーズにおいてローカル、またはリモートで追跡するブランチの切り替えを指定します。デフォルトは 'master' です。`branches` の設定値で、この属性をオーバーライドすることができます。現在のブランチがリモートのブランチを追跡している場合は、あなたの作業を破壊しないように切り替えのみが処理されます。

`tag` 属性は、更新フェーズでリビジョンを無条件にチェックアウトするために使用します。この属性は、`revision` 属性より優先されます。

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

#### Mercurial

このリポジトリ タイプは、Mercurial リポジトリを定義します。

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

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

#### Monotone

このリポジトリ タイプは、Monotone リポジトリを定義します。

`server` 属性は、リポジトリのサーバーを指定します。

`database` 属性は、リポジトリで使用するデータベースを指定します。

`defbranch` 属性は、使用するリポジトリのブランチを指定します。

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

#### Subversion

このリポジトリ タイプは、Subversion リポジトリを定義します。

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

`branch` に `revision` を指定できます。この属性で、チェックアウトするブランチの定義、または、チェックアウトするブランチのリビジョン番号を指定します。

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

`trunk-template` (デフォルトは "%(module)s/trunk")、`branches-template` (デフォルトは "%(module)s/branches/%(branch)s")、`tags-template` (デフォルトは "%(module)s/tags/%(tag)s") を使用して、カスタマイズされた `svn` レイアウトを指定できます。

#### Tarballs

このリポジトリ タイプは、tarball のリポジトリを定義します。

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

`branch` 要素には、以下の属性を指定できます:

`module` 属性により、ダウンロード、およびコンパイルするファイルを指定し、`version` 属性でモジュールのバージョンを指定します。

`size`、`hash`、同様に 旧来の `md5sum` 属性はオプションです。これらが指定された場合、パッケージが正しくダウンロードされたかチェックするのに使用されます。

`branch` 要素は、任意の数の `patch` 要素を持つことができます。ここで指定したパッチは、展開したソース ツリーにたいして記述した順に適用されます。`file` 属性でパッチのファイル名を指定し、`strip` 属性でパッチを適用する際に無視するディレクトリのレベル数を指定します(訳注:patch コマンドの -p オプションに相当)。

JHBuild に同梱されているモジュール セットでは、`jhbuild/patches/` ディレクトリからパッチ ファイルを探します。URI で参照されるモジュール セットの場合、モジュール セットと同じディレクトリ、もしくは`patches/` というサブ ディレクトリからパッチ ファイルを探します。`file` 属性に URI を指定することもでき、その場合は指定された場所からファイルをダウンロードします。

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

また、tarball の `branch` 要素は、内部に `quilt` 要素を含めることで、インポートしたい入れ子の `branch` を指定することもできます。

### 他のモジュール セットのインクルード

JHBuild では `include` 要素により、モジュール セットから他のモジュール セットをインクルードすることができます。

    <include href="uri"/>

`href` は、インクルードするモジュール セットを参照するための URI で、`include` 要素を含むファイルからの相対的な URI です。

参照されるモジュール セットからインポートされるのはモジュール定義だけで、モジュール ソースはインポートされません。複数階層のインクルードもできますが、インクルードのループはできません(今のところループの処理は実装されていません)。

### モジュールの定義

モジュール セット ファイルで使用できるモジュール定義には、さまざまな種類があり、そのリストは簡単に拡張できます。以下に記載するのは、最も一般的なものです。

基本的にモジュール定義は、モジュールをどうやって取得するかを記述する `branch` 要素と、モジュールの依存関係を定義する `dependencies`、`suggests`、`after` 要素で構成されます。

`dependencies` 要素にリストされたモジュールは、それがインクルードされていない場合 `jhbuild build` のモジュール リストに追加され、依存するモジュールが最初にビルドされることを保証します。

モジュール リストを生成した後で、`suggests` 要素にリストされたモジュールが、モジュール リストの他に使用されます(追加のモジュールを取得しないとしても)。これはモジュールが他のモジュールに対してオプションの依存関係をもつ場合を想定したものです。

#### autotools

`autotools` 要素は、GNU Autotools ビルド システムでモジュールをコンパイルすることを定義します。

    <autotools id="id"
    	      [ autogenargs="autogenargs" ]
    	      [ makeargs="makeargs" ]
    	      [ makeinstallargs="makeinstallargs" ]
    	      [ autogen-sh="autogen-sh" ]
    	      [ makefile="makefile" ]
    	      [ skip-autogen="skip-autogen" ]
    	      [ autogen-template="autogen-template" ]
    	      [ check-target="check-target" ]
    	      [ supports-non-srcdir-builds="supports-non-srcdir-builds" ]>

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

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

    </autotools>

`autogenargs`、`makeargs`、`makeinstallargs` 属性では、それぞれ `autogen.sh`、`make` および `make install` に引き渡す追加の引数を指定します。

`autogen-sh` 属性は、実行する autogen.sh スクリプトの名前を指定します。`autoreconf` の値は、モジュールに `autogen.sh` に相当するスクリプトがない場合に使用されます。この場合、JHBuild は適切な `configure` の後で `autoreconf -i` を実行します。`skip-autogen` では autogen.sh を実行するかどうかを指定します。指定できるのはブール値、および `never` で、never を指定した場合 JHBuild は決して `autogen.sh` の実行をスキップしません。`makefile` は、使用する makefile のファイル名を指定します。

`supports-non-srcdir-builds` 属性は、分離されたソース ディレクトリでクリーンなビルドができないモジュールであることをマークします。

`autogen-template` 属性は、autogen のコマンド ラインを "優雅" に制御したい場合に使用できます。これには Python の文字列書式を使用でき、以下の変数が置換されます: `srcdir`、`autogen-sh`、`prefix`、`libdir`、`autogenargs`。例えば、これはデフォルトの autogen-template です:

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

`check-target` 属性は、`make check` ターゲットがないモジュールの場合は指定しなければなりません(値は false)。

#### cmake

`cmake` 要素は、CMake ビルド システムでモジュールをビルドすることを定義します。

    <cmake id="modulename">
      <branch [ ... ] >
        [...]
      </branch>

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

#### distutils

`distutils` 要素は、python の distutils でモジュールをビルドすることを定義します。

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

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

#### linux

`linux` 要素は、linux カーネルのビルドで使用されるモジュールを定義します。加えて、`kconfig` サブ要素により、別のカーネル設定を選択することができます。

    <linux id="id"
    	  [ makeargs="makeargs" ]>

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

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

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

    </linux>

#### perl

`perl` 要素は、perl モジュールをビルドするために使用します。

`makeargs` 属性は、`make` に引き渡す追加の引数を指定します。

    <perl id="modulename"
    	 [ makeargs="makeargs" ]>

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

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

    </perl>

#### waf

`waf` 要素は、Waf ビルド システムでモジュールをビルドすることを定義します。

`waf-command` 属性は、使用する waf コマンド スクリプトを指定します。デフォルトは `waf` です。

    <waf id="modulename">
    	 [ waf-command="waf-command" ]>
      <branch [ ... ] >
        [...]
      </branch>

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

#### testmodule

`testmodule` 要素は、LDTP、または Dogtail でテストを実行するモジュールを作成するために使用します。

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

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

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

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

    </testmodule>

`type` 属性には、モジュールで実行するテストのタイプを指定します。'dogtail' は、すべての .py ファイルの実行に Python を使用します。'ldtp' は 'ldtprunner run.xml' を実行します。

noxvfb オプションが設定されていない場合、テストのために Xvfb サーバーが起動されます。

#### metamodule

`metamodule` 要素は、実際には何もしないモジュールを定義します。このモジュールの唯一の目的は、依存関係のためです。

例えば、meta-gnome-desktop は GNOME デスクトップの主要コンポーネントに依存しているので、実際には完全なデスクトップをインストールするよう JHBuild に指定することになります。

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

`id` 属性には、モジュールの名前を指定します。子要素は `autotools` と同様に処理されます。

### 非推奨となった要素

#### モジュール ソース

##### cvsroot

`cvsroot` 要素は、現在は非推奨となっています - かわりに `repository` 要素を使用してください。

`cvsroot` 要素は、CVS リポジトリを記述するのに使用します。

      <cvsroot name="rootname"
               [ default="yes|no" ]
               root="anon-cvsroot"
               password="anon-password"/>

`name` 属性は、CVS リポジトリを一意に識別する名前です。

`default` 属性には、モジュール セット ファイルのデフォルトのモジュール ソースを記述します。

`root` 属性には、このリポジトリへの匿名アクセスに使用される CVS root のリストを記述し、`password` 属性で匿名アクセスするときのパスワードを記述します。

##### svnroot

`svnroot` 要素は、現在は非推奨となっています - かわりに `repository` 要素を使用してください。

`svnroot` 要素は、Subversion リポジトリを記述するのに使用します。

      <svnroot name="rootname"
               [ default="yes|no" ]
               href="anon-svnroot"/>

`name` 属性は、Subversion リポジトリを一意に識別する名前です。

`default` 属性には、モジュール セット ファイルのデフォルトのモジュール ソースを記述します。

`href` 属性には、リポジトリの URL のリストを記述します。おそらく `http`、`https`、`svn` のような URL となるでしょう。

#### 非推奨となったモジュール タイプ

このセクションでは、既存のモジュール セットでは使用されているものの、今後の使用は非推奨の要素について説明します。

##### tarball

この非推奨な要素は、`autotools` モジュール タイプと `tarball` リポジトリ タイプの単なる軽量なラッパーです。

`tarball` 要素では、tarball からビルドされるモジュールを定義します。

      <tarball id="modulename"
                  [ version="version" ]
                  [ checkourdir="checkoutdir" ]
                  [ autogenargs="autogenargs" ]
                  [ makeargs="makeargs" ]
                  [ autogen-sh="autogen-sh" ]
                  [ supports-non-srcdir-builds="yes|no" ]>
        <source href="source-url"
                [ size="source-size" ]
                [ hash="source-algo:source-hash" ]
                [ md5sum="source-md5sum" ]/>
        <patches>
          <patch file="filename" strip="level"/>
          ...
        </patches>
        <dependencies>
          <dep package="modulename"/>
          ...
        </dependencies>
        <suggests>
          <dep package="modulename"/>
          ...
        </suggests>
      </tarball>

`id`、および `version` 属性は、モジュールを識別するために使用されます。

`source` 要素では、ダウンロードしてコンパイルするファイルを指定します。`href` は必須の属性で、`size`、`hash`、同様に 旧来の `md5sum` 属性はオプションです。最後の2つの属性が指定された場合は、ダウンロードされたソースが正しいものであるか確認するために使用されます。

`patches` 要素は、ソース ツリーを展開後に1つ (または複数) のパッチの適用を指定します。`file` 属性はファイル名を指定し、`strip` 属性はパッチを適用する際に無視するディレクトリのレベル数を指定します(訳注:patch コマンドの -p オプションに相当)。

JHBuild に同梱されているモジュール セットでは、`jhbuild/patches/` ディレクトリからパッチ ファイルを探します。URI で参照されるモジュール セットの場合、モジュール セットと同じディレクトリ、もしくは`patches/` というサブ ディレクトリからパッチ ファイルを探します。`file` 属性に URI を指定することもでき、その場合は指定された場所からファイルをダウンロードします。

その他の属性、および `dependencies`、`suggests`、`after` 要素は、autotools によって処理されます。