一般的な定義

問題を報告する ソースを表示 Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

このセクションでは、多くの関数やビルドルールに共通するさまざまな用語とコンセプトを定義します。

目次

• Bourne シェルのトークン化
• ラベルの拡張
• ほとんどのビルドルールで定義される一般的な属性
• すべてのビルドルールに共通する属性
• すべてのテストルールに共通する属性（*_test）
• すべてのバイナリルールに共通の属性（*_binary）
• 構成可能な属性
• 暗黙的な出力ターゲット

Bourne シェルのトークン化

一部のルールの特定の文字列属性は、Bourne シェルのトークン化ルールに従って複数の単語に分割されます。引用符なしのスペースは単語を区切ります。単一引用符、二重引用符、バックスラッシュはトークン化を防ぐために使用されます。

このトークン化の対象となる属性は、このドキュメントの定義で明示的に示されています。

「Make」変数の展開と Bourne シェルのトークン化の対象となる属性は、通常、コンパイラやその他のツールに任意のオプションを渡すために使用されます。このような属性の例としては、cc_library.copts と java_library.javacopts があります。これらの置換を使用すると、単一の文字列変数を構成固有のオプションワードのリストに展開できます。

ラベルの拡張

ごく一部のルールの文字列属性は、ラベル展開の対象となります。これらの文字列に //mypkg:target などの有効なラベルが部分文字列として含まれ、そのラベルが現在のルールの宣言された前提条件である場合、そのラベルは、ターゲット //mypkg:target で表されるファイルのパス名に展開されます。

属性の例には、genrule.cmd と cc_binary.linkopts があります。詳細は、相対ラベルが展開されるかどうか、複数のファイルに展開されるラベルの処理方法など、ケースごとに大きく異なる場合があります。詳細については、ルール属性のドキュメントをご覧ください。

ほとんどのビルドルールで定義される一般的な属性

このセクションでは、多くのビルドルールで定義される属性について説明します（ただし、すべてではありません）。

属性	説明
data	ラベルのリスト。デフォルトは [] です。 このルールが実行時に必要とするファイル。ファイルまたはルールのターゲットを一覧表示できます。通常、任意のターゲットを許可します。 data 属性のターゲットのデフォルトの出力とランファイルは、このターゲットによって出力される、またはこのターゲットにランタイム依存関係がある実行可能ファイルの *.runfiles 領域に表示されます。これには、このターゲットの srcs の実行時に使用されるデータファイルやバイナリが含まれる場合があります。データファイルに依存して使用する方法については、データの依存関係のセクションをご覧ください。 新しいルールで、実行時に他の入力を使用する可能性がある入力を処理する場合は、data 属性を定義する必要があります。ルールの実装関数は、data 属性の出力とランファイル、およびソースコードまたはランタイム依存関係を提供する依存関係属性のランファイルからターゲットのランファイルを入力する必要があります。
deps	ラベルのリスト。デフォルトは [] です。 このターゲットの依存関係。通常は、ルールのターゲットのみを含めます。（一部のルールでは、ファイルを deps に直接リストすることを許可していますが、可能であれば避けてください）。 通常、言語固有のルールでは、特定のプロバイダのターゲットのみが表示されます。 ターゲットが deps を使用して別のターゲットに依存する意味の正確なセマンティクスは、ルールの種類に固有です。ルール固有のドキュメントで詳細を確認してください。ソースコードを処理するルールの場合、deps は通常、srcs のコードで使用されるコード依存関係を指定します。 ほとんどの場合、deps 依存関係は、1 つのモジュールが同じプログラミング言語で記述され、別々にコンパイルされた別のモジュールで定義されたシンボルを使用できるようにするために使用されます。多くの場合、言語間の依存関係も許可されます。たとえば、java_library ターゲットは、deps 属性に cc_library ターゲットの C++ コードをリストすることで、cc_library ターゲットの C++ コードに依存できます。詳細については、依存関係の定義をご覧ください。
licenses	文字列のリスト。構成不可。デフォルトは ["none"] です。 この特定のターゲットに使用するライセンス タイプの文字列のリスト。これは、Bazel で使用されなくなった非推奨のライセンス API の一部です。使用しないでください。
srcs	ラベルのリスト。デフォルトは [] です。 このルールによって処理されるファイルまたはこのルールに含まれるファイル。通常はファイルを直接一覧表示しますが、デフォルト出力を含めるようにルール ターゲット（filegroup や genrule など）を一覧表示することもできます。 言語固有のルールでは、リスト内のファイルに特定のファイル拡張子が必要になることがよくあります。

