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

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

Bazel は、次のディレクトリ ツリーで整理されたソースコードからソフトウェアをビルドします。 できます。ワークスペースは定義済みのリポジトリのセットで構成されます。送信元 リポジトリ内のファイルは、ネストされたパッケージ階層に編成されています。 各パッケージは、関連するソースファイルのセットと 1 つの BUILD ファイル。BUILD ファイルでは、ビルドできるソフトウェア出力を指定します。 あります。

リポジトリ

Bazel ビルドで使用されるソースファイルは、リポジトリ(多くの場合、 repos に短縮されます)。リポジトリはディレクトリ ツリーで、ここに境界マーカー ファイルが ルートです。境界線マーカー ファイルは、MODULE.bazelREPO.bazel、または 以前のコンテキストでは、WORKSPACE または WORKSPACE.bazel

現在の Bazel コマンドが実行されているリポジトリはメイン リポジトリをご覧ください。その他の(外部)リポジトリは、リポジトリ ルールによって定義されます。社外向け資料をご覧ください。 依存関係の概要をご覧ください。

ワークスペース

ワークスペースは、同じプロジェクトから実行されるすべての Bazel コマンドで共有される環境です。 あります。メイン リポジトリと、すべての定義済みの外部リポジトリのセット できます。

これまで「リポジトリ」のコンセプトはと「workspace」を 混同し、“Workspace”という用語はよく使われるのは 「repository」の同義語として使われることさえあります。

パッケージ

リポジトリ内のコード編成の基本単位はパッケージです。 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> ラベル