Bazel は、ワークスペースというディレクトリ ツリーに整理されたソースコードからソフトウェアをビルドします。ワークスペース内のソースファイルは、パッケージのネストされた階層に編成されます。各パッケージは、関連するソースファイルのセットと 1 つの BUILD ファイルを含むディレクトリです。BUILD ファイルでは、ソースからビルド可能なソフトウェア出力を指定します。
ワークスペース
ワークスペースは、ビルドするソフトウェアのソースファイルを含むファイル システム上のディレクトリ ツリーです。各ワークスペースには WORKSPACE というテキスト ファイルがあります。これらのテキスト ファイルは空にすることも、出力の作成に必要な外部依存関係への参照を含めることもできます。
WORKSPACE という名前のファイルを含むディレクトリは、ワークスペースのルートと見なされます。したがって、Bazel は、WORKSPACE ファイルを含むサブディレクトリを元にしたワークスペースのディレクトリ ツリーをすべて無視します。
Bazel は WORKSPACE ファイルのエイリアスとして WORKSPACE.bazel ファイルもサポートしています。両方のファイルが存在する場合は、WORKSPACE.bazel が使用されます。
リポジトリ
コードはリポジトリで整理されます。WORKSPACE ファイルを含むディレクトリは、メイン リポジトリ（@ とも呼ばれます）のルートです。その他（外部）リポジトリは、ワークスペース ルールを使用して WORKSPACE ファイルで定義するか、Bzlmod システムのモジュールと拡張機能から生成します。詳細については、外部依存関係の概要をご覧ください。
Bazel にバンドルされているワークスペース ルールは、Build Encyclopedia のワークスペース ルール セクションと 埋め込みの 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 のシンボルを、実行中に B のランタイム データを A が利用できるため、この依存関係の影響が発生します。
すべてのルールの不変というのは、ルールによって生成されたファイルが常にルールと同じパッケージに属し、ファイルを別のパッケージに生成できないことです。ただし、ルールの入力が別のパッケージから返されることも珍しくありません。
パッケージ グループは、特定のルールのアクセシビリティを制限することを目的としたパッケージのセットです。パッケージ グループは、package_group 関数で定義します。このパッケージには、含まれるパッケージのリスト、名前、それらに含まれる他のパッケージ グループの 3 つのプロパティがあります。参照できる唯一の方法は、ルールの visibility 属性、または package 関数の default_visibility 属性です。ファイルを生成、消費することはありません。詳細については、package_group のドキュメントをご覧ください。