すべてのビルドルールに共通する属性

このセクションでは、すべてのビルドルールに暗黙的に追加される属性について説明します。

属性	説明
compatible_with	ラベルのリスト。構成不可。デフォルトは []。 デフォルトでサポートされている環境に加えて、このターゲットをビルドできる環境のリスト。 これは Bazel の制約システムの一部であり、ユーザーは相互に依存できるターゲットとできないターゲットを宣言できます。たとえば、外部にデプロイ可能なバイナリは、会社の秘密コードを含むライブラリに依存しないでください。詳細については、 ConstraintSemantics をご覧ください。
deprecation	文字列。構成不可。デフォルトは None です。 このターゲットに関連付けられた説明的な警告メッセージ。通常、これは、ターゲットが廃止された、別のルールに置き換えられた、パッケージ専用である、またはなんらかの理由で有害とみなされる可能性があることをユーザーに通知するために使用されます。メッセージが表示されないようにするために必要な変更を簡単に見つけられるように、参照情報（ウェブページ、バグ番号、移行 CL の例など）を含めることをおすすめします。ドロップイン リプレイスメントとして使用できる新しいターゲットがある場合は、古いターゲットのすべてのユーザーを移行することをおすすめします。 この属性はビルド方法には影響しませんが、ビルドツールの診断出力に影響する可能性があります。deprecation 属性を持つルールが別のパッケージ内のターゲットに依存している場合、ビルドツールは警告を出します。 パッケージ内の依存関係は、この警告の対象外です。たとえば、非推奨のルールのテストビルドで警告が発生することはありません。 非推奨のターゲットが別の非推奨のターゲットに依存している場合、警告メッセージは出力されません。 ユーザーが使用しなくなったら、ターゲットを削除できます。
distribs	文字列のリスト。構成不可。デフォルトは [] です。 この特定のターゲットに使用する配信方法の文字列のリスト。これは、Bazel で使用されなくなった非推奨のライセンス API の一部です。使用しないでください。
exec_compatible_with	ラベルのリスト。構成不可。デフォルトは []。 このターゲットの実行プラットフォームに存在する必要がある constraint_values のリスト。これは、ルールタイプですでに設定されている制約に加えて適用されます。制約は、使用可能な実行プラットフォームのリストを制限するために使用されます。詳細については、ツールチェーンの解決の説明をご覧ください。
exec_properties	文字列の辞書。デフォルトは {} です。 このターゲット用に選択したプラットフォームの exec_properties に追加される文字列の辞書。platform ルールの exec_properties をご覧ください。 キーがプラットフォーム レベルとターゲット レベルのプロパティの両方に存在する場合、値はターゲットから取得されます。
features	特徴文字列のリスト。デフォルトは [] です。 特徴とは、ターゲットで有効または無効にできる文字列タグです。特徴の意味はルール自体によって異なります。 この features 属性は、 パッケージ レベルの features 属性と組み合わせて使用します。たとえば、パッケージ レベルで特徴 ["a", "b"] が有効になっていて、ターゲットの features 属性に ["-a", "c"] が含まれている場合、ルールで有効になる特徴は「b」と「c」になります。 例をご覧ください。
restricted_to	ラベルのリスト。構成不可。デフォルトは []。 デフォルトでサポートされている環境ではなく、このターゲットをビルドできる環境のリスト。 これは Bazel の制約システムの一部です。詳しくは、compatible_with をご覧ください。
tags	文字列のリスト。構成不可。デフォルトは []。 タグは任意のルールで使用できます。テストと test_suite ルールのタグは、テストを分類するのに役立ちます。テスト以外のターゲット上のタグは、genrule と Starlark アクションのサンドボックス実行を制御し、人間または外部ツールによる解析に使用されます。 Bazel は、テストまたは genrule ターゲットの tags 属性、または Starlark アクションの execution_requirements のキーで次のキーワードが見つかった場合、サンドボックス化コードの動作を変更します。 no-sandbox キーワードを使用すると、アクションまたはテストがサンドボックス化されることはありません。キャッシュに保存したり、リモートで実行したりすることはできます。no-cache または no-remote を使用して、これらのいずれかまたは両方を防ぎます。 no-cache キーワードを使用すると、アクションまたはテストが（リモートまたはローカルで）キャッシュに保存されなくなります。 no-remote-cache キーワードを使用すると、アクションまたはテストはリモートでキャッシュに保存されなくなります（ただし、ローカルでキャッシュに保存される場合や、リモートで実行される場合もあります）。注: このタグでは、ディスク キャッシュはローカル キャッシュと見なされ、http キャッシュと gRPC キャッシュはリモート キャッシュと見なされます。ローカル ディスク キャッシュとリモート キャッシュの組み合わせ（結合キャッシュ）を使用する場合、それはリモート キャッシュとして扱われ、--incompatible_remote_results_ignore_disk が設定されていない限り完全に無効になります。この場合、ローカル コンポーネントが使用されます。 no-remote-exec キーワードを使用すると、アクションまたはテストがリモートで実行されることはありません（ただし、リモートでキャッシュに保存される場合があります）。 no-remote キーワードを使用すると、アクションやテストがリモートで実行されたり、リモートでキャッシュに保存されたりするのを防ぐことができます。これは、no-remote-cache と no-remote-exec の両方を使用する場合と同じです。 no-remote-cache-upload キーワードは、スポーンのリモート キャッシュのアップロード部分を無効にします。リモート実行が無効になることはありません。 local キーワードを使用すると、アクションまたはテストがリモートでキャッシュに保存されたり、リモートで実行されたり、サンドボックス内で実行されたりすることはありません。genrule とテストの場合、local = True 属性でルールをマークしても同じ効果があります。 requires-network キーワードを使用すると、サンドボックス内から外部ネットワークにアクセスできます。このタグは、サンドボックスが有効な場合にのみ効果があります。 block-network キーワードは、サンドボックス内から外部ネットワークへのアクセスをブロックします。この場合、localhost との通信のみが許可されます。このタグは、サンドボックスが有効な場合にのみ効果があります。 requires-fakeroot は、uid と gid 0（root ユーザー）としてテストまたはアクションを実行します。これは Linux でのみサポートされています。このタグは、--sandbox_fake_username コマンドライン オプションよりも優先されます。 テストのタグは、通常、デバッグ プロセスとリリース プロセスにおけるテストの役割にアノテーションを付けるために使用されます。通常、タグは、ランタイム アノテーション機能がない C++ テストと Python テストに最も役立ちます。タグとサイズ要素を使用すると、コードベースのチェックイン ポリシーに基づいてテストスイートを柔軟に組み立てることができます。 Bazel は、テストルールの tags 属性に次のキーワードが見つかった場合に、テスト実行動作を変更します。 exclusive を使用すると、テストが「排他的」モードで強制的に実行され、他のテストが同時に実行されなくなります。このようなテストは、すべてのビルド アクティビティと排他的でないテストが完了した後に、順番に実行されます。Bazel はリモートマシンで実行されている内容を制御できないため、このようなテストではリモート実行が無効になっています。 exclusive-if-local は、ローカルで実行される場合はテストを「排他的」モードで強制的に実行しますが、リモートで実行される場合はテストを並行して実行します。 manual キーワードを使用すると、build、test、coverage コマンドに対してビルドまたは実行するトップレベル ターゲットのセットを計算するときに、ターゲット パターンのワイルドカード（...、:*、:all など）と、テストを明示的にリストしない test_suite ルールの展開からターゲットが除外されます。これは、query コマンドなど、他のコンテキストでのターゲット ワイルドカードやテストスイートの拡張には影響しません。manual は、継続的ビルド/テスト システムによってターゲットが自動的にビルド/実行されないことを意味するものではありません。たとえば、特定の Bazel フラグが必要なターゲットを bazel test ... から除外し、適切に構成されたプレ送信または継続的なテスト実行に含める場合があります。 external キーワードを使用すると、（--cache_test_results 値に関係なく）テストが強制的に無条件で実行されます。 テスト対象に適用されるタグの規則については、テスト エンサイクロペディアのタグの規則をご覧ください。
target_compatible_with	ラベルのリスト。デフォルトは [] です。 このターゲットが互換性があると見なされるために、ターゲット プラットフォームに存在する必要がある constraint_value のリスト。これは、ルールタイプですでに設定されている制約に加えて適用されます。ターゲット プラットフォームがリストされている制約をすべて満たしていない場合、ターゲットは互換性がないと見なされます。ターゲット パターンが展開されると（例: //...、:all）、互換性のないターゲットはビルドとテストでスキップされます。コマンドラインで明示的に指定すると、互換性のないターゲットにより Bazel でエラーが印刷され、ビルドまたはテストが失敗します。 互換性のないターゲットに間接的に依存するターゲット自体は、互換性がないものと見なされます。ビルドとテストでもスキップされます。 リストが空（デフォルト）の場合、ターゲットがすべてのプラットフォームと互換性があることを示します。 Workspace Rules 以外のすべてのルールがこの属性をサポートしています。一部のルールでは、この属性は効果がありません。たとえば、cc_toolchain に target_compatible_with を指定しても意味がありません。 互換性のないターゲットのスキップの詳細については、プラットフォーム ページをご覧ください。
testonly	ブール値。構成不可。テスト ターゲットとテストスイート ターゲットを除き、デフォルトは False です。 True の場合、このターゲットに依存できるのは、testonly ターゲット（テストなど）のみです。 同様に、testonly 以外のルールが testonly のルールに依存することはできません。 テスト（*_test ルール）とテストスイート（test_suite ルール）は、デフォルトで testonly です。 この属性は、本番環境にリリースされるバイナリにターゲットが含まれていてはならないことを意味します。 testonly は実行時ではなくビルド時に適用され、依存関係ツリーにウイルスのように伝播するため、慎重に適用する必要があります。たとえば、単体テストに役立つスタブやフェイクは、本番環境にリリースされるバイナリを含む統合テストにも役立つ可能性があるため、testonly とマークしないことをおすすめします。逆に、リンクすることさえ危険なルール（通常の動作を無条件にオーバーライドするためなど）は、必ず testonly とマークする必要があります。
toolchains	ラベルのリスト。構成不可。デフォルトは []。 このターゲットがアクセスを許可されているMake 変数を持つターゲットのセット。これらのターゲットは、TemplateVariableInfo を提供するルールのインスタンスか、Bazel に組み込まれたツールチェーン タイプの特別なターゲットです。たとえば、次のようなものです。 @bazel_tools//tools/cpp:current_cc_toolchain @bazel_tools//tools/jdk:current_java_runtime これは、プラットフォーム依存の構成のルール実装で使用されるツールチェーン解決のコンセプトとは異なります。この属性を使用して、ターゲットが使用する特定の cc_toolchain または java_toolchain を特定することはできません。
visibility	ラベルのリスト。構成不可。指定されている場合はパッケージの default_visibility、指定されていない場合は "//visibility:private" がデフォルトです。 ターゲットの visibility 属性は、ターゲットを他のパッケージで使用できるかどうかを制御します。公開設定のドキュメントをご覧ください。

