リポジトリ、ワークスペース、パッケージ、ターゲット

問題を報告 ソースを表示

Bazel は、リポジトリと呼ばれるディレクトリ ツリーで構成されたソースコードからソフトウェアをビルドします。定義されたリポジトリのセットがワークスペースを構成します。リポジトリ内のソースファイルは、ネストされたパッケージ階層で編成されます。各パッケージは、関連するソースファイルのセットと 1 つの BUILD ファイルを含むディレクトリです。BUILD ファイルは、ソースからビルドできるソフトウェア出力を指定します。

リポジトリ

Bazel ビルドで使用されるソースファイルは、リポジトリ(多くの場合は「repos」と短縮されます)にまとめられます。リポジトリとは、ルートに境界マーカー ファイルがあるディレクトリ ツリーです。このような境界マーカー ファイルは、MODULE.bazelREPO.bazel、レガシー コンテキストでは WORKSPACEWORKSPACE.bazel のいずれかになります。

現在の Bazel コマンドが実行されているリポジトリをメイン リポジトリといいます。その他の(外部)リポジトリは、リポルールによって定義されます。詳細については、外部依存関係の概要をご覧ください。

ワークスペース

ワークスペースは、同じメイン リポジトリから実行されるすべての Bazel コマンドで共有される環境です。メイン リポジトリと、定義済みのすべての外部リポジトリのセットが含まれています。

歴史的には「リポジトリ」と「ワークスペース」のコンセプトは混同されてきました。「ワークスペース」という用語はメイン リポジトリを指す場合が多く、「リポジトリ」の同義語として使用されることもよくあります。

パッケージ

リポジトリ内のコードを構成する主な単位はパッケージです。パッケージは、関連するファイルの集まりと、出力アーティファクトの生成方法の仕様です。

パッケージは、BUILD または BUILD.bazel という名前の BUILD ファイルを含むディレクトリとして定義されます。パッケージには、そのディレクトリ内のすべてのファイルと、その下のすべてのサブディレクトリ(BUILD ファイルを含むものを除く)が含まれます。この定義では、2 つの異なるパッケージの一部にファイルまたはディレクトリを含めることはできません。

たとえば、次のディレクトリ ツリーには、my/app とサブパッケージ my/app/tests の 2 つのパッケージがあります。my/app/data はパッケージではなく、パッケージ my/app に属するディレクトリです。

src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc

ターゲット

パッケージはターゲットのコンテナであり、パッケージの BUILD ファイルで定義されます。ほとんどのターゲットは、ファイルとルールという 2 つのプリンシパルの種類のいずれかです。

ファイルはさらに 2 種類に分類されます。ソースファイルは通常、人の手によって作成され、リポジトリにチェックインされます。生成ファイル(派生ファイルや出力ファイルとも呼ばれます)はチェックインされず、ソースファイルから生成されます。

2 つ目の種類のターゲットはルールで宣言します。各ルール インスタンスでは、入力ファイルと出力ファイルの関係を指定します。ルールへの入力はソースファイルでもかまいませんが、他のルールの出力にすることもできます。

ほとんどの場合、ルールへの入力がソースファイルか生成されたファイルかは重要ではありません。重要なのは、そのファイルの内容だけです。そのため、複雑なソースファイルを、ルールによって生成された生成ファイルに簡単に置き換えることができます。たとえば、高度に構造化されたファイルを手動で管理する負担が大きくなり、それを取得するプログラムを記述した場合などです。このファイルのコンシューマーに変更を加える必要はありません。逆に、生成されたファイルは、ローカルの変更のみを行ったソースファイルに簡単に置き換えることができます。

ルールへの入力には、その他のルールも含まれる場合があります。多くの場合、このような関係の正確な意味は非常に複雑で、言語やルールによって異なりますが、直感的にシンプルです。C++ ライブラリ ルール A に、入力用に別の C++ ライブラリ ルール B がある場合があります。この依存関係の影響として、B のヘッダー ファイルはコンパイル時に A が使用でき、B のシンボルはリンク中に A から、B のランタイム データは実行中 A が使用できます。

ルールによって生成されるファイルは常にルール自体と同じパッケージに属しているという不変条件です。別のパッケージにファイルを生成することはできません。ただし、ルールの入力が別のパッケージから取得されることも珍しくありません。

パッケージ グループは、特定のルールのアクセシビリティを制限することを目的とするパッケージのセットです。パッケージ グループは、package_group 関数で定義されます。含まれるパッケージのリスト、名前、その他のパッケージ グループという 3 つのプロパティがあります。これらを参照するために許可される方法は、ルールの visibility 属性または package 関数の default_visibility 属性からのみです。ファイルの生成や消費は行われません。詳細については、package_group のドキュメントをご覧ください。

ラベル