一般的な定義

問題を報告する ソースを表示

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

目次

Bourne シェルのトークン化

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

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

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

ラベルの展開

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

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

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

このセクションでは、すべてのビルドルールではなく、多くのビルドルールで定義されている属性について説明します。

属性 説明
data

ラベルのリスト。デフォルトは [] です。

実行時にこのルールに必要なファイル。ファイルまたはルールのターゲットを一覧表示できます。通常、任意のターゲットを許可します。

data 属性内のターゲットのデフォルトの出力と実行ファイルは、このターゲットによって出力される実行可能ファイル、またはこのターゲットにランタイム依存関係がある実行可能ファイルの *.runfiles 領域に配置されます。これには、このターゲットの srcs の実行時に使用されるデータファイルやバイナリが含まれる場合があります。データファイルへの依存方法と使用方法の詳細については、データ依存関係のセクションをご覧ください。

新しいルールで実行時に他の入力を使用する可能性のある入力を処理する場合は、data 属性を定義する必要があります。ルールの実装関数は、data 属性の出力と実行ファイルからターゲットのランファイルを取り込む必要があります。また、ソースコードまたはランタイムの依存関係を提供する依存関係属性からの実行ファイルも設定する必要があります。

deps

ラベルのリスト。デフォルトは [] です。

このターゲットの依存関係。通常は、ルール ターゲットのみをリストします。(ルールによっては、ファイルを deps に直接リストすることが許可されているものもありますが、可能であれば避けてください)。

通常、言語固有のルールにより、リストされるターゲットは特定のプロバイダを持つターゲットに限定されます。

deps を使用してターゲットが別のターゲットに依存することの正確な意味は、ルールの種類によって異なります。詳細については、ルール固有のドキュメントをご覧ください。ソースコードを処理するルールの場合、deps は通常、srcs 内のコードで使用されるコード依存関係を指定します。

多くの場合、deps 依存関係は、あるモジュールが同じプログラミング言語で記述された別のモジュールで定義されたシンボルを、個別にコンパイルできるようにするために使用されます。多くの場合、言語間の依存関係も許可されます。たとえば、java_library ターゲットは、cc_library ターゲットの C++ コードに依存できます(後者を deps 属性にリストします)。詳細については、依存関係の定義をご覧ください。

licenses

文字列のリスト。構成不可。デフォルトは ["none"] です。

この特定のターゲットに使用されるライセンス タイプの文字列のリスト。これは、Bazel で使用されなくなったライセンス API の一部です。これは使用しないでください。

srcs

ラベルのリスト。デフォルトは [] です。

このルールで処理または追加したファイル。通常はファイルを直接リストしますが、デフォルトの出力を含めるためにルール ターゲット(filegroupgenrule など)をリストすることもできます。

多くの場合、言語固有のルールでは、リストされるファイルに特定のファイル拡張子を付ける必要があります。

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

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

属性 説明
compatible_with

ラベルのリスト。構成不可。デフォルトは [] です。

デフォルトでサポートされている環境に加えて、このターゲットをビルドできる環境のリスト。

これは Bazel の制約システムの一部であり、ユーザーは相互に依存できるターゲットと依存できないターゲットを宣言できます。たとえば、外部にデプロイ可能なバイナリが、会社秘密のコードを含むライブラリに依存しないようにする必要があります。詳細については、 ConstraintSemantics をご覧ください。

deprecation

文字列、構成不可、デフォルトは None

このターゲットに関連付けられている説明用の警告メッセージ。 通常、これはターゲットが古くなった、ターゲットが別のルールに置き換わった、パッケージに非公開になっている、なんらかの理由で有害とみなされる可能性があることをユーザーに知らせるために使用されます。このメッセージを回避するためにどのような変更が必要かを簡単に把握できるように、ウェブページ、バグ番号、移行 CL の例などの参照を含めることをおすすめします。ドロップイン代替として使用できる新しいターゲットがある場合は、古いターゲットのすべてのユーザーを移行することをおすすめします。

この属性はビルド方法には影響しませんが、ビルドツールの診断出力には影響する可能性があります。deprecation 属性を含むルールが別のパッケージ内のターゲットによって依存されている場合、ビルドツールは警告を発行します。

パッケージ内依存関係はこの警告から除外されます。たとえば、非推奨ルールのテストをビルドしても警告は表示されません。

非推奨のターゲットが別の非推奨のターゲットに依存している場合、警告メッセージは発行されません。

ユーザーが使用を停止したら、ターゲットを削除できます。

distribs

文字列のリスト。構成不可。デフォルトは [] です。

この特定のターゲットに使用される配布方法の文字列のリスト。 これは、Bazel で使用されなくなったライセンス API の一部です。これは使用しないでください。

exec_compatible_with

ラベルのリスト。構成不可。デフォルトは [] です。