すべてのテストルールに共通する属性（*_test）

このセクションでは、すべてのテストルールに共通する属性について説明します。

属性	説明
args	文字列のリスト。$(location) と 「変数を作成」の置換、Bourne シェルのトークン化の対象。デフォルトは [] bazel test で実行されたときに Bazel がターゲットに渡すコマンドライン引数。 これらの引数は、bazel test コマンドラインで指定された --test_arg 値の前に渡されます。
env	文字列のディクショナリ。値は $(location) と 「変数を作成」の置換の対象となります。デフォルトは [] です。 bazel test によってテストが実行されるときに設定する追加の環境変数を指定します。 この属性は、cc_test、py_test、sh_test などのネイティブ ルールにのみ適用されます。Starlark で定義されたテストルールには適用されません。独自の Starlark ルールの場合は、「env」属性を追加して、TestEnvironment プロバイダに入力できます。
env_inherit	文字列のリスト。デフォルトは [] です。 bazel test によってテストが実行されるときに、外部環境から継承する追加の環境変数を指定します。 この属性は、cc_test、py_test、sh_test などのネイティブ ルールにのみ適用されます。Starlark で定義されたテストルールには適用されません。
size	文字列 "enormous"、"large"、"medium"、"small"。構成不可。デフォルトは "medium"。 テスト対象の「負荷」: 実行に必要な時間とリソースの量を指定します。 単体テストは「小規模」、インテグレーション テストは「中規模」、エンドツーエンド テストは「大規模」または「非常に大規模」と見なされます。Bazel はサイズを使用してデフォルトのタイムアウトを決定します。これは timeout 属性を使用してオーバーライドできます。タイムアウトは、個々のテストではなく、BUILD ターゲットのすべてのテストに適用されます。テストがローカルで実行される場合、size はスケジューリング目的でさらに使用されます。Bazel は --local_{ram,cpu}_resources を尊重し、多くの負荷の高いテストを同時に実行してローカルマシンを圧倒しないようにします。 テストサイズは、次のデフォルトのタイムアウトと想定されるピークのローカル リソース使用量に対応しています。 サイズ RAM（MB） CPU（CPU コア数） デフォルトのタイムアウト 小 20 1 短い（1 分） 中 100 1 中程度（5 分） 大 300 1 長い（15 分） 巨大 800 1 永続（60 分） テストのスポーン時に、環境変数 TEST_SIZE がこの属性の値に設定されます。
timeout	文字列 "short"、"moderate"、"long"、または "eternal"。構成不可。デフォルトは、テストの size 属性から派生します。 テストが完了するまでに予想される時間。 テストのサイズ属性はリソースの推定値を制御しますが、テストのタイムアウトは個別に設定できます。明示的に指定しない場合、タイムアウトはテストのサイズに基づきます。テストのタイムアウトは、--test_timeout フラグでオーバーライドできます。たとえば、遅いことがわかっている特定の条件下で実行する場合などです。テスト タイムアウト値は次の時間に対応しています。 タイムアウト値 期間 short 1 分 中 5 分 long 15 分 永遠 60 分 上記以外の時間については、テストのタイムアウトを --test_timeout bazel フラグでオーバーライドできます。たとえば、遅いことがわかっている条件で手動で実行する場合などです。--test_timeout 値は秒単位です。たとえば、--test_timeout=120 はテストのタイムアウトを 2 分に設定します。 環境変数 TEST_TIMEOUT は、テストのスポーン時にテストのタイムアウト（秒単位）に設定されます。
flaky	ブール値。構成不可。デフォルトは False です。 テストを不安定なものとしてマークします。 設定されている場合、テストは最大 3 回実行され、毎回失敗した場合にのみ不合格としてマークされます。デフォルトでは、この属性は False に設定され、テストは 1 回だけ実行されます。なお、この属性の使用は一般的に推奨されません。アサーションの検証が成功した場合、テストは確実に合格する必要があります。
shard_count	50 以下の正の整数。デフォルトは -1 です。 テストの実行に使用する並列シャードの数を指定します。 設定すると、この値は、テストを実行する並列シャードの数を決定するために使用されるヒューリスティックをオーバーライドします。一部のテストルールでは、シャーディングを有効にするためにこのパラメータが必要になる場合があります。--test_sharding_strategy もご覧ください。 テスト シャーディングが有効になっている場合、テストのスポーン時に環境変数 TEST_TOTAL_SHARDS がこの値に設定されます。 シャーディングを行うには、テストランナーがテスト シャーディング プロトコルをサポートしている必要があります。シャーディングされていない場合、すべてのシャードですべてのテストが実行される可能性があり、これは望ましい動作ではありません。 シャーディングの詳細については、テスト エンサイクロペディアのテスト シャーディングをご覧ください。
local	ブール値。構成不可。デフォルトは False です。 サンドボックス化せずに、テストをローカルで強制的に実行します。 この値を True に設定することは、タグ（tags=["local"]）として「local」を指定することと同様です。

