ワークスペース、パッケージ、ターゲット

問題を報告 ソースを表示 Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bazel は、ワークスペースと呼ばれるディレクトリ ツリーに編成されたソースコードからソフトウェアをビルドします。ワークスペース内のソースファイルは、パッケージのネストされた階層に編成されます。各パッケージは、関連するソースファイルのセトと 1 つの BUILD ファイルを含むディレクトリです。BUILD ファイルは、使用するソフトウェアを その出力をソースからビルドできます。

ワークスペース

ワークスペースは、ソースを含むファイル システム上のディレクトリ ツリーです。 作成するソフトウェア用のファイルです。各ワークスペースには WORKSPACE という名前のテキスト ファイルがあります。このファイルは空でもかまいません。また、出力のビルドに必要な外部依存関係への参照が含まれていることもあります。

WORKSPACE というファイルを含むディレクトリは、 見てみましょう。したがって、WORKSPACE ファイルを含むサブディレクトリをルートとするワークスペース内のディレクトリ ツリーは、別のワークスペースを形成するため、Bazel では無視されます。

Bazel は、WORKSPACE ファイルのエイリアスとして WORKSPACE.bazel ファイルもサポートしています。条件 両方のファイルが存在する場合は、WORKSPACE.bazel が使用されます。

リポジトリ

コードはリポジトリに編成されます。WORKSPACE を含むディレクトリ ファイルはメイン リポジトリのルート(@ とも呼ばれます)です。その他の(外部)リポジトリは、ワークスペース ルールを使用して WORKSPACE ファイルで定義するか、Bzlmod システムのモジュールと拡張機能から生成されます。詳細については、外部依存関係の概要をご覧ください。

Bazel にバンドルされているワークスペース ルールは、Workspace Build の [ルール] セクション 百科事典と埋め込みドキュメント Starlark リポジトリ ルール

外部リポジトリ自体がリポジトリであるため、多くの場合、WORKSPACE ファイルも含まれています。ただし、これらの追加の WORKSPACE ファイルは Bazel では無視されます。特に、リポジトリが循環的に依存している場合、リポジトリは自動的に追加されません。

パッケージ

リポジトリ内のコード編成の主要な単位はパッケージです。パッケージは、関連するファイルのコレクションと、それらを使用して出力アーティファクトを生成する方法の仕様です。

パッケージは、コンテナ イメージを含むディレクトリとして BUILD または BUILD.bazel という名前の BUILD ファイル。パッケージには、そのディレクトリ内のすべてのファイルと、そのディレクトリ内のすべてのサブディレクトリが含まれます(ただし、それ自体に BUILD ファイルが含まれているものは除きます)。この定義から、ファイルまたはディレクトリが 2 つの異なるパッケージに属することはできません。

たとえば、次のディレクトリ ツリーには、my/app という 2 つのパッケージがあります。 サブパッケージは my/app/tests です。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 のシンボルにアクセスできること、A が実行時に B のランタイム データにアクセスできることです。

すべてのルールの不変条件は、ルールによって生成されたファイルは常にルール自体と同じパッケージに属することです。別のパッケージにファイルを生成することはできません。ルールの入力が別のルールから来ることは珍しくありません。 です。

パッケージ グループとは、特定のデバイスに対するアクセスを制限することを目的とする 適用できます。パッケージ グループは package_group 関数で定義されます。パッケージ グループには、含まれるパッケージのリスト、名前、他のパッケージ グループの 3 つのプロパティがあります。これらのファイルは、ルールの visibility 属性または package 関数の default_visibility 属性からのみ参照できます。ファイルは生成または使用されません。詳細については、package_group のドキュメントをご覧ください。

ラベル