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