すべてのバイナリルールに共通する属性（*_binary）

このセクションでは、すべてのバイナリルールに共通する属性について説明します。

属性	説明
args	文字列のリスト。$(location) と 「変数を作成」の置換、Bourne シェルのトークン化の対象。構成不可。デフォルトは []。 run コマンドまたはテストとして実行されるときに Bazel がターゲットに渡すコマンドライン引数。これらの引数は、bazel run または bazel test コマンドラインで指定された引数の前に渡されます。 注: Bazel の外部でターゲットを実行する場合（bazel-bin/ でバイナリを手動で実行する場合など）は、引数は渡されません。
env	文字列のディクショナリ。値は $(location) と 「変数を作成」の置換の対象となります。デフォルトは {} です。 ターゲットが bazel run によって実行されるときに設定する追加の環境変数を指定します。 この属性は、cc_binary、py_binary、sh_binary などのネイティブ ルールにのみ適用されます。これは、Starlark で定義された実行可能ルールには適用されません。 注: Bazel の外部でターゲットを実行する場合（bazel-bin/ でバイナリを手動で実行する場合など）は、環境変数は設定されません。
output_licenses	文字列のリスト。デフォルトは [] です。 このバイナリが生成した出力ファイルのライセンス。これは、Bazel で使用されなくなった非推奨のライセンス API の一部です。使用しないでください。