このターゲットの実行プラットフォームに存在する必要がある constraint_values のリスト。これは、ルールタイプですでに設定されている制約に加えて適用されます。制約は、使用可能な実行プラットフォームのリストを制限するために使用されます。詳細については、ツールチェーンの解決の説明をご覧ください。

exec_properties

文字列の辞書。デフォルトは {} です。

このターゲットに対して選択されたプラットフォームの exec_properties に追加される文字列のディクショナリ。プラットフォーム ルールの exec_properties をご覧ください。

プラットフォーム プロパティとターゲット レベルのプロパティの両方にキーが存在する場合、値はターゲットから取得されます。

features

feature 文字列のリスト。デフォルトは [] です。

機能とは、ターゲットで有効または無効にできる文字列タグです。特徴の意味はルール自体によって異なります。

この features 属性は、 パッケージ レベルの features 属性と組み合わされます。たとえば、機能 ["a", "b"] がパッケージ レベルで有効になっており、ターゲットの features 属性に ["-a", "c"] が含まれている場合、ルールで有効になる機能は「b」と「c」になります。 例をご覧ください

restricted_to

ラベルのリスト。構成不可。デフォルトは [] です。

デフォルトでサポートされている環境の代わりに、このターゲットをビルドできる環境のリスト。

これは Bazel の制約システムの一部です。詳しくは、compatible_with をご覧ください。

tags

文字列のリスト。構成不可。デフォルトは [] です。

タグはどのルールでも使用できます。テストルールと test_suite ルールのタグは、テストを分類するのに役立ちます。テスト以外のターゲットのタグは、genruleStarlark アクションのサンドボックス化された実行の制御と、人間や外部ツールによる解析に使用されます。

テストまたは genrule ターゲットの tags 属性に次のキーワードが見つかった場合、または Starlark アクションの execution_requirements のキーが検出された場合、Bazel はサンドボックス コードの動作を変更します。

  • no-sandbox キーワードを指定すると、アクションまたはテストがサンドボックス化されなくなります。キャッシュに保存することも、リモートで実行することもできます。no-cache または no-remote を使用して、いずれかまたは両方を防ぎます。
  • no-cache キーワードにより、アクションまたはテストが(ローカルまたはリモートに)キャッシュに保存されなくなります。注: このタグでは、ディスク キャッシュはローカル キャッシュとみなされ、HTTP キャッシュと gRPC キャッシュはリモート キャッシュとみなされます。Skyframe や永続アクション キャッシュなどの他のキャッシュは影響を受けません。
  • no-remote-cache キーワードを指定すると、アクションまたはテストはリモートのキャッシュに保存されません(ただし、ローカルのキャッシュに保存でき、リモートで実行することもできます)。注: このタグでは、ディスク キャッシュはローカル キャッシュとみなされ、HTTP キャッシュと gRPC キャッシュはリモート キャッシュとみなされます。Skyframe や永続アクション キャッシュなどの他のキャッシュは影響を受けません。ローカル ディスク キャッシュとリモート キャッシュを組み合わせて使用する場合(結合キャッシュ)、リモート キャッシュとして処理され、完全に無効になります。ただし、--incompatible_remote_results_ignore_disk が設定されている場合は、ローカル コンポーネントが使用されます。
  • no-remote-exec キーワードを指定すると、アクションまたはテストがリモートで実行されません(ただし、リモートでキャッシュに保存できます)。
  • no-remote キーワードを指定すると、アクションまたはテストがリモートで実行されることや、リモートでキャッシュに保存されることを防止できます。これは、no-remote-cacheno-remote-exec の両方を使用するのと同等です。
  • no-remote-cache-upload キーワードは、スポーンのリモート キャッシュの一部のアップロードを無効にします。リモート実行が無効になることはありません。
  • local キーワードを指定すると、アクションまたはテストがリモート キャッシュに保存されたり、リモートから実行されたり、サンドボックス内で実行されなかったりします。genrules と test では、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 キーワードは、ターゲット パターンのワイルドカード(...:*:all など)と test_suite ルールの拡張からターゲットを除外します。これらのルールは、buildtestcoverage コマンドでビルド/実行するトップレベル ターゲットのセットを計算するときに、テストを明示的にリストしません。query コマンドなどの他のコンテキストにおけるターゲットのワイルドカードやテストスイートの展開には影響しません。manual は、継続的なビルド / テストシステムによりターゲットが自動的にビルドまたは実行されないことを意味しません。たとえば、特定の Bazel フラグを必要とするものの、適切に構成された presubmit または継続的なテスト実行にはターゲットを含めておくため、bazel test ... からターゲットを除外する方が望ましい場合があります。
  • external キーワードは、--cache_test_results の値に関係なく、テストを強制的に無条件に実行します。
テスト ターゲットに付加されるタグの規則について詳しくは、テスト百科事典のタグの規則をご覧ください。
target_compatible_with

ラベルのリスト。デフォルトは [] です。

