ラベルはターゲットの識別子です。完全な正規版での一般的なラベル 次のようになります。
@@myrepo//my/app/main:app_binary
ラベルの最初の部分はリポジトリ名 @@myrepo です。二重の @
構文は、これが正規リポジトリであることを示します
一意の ID タイプです。
できます。正規リポジトリ名を持つラベルはターゲットを明確に識別する
コンテキストが共通して表示されるので、
多くの場合、正規のリポジトリ名は
@@rules_java~7.1.0~toolchains~local_jdk。より一般的なのは
見かけ上のリポジトリ名を持つラベル
次のようになります。
@myrepo//my/app/main:app_binary
唯一の違いは、リポジトリ名の先頭に 2 つではなく 1 つの @ が付いていることです。
これは、myrepo という名前のリポジトリを参照していますが、これは異なる場合があります
コンテキストに基づいて自動的に分類されます。
一般的に、ラベルが参照先のリポジトリと同じリポジトリを
リポジトリ名の部分は省略できます。したがって、@@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 などの文字列は、
使用されるコンテキスト。Bazel ではラベルが想定されていますが、
それぞれ //my/app:app と @@some_repo//my/app:app です。Bazel を使用すると、
（package_group 仕様などで）パッケージを想定している場合、
そのラベルを含むパッケージです。
BUILD ファイルでよくある間違いとして、//my/app を使用してパッケージを参照することが挙げられます。
パッケージ内のすべてのターゲットに適用されます。注意すべき点は、
//my/app:app と同等であるため、my/app で app ターゲットに名前を付けます。
パッケージ化されています。
ただし、//my/app を使用してパッケージを参照することは、
これは、package_group または .bzl ファイルで指定することが推奨されるためです。
パッケージ名が絶対であり、トップレベルがルートであることを伝える
ディレクトリに移動します。
相対ラベルを使用して他のパッケージ内のターゲットを参照することはできません。
この場合は、リポジトリ ID とパッケージ名を必ず指定する必要があります。
たとえば、ソースツリーにパッケージ my/app と
パッケージ my/app/testdata（これら 2 つのディレクトリのそれぞれに独自の
BUILD ファイルなど）、後者のパッケージには testdepot.zip という名前のファイルが含まれています。現在地
フォルダ内でこのファイルを参照する方法は 2 つあります（1 つ間違って
//my/app:BUILD:
不適切 - testdata は別のパッケージであるため、相対パスを使用できません。
testdata/testdepot.zip
正解 - testdata をフルパスで参照してください
//my/app/testdata:testdepot.zip
@@// で始まるラベルは、メイン
外部リポジトリからでも機能します。
したがって、@@//a/b/c は次の値とは異なります。
外部リポジトリから参照する場合は //a/b/c。
前者はメイン リポジトリを参照し、後者はメイン リポジトリを参照します。
外部リポジトリ自体で //a/b/c を探します。
これは、メイン モジュールでルールを記述する場合に特に重要です。
メイン リポジトリ内のターゲットを参照するリポジトリであり、
外部リポジトリから使用できます。
ターゲットを参照するさまざまな方法については、以下をご覧ください。 ターゲット パターン。
ラベルの語彙の仕様
ラベル構文では、ラベルの構文に対して特別な意味を持つメタ文字の使用は推奨されません。 使用できます。これにより、不注意による引用の問題が回避され、 ラベルを操作するツールやスクリプトを作成する Bazel クエリ言語。
許可されるターゲット名の正確な詳細については、以下をご覧ください。
ターゲット名 - package-name:target-name
target-name はパッケージ内のターゲットの名前です。ルールの名前
BUILD 内のルールの宣言の name 属性の値
file;ファイルの名前は、そのファイルを含むディレクトリからの相対パス名です。
BUILD ファイル。
ターゲット名は、a～z のセットから取得した文字で完全に構成する必要があります。
A–Z、0–9、句読点記号 !%-@^_"#$&'()*-+,;<=>?[]{|}~/.。
ファイル名は、通常の形式の相対パス名にする必要があります。つまり、
先頭も末尾もスラッシュではない（たとえば、/foo と foo/ は
禁止）、またはパス区切り文字として複数の連続スラッシュを含めないでください。
（例: foo//bar）。同様に、上位レベルの参照（..）と
現在のディレクトリの参照（./）は禁止されています。
不適切 - 他のパッケージ内のファイルを参照するために「..」を使用しないでください。
正解 - 使用 `//package-name:filename`
ファイル ターゲットの名前に / を使用するのが一般的ですが、
ルール名に /。特に、ラベルの短縮形が
読み手を混乱させる可能性があります。//foo/bar/wiz ラベルは常に省略形です。
//foo/bar/wiz:wiz（該当するパッケージ foo/bar/wiz がない場合でも適用）
ターゲットが存在しても、//foo:bar/wiz を参照しません。
ただし、スラッシュを使用すると便利な場合や、 場合によっては必要であることさえありますたとえば、特定のルールの名前は同じ名前にしないと そのプリンシパル ソースファイルがパッケージのサブディレクトリに存在することがあります。
パッケージ名 - //package-name:target-name
パッケージの名前は、BUILD ファイルを含むディレクトリの名前です。
格納されているリポジトリの最上位ディレクトリからの相対パスです。
例: my/app。
パッケージ名は、セットから抽出した文字で完全に構成する必要があります
A-Z、a–z、0–9、「/」、「-」、「.」、「@」、「_」、および次のことはできません
スラッシュで始めます。
モジュールにとって重要なディレクトリ構造を持つ言語の場合 ディレクトリ名を指定することが重要です。 言語に含まれる有効な識別子です。
Bazel は、ワークスペースのルート パッケージ（
//:foo など）が含まれている場合は、意味のあるパッケージをすべて空白のままにすることをおすすめします。
わかりやすい名前を付けてください。
パッケージ名に部分文字列 // を含めることや、スラッシュで終わることはできません。
ルール
ルールは、入力と出力の関係を指定します。 出力を構築します。ルールにはさまざまなタイプがあり、 （ルールクラスと呼ばれることもあります）。これは、コンパイルされた 実行可能なファイルとライブラリ、テスト実行可能なファイル、その他サポートされている （Build 百科事典で説明されている出力）。
BUILD ファイルは、rules を呼び出すことでターゲットを宣言します。
以下の例では、ターゲット my_app の宣言が示されています。
cc_binary ルールを使用します。
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
すべてのルール呼び出しには name 属性があります（この属性は
target name）を使用して、パッケージ内でターゲットを宣言します。
BUILD ファイルの
すべてのルールには、一連の属性があります。特定のエンティティに適用可能な属性を 各属性の重要性とセマンティクスは、 ルールの種類を指定します。Build の百科事典を ルールとそれに対応する属性のリスト。各属性には名前と属性があり、 します。属性の一般的な型には、整数、ラベル、リストがあります。 ラベル、文字列、文字列のリスト、出力ラベル、出力ラベルのリスト。× すべての属性をすべてのルールで指定する必要があります。このように属性によって、 キー（名前）からオプションの型付き値までです。
多くのルールに存在する srcs 属性のタイプは「ラベルのリスト」です。
value: ラベルのリスト（存在する場合）です。各ラベルは、
このルールへの入力。
場合によっては、ルールの種類の名前はやや不明確で、 ルールによって生成されたファイルの名前に注目します。これは、 あります。詳細については、次をご覧ください: 一般ルール: genrule
それ以外の場合、*_binary ルールと *_test ルールでは名前が重要です。
たとえば、実行可能なファイルの名前が、ルール名によって
表示されます。
このターゲットに対する有向非巡回グラフは、ターゲット グラフと呼ばれます。 依存関係グラフを構築します。これはアプリケーションの Bazel クエリツールが動作する。
| <ph type="x-smartling-placeholder"></ph> 目標 | <ph type="x-smartling-placeholder"></ph> BUILD ファイル |