構成可能な属性

ほとんどの属性は「構成可能」です。つまり、ターゲットの作成方法が異なると、値が変更される可能性があります。具体的には、構成可能な属性は、Bazel コマンドラインに渡されたフラグや、ターゲットをリクエストしているダウンストリーム デペンドンシティによって異なる場合があります。これは、たとえば、複数のプラットフォームまたはコンパイルモードのターゲットをカスタマイズするために使用できます。

次の例では、ターゲット アーキテクチャごとに異なるソースを宣言しています。bazel build :multiplatform_lib --cpu x86 を実行すると、x86_impl.cc を使用してターゲットがビルドされますが、--cpu arm に置き換えると、代わりに arm_impl.cc が使用されます。

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

select() 関数は、ターゲットの構成が満たす config_setting または constraint_value の条件に基づいて、構成可能な属性のさまざまな代替値から選択します。

Bazel は、マクロの処理後に、ルールの処理の前に（技術的には、 読み込みフェーズと分析フェーズの間）構成可能な属性を評価します。select() 評価前の処理では、select() が選択するブランチを認識できません。たとえば、マクロは選択したブランチに基づいて動作を変更できません。また、bazel query はターゲットの構成可能な依存関係について保守的な推測しか行えません。ルールとマクロで select() を使用する方法については、 よくある質問をご覧ください。

