これまでのセクションでは、パッケージ、ターゲット、ラベル、ビルド依存関係グラフを抽象的に説明しました。このセクションでは、パッケージを定義するために使用される具体的な構文について説明します。
定義上、すべてのパッケージには BUILD プログラム（短いプログラム）が含まれています。BUILD ファイルは、命令型言語 Starlark を使用して評価されます。
これらはステートメントの連続リストとして解釈されます。
一般的に、順序は重要です。たとえば、変数を使用する前に変数を定義する必要があります。ただし、ほとんどの BUILD ファイルはビルドルールの宣言のみで構成され、これらのステートメントの相対的な順序は重要ではありません。重要なことは、パッケージ評価の完了時までに、どのルールがどの値とともに宣言されたかだけです。
cc_library などのビルドルール関数が実行されると、グラフに新しいターゲットが作成されます。このターゲットは、後でラベルを使用して参照できます。
シンプルな BUILD ファイルでは、動作を変更せずに、ルールの宣言の順序を変更できます。
コードとデータを明確に分離するために、BUILD ファイルに関数定義、for ステートメント、if ステートメントを含めることはできません（ただし、リスト理解と if 式は使用できます）。代わりに、.bzl ファイルで関数を宣言できます。また、BUILD ファイルでは *args 引数と **kwargs 引数を使用できません。代わりにすべての引数を明示的にリストしてください。
重要な点として、Starlark のプログラムは任意の I/O を実行できません。この不変量により、BUILD ファイルの解釈は既知の入力セットのみに依存するため、ビルドの再現性を確保するために不可欠です。詳細については、密閉性をご覧ください。
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++ バイナリ、ライブラリ、テストのビルドルールです。他の言語は同じ命名規則を使用します（Java の場合は java_* など）。それらの関数の一部は Build Encyclopedia に記載されていますが、誰でも新しいルールを作成することが可能です。
*_binaryルールは、特定の言語で実行プログラムを作成します。ビルド後、実行ファイルはルールラベルに対応する名前のビルドツールのバイナリ出力ツリーに存在するため、//my:programは$(BINDIR)/my/programなどに表示されます。一部の言語では、ルールに属する
data属性や、依存関係の推移的な終了ルールにあるすべてのファイルを含むランファイル ディレクトリも作成されます。これらのファイルは、本番環境へのデプロイを容易にするために 1 か所にまとめられます。*_testルールは*_binaryルールの特殊な機能であり、自動テストで使用されます。テストは、成功するとゼロを返すプログラムです。バイナリと同様に、テストにはランファイル ツリーもあり、その下にあるファイルは、実行時に正当に開くことができる唯一のファイルです。たとえば、
cc_test(name='x', data=['//foo:bar'])プログラムは、実行中に$TEST_SRCDIR/workspace/foo/barを開いて読み取ることができます。（各プログラミング言語には、$TEST_SRCDIRの値にアクセスするための独自のユーティリティ関数がありますが、すべて環境変数を直接使用するのと同じです）。ルールを監視しない場合は、リモートテストホストで実行されたときにテストが失敗します。*_libraryルールは、指定されたプログラミング言語で個別にコンパイルされたモジュールを指定します。ライブラリは他のライブラリに依存し、バイナリとテストはライブラリに依存し、想定される個別のコンパイル動作が発生する可能性があります。
| ラベル | 依存関係 |