Bazel は、
ワークスペースと呼ばれるディレクトリ ツリーに整理されたソースコードからソフトウェアをビルドします。ワークスペース内のソースファイルは、パッケージのネストされた階層に整理されます。各パッケージは、関連するソースファイルのセットと 1 つの BUILD ファイルを含むディレクトリです。BUILD ファイルは、ソースからビルドできるソフトウェア
出力を指定します。
ワークスペース
ワークスペースは、ビルドするソフトウェアのソース
ファイルを含むファイル システム上のディレクトリ ツリーです。各ワークスペースには
WORKSPACEという名前のテキスト ファイルがあります。このファイルは空の場合もあれば、出力のビルドに必要な外部
依存関係への参照が含まれている場合もあります。
WORKSPACE という名前のファイルを含むディレクトリは、
ワークスペースのルートと見なされます。したがって、Bazel は、
ファイルを含むサブディレクトリをルートとするワークスペース内のディレクトリ ツリーを無視します。これは、別のワークスペースを形成するためです。WORKSPACE
Bazel は、WORKSPACE ファイルのエイリアスとして WORKSPACE.bazel ファイルもサポートしています。両方のファイルが存在する場合は、WORKSPACE.bazel が使用されます。
リポジトリ
コードはリポジトリに整理されます。
ファイルを含むディレクトリは、メイン リポジトリのルート（@ とも呼ばれます）です。WORKSPACE他の（外部）
リポジトリは、ワークスペース ルールを使用して WORKSPACE ファイルで定義するか、
Bzlmod システムのモジュールと拡張機能から生成します。詳細については、外部
依存関係の概要をご覧ください。
Bazel にバンドルされているワークスペース ルールについては、ビルド 百科事典の ワークスペース ルールのセクションと、埋め込み Starlark リポジトリ ルールのドキュメントをご覧ください。
外部リポジトリはリポジトリ自体であるため、
WORKSPACE ファイルも含まれていることがよくあります。ただし、これらの追加の WORKSPACE ファイルは
Bazel によって無視されます。特に、推移的に依存するリポジトリは自動的に
追加されません。
パッケージ
リポジトリ内のコード編成の基本単位はパッケージです。パッケージは、関連ファイルのコレクションと、出力アーティファクトの生成に使用できる方法の仕様です。
パッケージは、BUILD（または
BUILD.bazel）という名前のファイルを含むディレクトリとして定義されます。パッケージには、そのディレクトリ内のすべてのファイルと、その下にあるすべての
サブディレクトリが含まれます。ただし、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属性またはdefault_visibility属性からのみです。
関数はファイルを生成または使用しません。package詳細については、package_group
ドキュメントをご覧ください。