ラベル

すべてのターゲットは 1 つのパッケージにのみ属します。ターゲットの名前は「ラベル」と呼ばれます。 すべてのラベルはターゲットを一意に識別します。正規形の一般的なラベルは次のようになります。

@myrepo//my/app/main:app_binary

ラベルの最初の部分はリポジトリ名 @myrepo// です。 ラベルが使用されているリポジトリと同じリポジトリを参照する場合、リポジトリ ID は // と省略できます。 したがって、@myrepo 内では、通常このラベルは次のように記述されます。

//my/app/main:app_binary

ラベルの 2 番目の部分は、修飾されていないパッケージ名 my/app/main です。これは、リポジトリのルートに対するパッケージのパスです。 リポジトリ名と修飾されていないパッケージ名を組み合わせると、完全修飾パッケージ名 @myrepo//my/app/main になります。ラベルが使用されているパッケージと同じパッケージを参照する場合、パッケージ名（コロンは省略可）を省略できます。 したがって、@myrepo//my/app/main 内では、このラベルは次のいずれかの方法で記述できます。

app_binary
:app_binary

ファイルの場合はコロンを省略し、ルールの場合はコロンを保持するという慣例がありますが、それ以外に意味はありません。

コロンの後のラベルの部分 app_binary は、修飾されていないターゲット名です。パッケージ パスの最後のコンポーネントと一致する場合は、そのコンポーネントとコロンを省略できます。 したがって、次の 2 つのラベルは同じ意味になります。

//my/app/lib
//my/app/lib:lib

パッケージのサブディレクトリにあるファイル ターゲットの名前は、パッケージのルート（BUILD ファイルを含むディレクトリ）に対するファイルのパスです。したがって、このファイルはリポジトリの my/app/main/testdata サブディレクトリにあります。

//my/app/main:testdata/input.txt

//my/app や @some_repo//my/app などの文字列は、使用されるコンテキストによって 2 つの意味を持ちます。Bazel がラベルを必要とする場合、それぞれ //my/app:app と @some_repo//my/app:app を意味します。ただし、Bazel がパッケージを必要とする場合（package_group 仕様など）、そのラベルを含むパッケージを参照します。

BUILD ファイルでよくある間違いは、//my/app を使用してパッケージまたはパッケージ内のすべてのターゲットを参照することです。これは正しくありません。 これは //my/app:appと同じであるため、現在のリポジトリのmy/app パッケージ内のappターゲットに名前を付けます。

ただし、package_group の仕様または .bzl ファイルでパッケージを参照するために //my/app を使用することをおすすめします。これにより、パッケージ名が絶対パスであり、ワークスペースの最上位ディレクトリをルートにしていることが明確に伝わります。

相対ラベルを使用して他のパッケージのターゲットを参照することはできません。この場合は、リポジトリ ID とパッケージ名を常に指定する必要があります。 たとえば、ソースツリーにパッケージ my/app と パッケージ my/app/testdata の両方が含まれている場合（これらの 2 つのディレクトリにはそれぞれ独自の BUILD ファイルがあります）、後者のパッケージには testdepot.zip という名前のファイルが含まれています。//my/app:BUILD 内でこのファイルを参照する方法は 2 つあります（1 つは間違っていて、1 つは正しい）。

間違い — testdata は別のパッケージであるため、相対パスを使用できません

testdata/testdepot.zip

正しい - フルパスで testdata を参照する

//my/app/testdata:testdepot.zip

@// で始まるラベルはメイン リポジトリへの参照であり、外部リポジトリからでも引き続き機能します。したがって、@//a/b/c は //a/b/c 外部リポジトリから参照する場合とは異なります。 前者はメイン リポジトリを参照しますが、後者は外部リポジトリ自体で //a/b/c を検索します。 これは、メイン リポジトリ内のターゲットを参照するルールをメイン リポジトリに記述し、外部リポジトリから使用する場合に特に重要です。

ターゲットを参照するさまざまな方法については、 ターゲット パターンをご覧ください。

ラベルの語彙仕様

ラベルの構文では、シェルで特別な意味を持つメタ文字の使用は推奨されていません。これにより、誤って引用符を使用する問題を回避し、 Bazel Query Languageなどのラベルを操作するツールやスクリプトを簡単に作成できます。

許可されるターゲット名の詳細については、以下をご覧ください。

ターゲット名 - package-name:target-name

