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

<ph type="x-smartling-placeholder"></ph> 問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

ワークスペース

ワークスペースは、ソースを含むファイル システム上のディレクトリ ツリーです。 作成するソフトウェア用のファイルです。各ワークスペースには、名前を付けたテキスト ファイルが WORKSPACE: 空か、外部への参照を含めることができます。 依存関係があります。

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

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

リポジトリ

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

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

外部リポジトリはそれ自体がリポジトリであるため、多くの場合、 WORKSPACE ファイルも同様です。ただし、これらの追加の WORKSPACE ファイルは Bazel では無視されます。特に、推移的に依存するリポジトリは 自動的に追加されます。

パッケージ

リポジトリ内のコード編成の基本単位はパッケージです。 package は、関連ファイルのコレクションと、そのファイルを 使用されます。

パッケージは、コンテナ イメージを含むディレクトリとして 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 つ目の種類のターゲットは、ルールで宣言されます。各ルール インスタンス 一連の入力ファイルと出力ファイルのセットの関係を指定します。「 ソースファイルにすることもできますが、他のルールの出力に できます。

ルールへの入力がソースファイルか生成されたファイルかは、 重要ではないケース重要なのはそのファイルの内容だけです。この事実 を使用すると、複雑なソースファイルを、Google Cloud で生成された たとえば、大規模なインフラストラクチャを手作業で維持する負担が、 構造化ファイルの作成は面倒になり、誰かがプログラムを作成してそれを導き出します。 このファイルの使用者を変更する必要はありません。逆に、生成された ファイルは、ローカルの変更のみを含むソースファイルと簡単に置き換えることができます。

ルールへの入力には、他のルールも含めることができます。かかる Pod の正確な意味は、 非常に複雑で言語やルールに依存しますが 直感的にシンプルです。C++ ライブラリ ルール A に別の C++ ライブラリと ルール B を入力します。この依存関係の効果により、B のヘッダー ファイルが 利用可能になると、A は B のシンボルをコンパイル時に リンクされ、実行中に A は B のランタイム データを利用できます。

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

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

<ph type="x-smartling-placeholder"></ph> ラベル