前のセクションでは、パッケージ、ターゲット、ラベル、および ビルド依存関係グラフについて抽象的に説明しました。このセクションでは、パッケージの定義に使用される具体的な構文 について説明します。
定義上、すべてのパッケージには短い
プログラムである BUILD ファイルが含まれています。
BUILD ファイルは、命令型言語である
Starlark を使用して評価されます。
これらは、一連のステートメントとして解釈されます。
一般に、順序は重要です。たとえば、変数は使用する前に
使用する必要があります。ただし、ほとんどの BUILD ファイルは
ビルドルールの宣言のみで構成されており、これらのステートメントの相対的な順序は関係ありません。重要なのは、パッケージの評価が完了するまでに宣言された どの ルールと、その値です。
`cc_library` などのビルドルール関数が実行されると、グラフに新しいターゲットが作成されます。このターゲットは、後でラベルを使用して参照できます。
単純な BUILD ファイルでは、動作を変更せずに
ルールの宣言の順序を自由に変更できます。
コードとデータの明確な分離を促進するため、BUILD ファイルに関数定義、for ステートメント、if ステートメントを含めることはできません（ただし、リスト内包表記と if 式は使用できます）。関数は代わりに
.bzl ファイルで宣言できます。また、*args 引数と **kwargs 引数は
BUILD ファイルでは使用できません。代わりに、すべての引数を明示的にリストします。
重要な点として、Starlark のプログラムは任意の I/O を実行できません。この不変条件
により、BUILD ファイルの解釈は既知の
入力セットのみに依存するようになり、ビルドの再現性を確保するために不可欠です。
詳細については、Hermeticityをご覧ください。
BUILD ファイルは、
技術的には Latin-1 文字セットを使用して解釈されますが、ASCII 文字のみを使用して記述する必要があります。
BUILD ファイルは、基盤となるコードの依存関係が変更されるたびに更新する必要があるため、通常はチームの複数のメンバーによって管理されます。BUILD ファイルの作成者は、各ビルドターゲットの役割（一般公開を目的としているかどうか）とパッケージ自体の役割を文書化するために、自由にコメントを追加する必要があります。
拡張機能を読み込む
Bazel 拡張機能は、.bzl で終わるファイルです。load ステートメントを使用して、拡張機能からシンボルをインポートします。
load("//foo/bar:file.bzl", "some_library")
このコードは、ファイル foo/bar/file.bzl を読み込み、some_library シンボル
を環境に追加します。これは、新しいルール、関数、定数
（文字列やリストなど）を読み込むために使用できます。`load` の呼び出しに
追加の引数を使用すると、複数のシンボルをインポートできます。引数は文字列リテラル
（変数なし）にする必要があり、load ステートメントはトップレベルに記述する必要があります。関数本体に記述することはできません。
load の最初の引数は、ラベル を識別する
.bzl ファイルです。相対ラベルの場合、現在の bzl ファイルを含む
パッケージ（ディレクトリではない）を基準に解決されます。Relative labels in
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 など）。これらの関数の一部は
ビルド百科事典に記載されていますが、誰でも新しいルールを作成できます。
*_binaryルールは、指定された言語で実行可能プログラムをビルドします。ビルド後、実行可能ファイルはビルドツールのバイナリ出力ツリー内のルールのラベルに対応する名前で保存されます。したがって、//my:programは（たとえば）$(BINDIR)/my/programに表示されます。一部の言語では、このようなルールによって、ルールの
data属性または依存関係の推移的 閉包内のルールで言及されているすべてのファイルを含む runfiles ディレクトリ も作成されます。このファイルセットは、本番環境へのデプロイを容易にするために 1 か所に集められます。*_testルールは、自動テストに使用される*_binaryルールの特殊化です。テストは、成功時にゼロを返すプログラムです。バイナリと同様に、テストにも runfiles ツリーがあり、その下のファイルは、テストが実行時に正当に開くことができる唯一のファイルです。たとえば、プログラム
cc_test(name='x', data=['//foo:bar'])は、実行中に$TEST_SRCDIR/workspace/foo/barを開いて読み取ることができます。 （各プログラミング言語には$TEST_SRCDIRの値にアクセスするための独自のユーティリティ関数がありますが、どれも環境変数を直接使用するのと同じです）。 このルールに従わないと、リモート テストホストで実行されたときにテストが 失敗します。*_libraryルールは、指定された プログラミング言語で個別にコンパイルされたモジュールを指定します。ライブラリは他のライブラリに依存でき、 バイナリとテストはライブラリに依存できます。この場合、想定される 個別のコンパイル動作になります。
| ラベル | 依存関係 |