Bazel は、リポジトリと呼ばれるディレクトリ ツリーに整理されたソースコードからソフトウェアをビルドします。定義されたリポジトリのセットがワークスペースを構成します。リポジトリ内のソースファイルは、パッケージのネストされた階層に整理されます。各パッケージは、関連するソースファイルのセットと 1 つの BUILD ファイルを含むディレクトリです。BUILD ファイルは、ソースからビルドできるソフトウェア出力を指定します。
リポジトリ
Bazel ビルドで使用されるソースファイルは、リポジトリ（多くの場合、
リポジトリと略されます）に整理されます。リポジトリは、ルートに境界マーカー ファイルがあるディレクトリ ツリーです。このような境界マーカー ファイルは、MODULE.bazel、REPO.bazel、または
レガシー コンテキストでは WORKSPACE または WORKSPACE.bazel になります。
現在の Bazel コマンドが実行されているリポジトリは、メイン リポジトリと呼ばれます。 他のリポジトリ（外部リポジトリ）は、リポジトリルールによって定義されます。詳細については、外部 依存関係の概要をご覧ください。
ワークスペース
ワークスペースは、同じメイン リポジトリから実行されるすべての Bazel コマンドで共有される環境です。 これには、メイン リポジトリと、定義されているすべての外部リポジトリのセットが含まれます。
歴史的に、「リポジトリ」と「ワークスペース」の概念は混同されてきました。「ワークスペース」という用語は、メイン リポジトリを指すために使用されることが多く、リポジトリの同義語として使用されることもあります。
パッケージ
リポジトリ内のコード編成の基本単位はパッケージです。 パッケージは、関連するファイルのコレクションと、出力アーティファクトの生成に使用する方法の仕様です。
パッケージは、
BUILD ファイルを含むディレクトリとして定義されます。ファイル名は 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
ドキュメントをご覧ください。