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 ファイルを含むディレクトリとして定義されます。パッケージには、そのディレクトリ内のすべてのファイルと、その下にあるすべてのサブディレクトリ（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 のドキュメントをご覧ください。