target-name は、パッケージ内のターゲットの名前です。ルールの名前は、BUILD ファイル内のルールの宣言にある name 属性の値です。ファイルの名前は、BUILD ファイルを含むディレクトリに対するパス名です。

ターゲット名は、a～z、 A～Z、0～9 の文字と句読点 !%-@^_"#$&'()*-+,;<=>?[]{|}~/. のみで構成する必要があります。

ファイル名は、正規形の相対パス名にする必要があります。つまり、スラッシュで始まったりスラッシュで終わったりすることはできません（/foo と foo/ は禁止されています）。また、パス区切り文字として複数の連続するスラッシュを含めることもできません（foo//bar など）。同様に、上位レベルの参照（..）と現在のディレクトリの参照（./）は禁止されています。

間違い - `..` を使用して他のパッケージのファイルを参照しないでください

正しい — `//package-name:filename` を使用する

ファイル ターゲットの名前には / を使用するのが一般的ですが、ルールの名前には / を使用しないでください。特にラベルの短縮形を使用する場合は、読者を混乱させる可能性があります。ラベル //foo/bar/wiz は、foo/bar/wiz というパッケージが存在しない場合でも、常に //foo/bar/wiz:wiz の短縮形です。ターゲットが存在する場合でも、//foo:bar/wiz を参照することはありません。

ただし、スラッシュを使用すると便利な場合や、必要な場合もあります。たとえば、特定のルールの名前は、パッケージのサブディレクトリに存在する可能性があるメイン ソースファイルと一致する必要があります。

パッケージ名 - //package-name:target-name

パッケージの名前は、BUILD ファイルを含むディレクトリの名前です。これは、包含リポジトリの最上位ディレクトリからの相対パスです。 例: my/app。

パッケージ名は、 A-Z、a–z、0–9、'/'、'-'、'.'、'@'、および '_' の文字のみで構成する必要があります。 スラッシュで始めることはできません。

モジュール システムにとってディレクトリ構造が重要な言語（Java など）の場合は、その言語で有効な識別子であるディレクトリ名を選択することが重要です。

Bazel はワークスペースのルート パッケージのターゲット（//:foo など）をサポートしていますが、意味のあるパッケージにわかりやすい名前を付けるため、そのパッケージは空にしておくことをおすすめします。

パッケージ名にサブストリング // を含めることはできません。また、スラッシュで終わることもできません。

ルール

ルールは、入力と出力の関係と、出力をビルドする手順を指定します。ルールにはさまざまな種類があります（ルールクラスと呼ばれることもあります）。ビルド百科事典で説明されているように、コンパイル済みの実行可能ファイルとライブラリ、テスト実行可能ファイル、その他のサポートされている出力が生成されます。

BUILD ファイルは、ルールを呼び出すことで ターゲット を宣言します。

次の例では、cc_binary ルールを使用してターゲット my_app を宣言しています。

cc_binary(
    name = "my_app",
    srcs = ["my_app.cc"],
    deps = [
        "//absl/base",
        "//absl/strings",
    ],
)

すべてのルール呼び出しには name 属性（有効な ターゲット名である必要があります）があり、パッケージ 内のターゲットを宣言します。BUILD ファイル。

すべてのルールには一連の属性があります。特定の ルールに適用可能な属性と、各属性の意味とセマンティクスは、 ルールの種類によって異なります。ルールとその対応する属性の リストについては、ビルド百科事 9 典をご覧ください。各属性には名前と型があります。属性に設定できる一般的な型には、整数、ラベル、ラベルのリスト、文字列、文字列のリスト、出力ラベル、出力ラベルのリストなどがあります。すべてのルールで、すべての属性を指定する必要はありません。したがって、属性はキー（名前）から省略可能な型付きの値へのディクショナリを形成します。

多くのルールに存在する srcs 属性の型は「ラベルのリスト」です。値が存在する場合、ラベルのリストになります。各ラベルは、このルールへの入力であるターゲットの名前です。

場合によっては、ルールの種類の名前は任意であり、ルールによって生成されるファイルの名前の方が重要です。これは genrule に当てはまります。詳細については、 一般的なルール: genrule をご覧ください。

名前が重要な場合もあります。たとえば、*_binary ルールと *_test ルールの場合、ルール名によってビルドで生成される実行可能ファイルの名前が決まります。

ターゲットに対するこの有向非巡回グラフは、ターゲット グラフまたは ビルド依存関係グラフと呼ばれ、 Bazel Query ツールが動作するドメインです。

ターゲット BUILD ファイル