このターゲットを互換性とみなすためにターゲット プラットフォームに存在する必要がある constraint_value のリスト。これは、ルールタイプですでに設定されている制約に加えて適用されます。ターゲット プラットフォームがリストされた制約をすべて満たしていない場合、ターゲットは「互換性なし」とみなされます。incompatibleターゲット パターンが展開されると、互換性のないターゲットはビルドとテストでスキップされます(//...:all など)。コマンドラインで明示的に指定すると、互換性のないターゲットは Bazel でエラーを出力し、ビルドまたはテストの失敗の原因になります。

互換性のないターゲットに推移的に依存するターゲットは、それ自体は互換性がないと見なされます。また、ビルドとテストではスキップされます。

空のリスト(デフォルト)は、ターゲットがすべてのプラットフォームと互換性があることを示します。

この属性は、ワークスペース ルール以外のすべてのルールでサポートされます。一部のルールでは、この属性は無効になります。たとえば、cc_toolchaintarget_compatible_with を指定しても役に立ちません。

互換性のないターゲットのスキップについて詳しくは、プラットフォーム ページをご覧ください。

testonly

ブール値。構成不可。デフォルトは False です(テストとテストスイートのターゲットを除く)。

True の場合、テスト専用ターゲット(テストなど)のみがこのターゲットに依存できます。

同様に、testonly でないルールは、testonly であるルールに依存できません。

テスト(*_test ルール)とテストスイート(test_suite ルール)はデフォルトで 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

ラベルのリスト。構成不可。デフォルトは、指定されている場合は package から default_visibility、それ以外の場合は "//visibility:private" です。

ターゲットの visibility 属性は、そのターゲットを他のパッケージで使用できるかどうかを制御します。可視性については、ドキュメントをご覧ください。

すべてのテストルールに共通の属性(*_test)

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

属性 説明
args

文字列のリスト。$(location)"Make variable" による置換、Bourne シェルのトークン化が適用されます。デフォルトは [] です。

bazel test の実行時に Bazel がターゲットに渡すコマンドライン引数。

これらの引数は、bazel test コマンドラインで指定された --test_arg 値の前に渡されます。

env

文字列の辞書。値は、$(location)"Make variable" による置換の対象となります。デフォルトは {} です。

bazel test によってテストが実行されるときに設定する追加の環境変数を指定します。

この属性は、cc_testpy_testsh_test などのネイティブ ルールにのみ適用されます。Starlark 定義のテストルールには適用されません。独自の Starlark ルールでは、「env」属性を追加し、それを使用して TestEnvironment プロバイダにデータを入力できます。

env_inherit

文字列のリスト。デフォルトは [] です。

bazel test によってテストが実行されるときに外部環境から継承する追加の環境変数を指定します。

この属性は、cc_testpy_testsh_test などのネイティブ ルールにのみ適用されます。Starlark 定義のテストルールには適用されません。

size

文字列 "enormous""large""medium"、または "small"構成不可。デフォルトは "medium"

テスト ターゲットの「重さ」(実行に必要な時間/リソース)を指定します。

単体テストは「小規模」、統合テストは「中」、エンドツーエンド テストは「大規模」または「巨大」と見なされます。Bazel は、サイズに基づいてデフォルトのタイムアウトを決定します。これは、timeout 属性を使用してオーバーライドできます。タイムアウトは、個々のテストごとではなく、BUILD ターゲット内のすべてのテストに適用されます。テストをローカルで実行する場合、size はスケジューリングのためにも使用されます。Bazel は、--local_{ram,cpu}_resources を尊重し、負荷の高いテストを大量に同時に実行してローカルマシンに負荷をかけることがないようにします。

テストサイズは次のデフォルト タイムアウトに対応しており、ローカル リソースのピーク使用量を想定しています。

サイズ RAM(MB) CPU(CPU コア数) デフォルトのタイムアウト
小さく初めて 20 1 短(1 分)
medium 100 1 中(5 分)
300 1 長め(15 分)
巨大 800 1 eternal(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 に設定すると、「local」をタグ(tags=["local"])として指定した場合と同じ結果になります。

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

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

属性 説明
args

文字列のリスト。$(location)"Make variable" による置換、Bourne シェルのトークン化の対象です。構成不可。デフォルトは [] です。

run コマンドまたはテストの実行時に Bazel がターゲットに渡すコマンドライン引数。これらの引数は、bazel run または bazel test コマンドラインで指定された引数よりも前に渡されます。

注: Bazel の外部でターゲットを実行する場合(bazel-bin/ でバイナリを手動で実行する場合など)は、引数は渡されません。

env

文字列の辞書。値は $(location)"Make variable" 置換の対象です。デフォルトは {} です。

ターゲットが bazel run によって実行されるときに設定する追加の環境変数を指定します。

この属性は、cc_binarypy_binarysh_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 とマークされている属性では、この機能を使用できません。通常、属性は構成できません。これは、select() の解決方法を決定する前に、Bazel が内部でその値を知る必要があるためです。

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

暗黙的な出力ターゲット

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

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

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

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

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