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