ここまでのセクションでは、パッケージ、ターゲット、ラベルについて説明し、 依存関係グラフを抽象化します。このセクションでは、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_binary、cc_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> 依存関係 |