ドキュメントで nonconfigurable とマークされている属性では、この機能は使用できません。通常、属性は構成できません。これは、Bazel が select() の解決方法を決定する前に、内部でその値を知る必要があるためです。

詳細な概要については、 構成可能なビルド属性をご覧ください。

暗黙的な出力ターゲット

C++ の暗黙的な出力は非推奨になりました。可能であれば、他の言語で使用しないでください。まだ非推奨化の予定はありませんが、最終的には非推奨となります。

BUILD ファイルでビルドルールを定義すると、パッケージに名前付きの新しいルール ターゲットを明示的に宣言します。多くのビルドルール関数は、1 つ以上の出力ファイル ターゲットを暗黙的に含みます。その内容と意味はルール固有です。たとえば、java_binary(name='foo', ...) ルールを明示的に宣言すると、出力ファイル ターゲット foo_deploy.jar を同じパッケージのメンバーとして暗黙的に宣言します。（このターゲットは、デプロイに適した自己完結型の Java アーカイブです）。

暗黙的な出力ターゲットは、グローバル ターゲット グラフのファーストクラス メンバーです。他のターゲットと同様に、トップレベルのビルドコマンドで指定された場合、または他のビルドターゲットの前提条件として必要な場合に、オンデマンドでビルドされます。これらは、BUILD ファイルで依存関係として参照でき、bazel query などの分析ツールの出力で確認できます。

ビルドルールの種類ごとに、その種類のルールの宣言に伴う暗黙的な出力の名前と内容を詳しく説明する特別なセクションがルールのドキュメントに含まれています。

ビルドシステムで使用される 2 つの名前空間には、重要な違いがあります。ラベルはターゲットを識別します。ターゲットはルールまたはファイルのいずれかです。ファイル ターゲットは、ソース（または入力）ファイル ターゲットと派生（または出力）ファイル ターゲットに分けることができます。これらは、BUILD ファイルで指定したり、コマンドラインからビルドしたり、bazel query を使用して調べたりできるものです。これはターゲット Namespace です。各ファイル ターゲットはディスク上の 1 つの実際のファイル（「ファイル システム Namespace」）に対応します。各ルール ターゲットは、ディスク上の 0 個、1 個以上の実際のファイルに対応できます。ディスク上には、対応するターゲットがないファイルが存在する場合があります。たとえば、C++ コンパイル中に生成された .o オブジェクト ファイルは、BUILD ファイル内またはコマンドラインから参照できません。このように、ビルドツールは、その機能の実行方法に関する特定の実装の詳細を隠す場合があります。詳しくは、BUILD コンセプト リファレンスをご覧ください。