BUILD ファイル

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

ここまでのセクションでは、パッケージ、ターゲット、ラベルについて説明し、 依存関係グラフを抽象化します。このセクションでは、Google Cloud で 使用します。

定義上、すべてのパッケージには BUILD ファイルが含まれます。これは、 。

BUILD ファイルは、命令型言語を使用して評価されます。 Starlark

これらは、ステートメントの連続リストとして解釈されます。

一般的に順序が重要: 変数は定義する前に定義する必要がある できます。ただし、ほとんどの BUILD ファイルは、 記述され、それらの記述の相対的な順序は重要ではありません。すべて 重要なのは、各ルールで宣言されたルールと、 パッケージの評価が完了した時間です。

cc_library などのビルドルール関数を実行すると、 グラフに表示されます。このターゲットは、後でラベルを使用して参照できます。

シンプルな BUILD ファイルでは、ルールの宣言を自由に並べ替えることができます。 動作を変えることができます。

コードとデータを明確に分離するため、BUILD ファイルでは 関数定義、for ステートメント、または if ステートメントが含まれている(ただし、 理解と if 式を使用できます)。関数は .bzl ファイルを使用してください。また、*args 引数と **kwargs 引数は、 BUILD 個のファイルで許可。すべての引数を明示的に列挙します。

重要な点として、Starlark のプログラムは任意の I/O を実行できません。この不変条件は BUILD ファイルの解釈が密閉型になり、既知の認証情報にのみ依存します。 ビルドの再現性を確保するために不可欠な入力です。 詳しくは、Hermeticityをご覧ください。

BUILD ファイルは、ASCII 文字のみを使用して記述する必要があります。ただし、 技術的には、Latin-1 文字セットを使用して解釈されます。

これは、依存関係が依存関係にあるときは、常に BUILD ファイルを更新する必要があるためです。 基盤となるコード変更が行われていないため、通常は複数の人が同じ 共有しますBUILD ファイルの作成者は、十分なコメントを追加してロールを記録する必要があります。 各ビルド ターゲットの明示的な依存関係があり、一般公開を意図したものであるかどうか、 パッケージ自体の役割を文書化します。

拡張機能の読み込み

Bazel 拡張機能は、末尾が .bzl のファイルです。load ステートメントを使用してインポートする シンボルです。

load("//foo/bar:file.bzl", "some_library")

このコードは、foo/bar/file.bzl ファイルを読み込み、some_library 記号を追加します。 可視化できます。新しいルール、関数、定数を読み込むために使用できる (文字列やリストなど)。複数のシンボルを load の呼び出しに対する追加の引数。引数は文字列リテラルにする必要があります (変数なし)ステートメントと load ステートメントはトップレベルに配置する必要があります。 あります。

load の最初の引数は、ラベルを識別する .bzl ファイル。相対ラベルの場合は、ラベルの 現在の bzl ファイルを含む(ディレクトリではなく)パッケージ。相対ラベル load ステートメントでは、先頭に : を使用する必要があります。

load はエイリアスもサポートしているため、異なる名前を割り当てることができます。 インポートされます。

load("//foo/bar:file.bzl", library_alias = "some_library")

1 つの load ステートメント内で複数のエイリアスを定義できます。さらに、 引数リストには、エイリアスと通常のシンボル名の両方を含めることができます。次の (引用符を使用するタイミングに注意してください)。

load(":my_rules.bzl", "some_rule", nice_alias = "some_other_rule")

.bzl ファイルでは、_ で始まるシンボルはエクスポートされず、エクスポートできません。 別のファイルから読み込む場合です

読み込みの可視性を使用して、 .bzl ファイルを読み込む可能性のあるユーザーです。

ビルドルールのタイプ

ビルドルールの大半はファミリーにまとめられており、 あります。例: cc_binarycc_library cc_test は、C++ バイナリのビルドルールです。 ライブラリ、テストの 2 つがあります。他の言語では、 (たとえば、java_* のように、異なる接頭辞を持つ) Java です。これらの関数の一部については、 Build Encyclopedia でも作成できますが、 新しいルールを作成できます。

  • *_binary ルールは、指定された言語で実行可能プログラムを構築します。アフター 実行可能ファイルはビルドツールのバイナリに配置されます。 ルールのラベルに対応する名前の そのため、//my:program$(BINDIR)/my/program などに表示されます。

    一部の言語では、このようなルールによって runfiles ディレクトリも作成される data で言及されているすべてのファイルを含む 属性、またはその推移的ルール内の任意のルールに 依存関係のクローズこのファイルセットは 本番環境へのデプロイを容易にします

  • *_test ルールは *_binary ルールの一種で、自動化ルールに使用します。 説明します。テストは、成功するとゼロを返すプログラムです。

    バイナリと同様に、テストにもランファイル ツリーがあり、 その下に、テストで正当に開くことができる唯一のファイルがあります。 実行時に決定できますたとえば、プログラム cc_test(name='x', data=['//foo:bar']) は、実行中に $TEST_SRCDIR/workspace/foo/bar を開いて読み取ることができます。 (プログラミング言語ごとに、独自のユーティリティ関数があります)。 $TEST_SRCDIR の値にアクセスしていますが、すべて 環境変数を直接使用する場合と同等です)。 ルールの監視に失敗した場合、テストは失敗します。 実行するためのツールです。

  • *_library ルールは、個別にコンパイルされたモジュールを、 説明します。ライブラリは他のライブラリに依存し、 バイナリとテストはライブラリに依存できますが、 異なるためです。

<ph type="x-smartling-placeholder"></ph> ラベル <ph type="x-smartling-placeholder"></ph> 依存関係