Bazel は、ワークスペースと呼ばれるディレクトリ ツリーに編成されたソースコードからソフトウェアを構築します。ワークスペース内のソースファイルは、ネストされたパッケージの階層に編成されます。各パッケージは、関連するソースファイルのセットと 1 つの BUILD ファイルを含むディレクトリです。BUILD ファイルは、ソースからビルドできるソフトウェア出力を指定します。
ワークスペース
ワークスペースは、ビルドするソフトウェアのソースファイルを含む、ファイル システム上のディレクトリ ツリーです。各ワークスペースには WORKSPACE という名前のテキスト ファイルがあります。このファイルは空の場合もあれば、出力のビルドに必要な外部依存関係への参照が含まれる場合もあります。
WORKSPACE という名前のファイルを含むディレクトリは、ワークスペースのルートとみなされます。したがって、Bazel は WORKSPACE ファイルを含むサブディレクトリをルートとするワークスペース内のディレクトリ ツリーをすべて無視して、別のワークスペースを形成します。
Bazel は、WORKSPACE ファイルのエイリアスとして、WORKSPACE.bazel ファイルもサポートします。両方のファイルが存在する場合は、WORKSPACE.bazel が使用されます。
リポジトリ
コードはリポジトリにまとめられています。WORKSPACE ファイルを含むディレクトリは、メイン リポジトリのルート（@ とも呼ばれます）です。他の（外部）リポジトリは、ワークスペース ルールを使用して WORKSPACE ファイルで定義されます。
Bazel にバンドルされているワークスペース ルールについては、Workspace のルールセクション（ 百科事典の作成および埋め込み 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 があるとします。 101}この依存関係の影響により、コンパイル中に B のヘッダー ファイルは A で使用可能になり、リンク中は B のシンボルが A で使用でき、実行中に B のランタイム データは A で使用できるようになります。
どのルールでも、ルールによって生成されるファイルは、常にルール自体と同じパッケージに属します。別のパッケージにファイルを生成することはできない。ただし、ルールの入力が別のパッケージから取得されることは珍しくありません。
パッケージ グループは、特定のルールのユーザー補助機能を制限することを目的とするパッケージのセットです。パッケージ グループは、package_group 関数で定義します。
含まれる 3 つのプロパティ: 含まれるパッケージのリスト、名前、および含まれる他のパッケージ グループ。これらを参照するには、ルールの visibility 属性または package 関数の default_visibility 属性を使用する必要があります。ファイルの生成や使用は行わない。
詳細については、package_group のドキュメントをご覧ください。