Bazel は、リポジトリと呼ばれるディレクトリ ツリーに整理されたソースコードからソフトウェアをビルドします。ワークスペースは、定義された一連のリポジトリで構成されます。リポジトリ内のソースファイルは、パッケージのネストされた階層で編成されます。各パッケージは、関連するソースファイルのセトと 1 つの BUILD
ファイルを含むディレクトリです。BUILD
ファイルには、ソースからビルドできるソフトウェア出力を指定します。
リポジトリ
Bazel ビルドで使用されるソースファイルは、リポジトリ(多くの場合は「repos」と省略されます)にまとめられています。リポジトリは、ルートに境界マーカー ファイルがあるディレクトリ ツリーです。このような境界マーカー ファイルは、MODULE.bazel
、REPO.bazel
、またはレガシー コンテキストでは WORKSPACE
または WORKSPACE.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 を持つ場合もあります。この依存関係の影響は、A がコンパイル時に B のヘッダー ファイルを使用できること、A がリンク時に B のシンボルを使用できること、A が実行時に B のランタイム データを使用できることです。
すべてのルールの不変条件は、ルールによって生成されたファイルは常にルール自体と同じパッケージに属することです。別のパッケージにファイルを生成することはできません。ただし、ルールの入力が別のパッケージから取得されることは珍しくありません。
パッケージ グループは、特定のルールへのアクセスを制限することを目的としたパッケージのセットです。パッケージ グループは package_group
関数で定義されます。プロパティには、パッケージに含まれるパッケージのリスト、名前、パッケージに含まれる他のパッケージ グループの 3 つのプロパティがあります。これらのファイルを参照できるのは、ルールの visibility
属性または package
関数の default_visibility
属性からのみです。ファイルは生成または使用されません。詳細については、package_group
のドキュメントをご覧ください。