BazelCon 2024 登録の受け付けを開始しました。

このページは Cloud Translation API によって翻訳されました。

Bazel クエリリファレンス

<ph type="x-smartling-placeholder"></ph> 問題を報告する <ph type="x-smartling-placeholder"></ph> ソースを表示夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

このページは、使用する Bazel クエリ言語のリファレンスマニュアルです。 bazel query を使用してビルドの依存関係を分析する場合。また、 bazel query がサポートする出力形式を示しています。

実際の使用例については、Bazel クエリの使用方法をご覧ください。

その他のクエリリファレンス

読み込み後のフェーズのターゲットグラフで実行される query に加えて、 Bazel には、アクショングラフクエリと構成可能なクエリが含まれています。

アクショングラフのクエリ

アクショングラフのクエリ（aquery）は、分析後の構成済みテーブルで動作するターゲットグラフ。[アクション]、[アーティファクト]、つながります。aquery は、構成済みのターゲットグラフから生成されたアクション/アーティファクトのプロパティ。たとえば、実際のコマンドの実行と、その入力、出力、ニーモニックなどです。

詳細については、aquery リファレンスをご覧ください。

構成可能なクエリ

従来の Bazel クエリは、読み込み後フェーズのターゲットグラフで実行されます。構成の概念やそれに関連する概念はありません。注目すべき点は、 select ステートメントが正しく解決されない代わりに select に対して考えられるすべての解決を返します。ただし、構成可能なクエリ環境 cquery は、構成を適切に処理しますが、では元のクエリの機能が一部しか利用できません。

詳細については、cquery リファレンスをご覧ください。

例

bazel query の用途一般的な例を次に示します。

//foo ツリーが //bar/baz に依存する理由経路を表示する:

somepath(foo/..., //bar/baz:all)

すべての foo テストが依存する C++ ライブラリ foo_bin 標的にできない？

kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))

トークン: 語彙構文

クエリ言語の式は、次の要素で構成されます。トークン:

キーワード（let など）。キーワードは、Google 広告で使用する予約語であり、それぞれ以下で説明します。完全なセットキーワード:
- except
- in
- intersect
- let
- set
- union
語句（「foo/...」など）または「.*test rule」または「//bar/baz:all」。もし文字シーケンスが「引用符で囲まれている」（先頭と末尾は単一引用符 ' または（二重引用符 " で始まります）は単語です。文字シーケンスが引用符で囲まない場合、単語として解析される場合があります。引用符で囲まれていない単語はシーケンスであるアルファベット文字 A ～ Za ～ z（0 ～ 9 の数字）からと特殊文字 */@.-_:$~[]（アスタリスク、スラッシュ、アット、ピリオド、ハイフン、アンダースコア、コロン、ドル記号、チルド、左角かっこ、右角中かっこなど）を使用します。ただし、引用符で囲まれていない単語をハイフン - やアスタリスク * で始めることはできません。相対ターゲット名が先頭にあってもかまいませんが、です。

また、引用符で囲まれていない単語にプラス記号 + や等号を含めることはできません記号 = を付加しますが、これらの文字はターゲット名で使用できます。日時クエリ式を生成するコードを記述する場合、ターゲット名は引用符で囲む必要があります。

Bazel クエリを構築するスクリプトを記述する際は、引用が必要です。ユーザー入力値から抽出できます。
```
 //foo:bar+wiz    # WRONG: scanned as //foo:bar + wiz.
 //foo:bar=wiz    # WRONG: scanned as //foo:bar = wiz.
 "//foo:bar+wiz"  # OK.
 "//foo:bar=wiz"  # OK.
```
この引用は、シェルを実行します。
```
bazel query ' "//foo:bar=wiz" '   # single-quotes for shell, double-quotes for Bazel.
```
キーワードと演算子は、引用符で囲むと通常の単語として扱われます。たとえば、some は、「一部」を含む単語です。foo と「foo」の両方単語です。

ただし、ターゲット名で一重引用符または二重引用符を使用する場合は注意が必要です。日時引用符で囲む場合は、1 種類の引用符（すべて単一引用符またはすべての二重引用符で囲む必要があります）。

Java クエリ文字列の例を以下に示します。
```
  'a"'a'         # WRONG: Error message: unclosed quotation.
  "a'"a"         # WRONG: Error message: unclosed quotation.
  '"a" + 'a''    # WRONG: Error message: unexpected token 'a' after query expression '"a" + '
  "'a' + "a""    # WRONG: Error message: unexpected token 'a' after query expression ''a' + '
  "a'a"          # OK.
  'a"a'          # OK.
  '"a" + "a"'    # OK
  "'a' + 'a'"    # OK
```
この構文は、ほとんどの場合に引用符が不要になるように選択しています。「（異常）".*test rule" の例には引用符が必要です。ピリオドで始まり、スペースが含まれています。"cc_library" の引用符は不要ですが、無害です。
句読点（丸括弧 ()、ピリオド .、カンマ , など）。単語句読点（上記の例外を除く）を含む場合は引用符で囲む必要があります。

引用符で囲まれた単語の外の空白文字は無視されます。

Bazel クエリ言語のコンセプト

Bazel クエリ言語は式の言語です。毎式は部分的に順序付けされたターゲットのセットに評価されます。ターゲットのグラフ（DAG）です。これが唯一の設定します。

集合とグラフは同じデータ型を参照するが、異なることを強調する次のような側面があります。

Set（設定）: ターゲットの部分的な順序は重要ではありません。
グラフ: ターゲットの部分的な順序が重要です。

依存関係グラフのサイクル

ビルドの依存関係グラフは非巡回である必要があります。

クエリ言語で使用されるアルゴリズムは、非巡回グラフですが、周期に対して堅牢です。kubectl のサイクルは指定されておらず、依拠すべきではありません。

暗黙的な依存関係

BUILD ファイルで明示的に定義されているビルド依存関係に加えて、 Bazel は、ルールに暗黙的な依存関係を追加します。暗黙的な依存関係次のように定義できます。

デフォルトでは、bazel query は暗黙的な依存関係を考慮します。クエリの結果を計算するときに使用しますこの動作は、 --[no]implicit_deps オプション。

クエリでは構成が考慮されないため、ツールチェーンが実装は依存関係とはみなされず、必要なツールチェーンタイプがあります。詳しくは、ツールチェーンのドキュメントをご覧ください。

健全性

Bazel クエリ言語式はビルド全体で動作依存関係グラフ。これは、すべての依存関係によって暗黙的にすべての BUILD ファイル内でルール宣言を宣言します。データアナリストがこのグラフはやや抽象的でありビルドのすべてのステップを実行する方法の詳細な説明です。インビルドを実行するには構成も必要になります。構成をセクションをご覧ください。

Bazel クエリ言語で式を評価した結果すべての設定に当てはまるため、厳密には正確ではありません。もしクエリツールを使用して、必要なすべてのソースファイルのセットを計算する場合、実際に必要なものよりも多くのたとえば、クエリツールにはすべてのファイルがメッセージ翻訳のサポートに必要ですが、ビルドでその機能を使用します

グラフの順序の保持

オペレーションの順序は保持されるサブ式から継承されます。これは、これを「部分順序保存の法則」と呼びます。検討すべき事項例: 次のフィールドの推移的クロージングを判断するクエリを発行すると、依存関係が決まっている場合、各依存関係はターゲットに依存関係グラフに従って作成されます。これをフィルタで絞り込んで種類が file で、かつ 推移的部分的な順序関係がターゲットのペアが 1 つもないにもかかわらず、これらのペアは元のグラフで直接接続されています（ビルド依存関係グラフにはファイルファイルのエッジはありません）。

順序はすべての演算子で保持されますが、一部の演算子は set 演算などの順序の制約は導入しないでください。次の式について考えてみましょう。

deps(x) union y

最終的な結果セットの順序は、指定したすべての順序付け制約があります。つまり、 x の推移的依存関係が正しく順序付けられている考えていますただし、このクエリでは、このクエリが y 内のターゲットの順序、 deps(x) 内のターゲットの順序付け y（ y が deps(x) にも含まれている場合）。

順序の制約を導入する演算子には、次のものがあります。 allpaths、deps、rdeps、somepath、ターゲットパターンのワイルドカード package:*、dir/... など

Sky のクエリ

スカイクエリは、指定されたユニバーススコープで動作するクエリのモードです。

SkyQuery でのみ使用できる特別な関数

Sky Query モードには、追加のクエリ関数 allrdeps と rbuildfiles。これらの関数は、インスタンス全体の（そのため通常のクエリでは意味がありません）。

ユニバースのスコープの指定

Sky Query モードは、次の 2 つのフラグを渡すことで有効になります。（--universe_scope または --infer_universe_scope）と --order_output=no。 --universe_scope=<target_pattern1>,...,<target_patternN> はクエリをターゲットパターンで指定されたターゲットパターンの推移的クロージャをプリロードする。加算と減算の両方が行われますすべてのクエリは、この「スコープ」内で評価されます。特に allrdeps と rbuildfiles 演算子は、このスコープからの結果のみを返します。 --infer_universe_scope は --universe_scope の値を推測するよう Bazel に指示しますクエリ式から取得できますこの推定値は、一意のターゲットパターンのリストです。期待する結果が得られない可能性があります。例:

bazel query --infer_universe_scope --order_output=no "allrdeps(//my:target)"

このクエリ式の一意のターゲットパターンのリストは ["//my:target"] であるため、 Bazel では、これを呼び出しと同じように扱います。

bazel query --universe_scope=//my:target --order_output=no "allrdeps(//my:target)"

しかし、--universe_scope を使用したクエリの結果は //my:target のみです。 //my:target の逆依存関係は存在しないため、工事中！一方、

bazel query --infer_universe_scope --order_output=no "tests(//a/... + b/...) intersect allrdeps(siblings(rbuildfiles(my/starlark/file.bzl)))"

これは、テストターゲットの計算を試行する有意義なクエリ呼び出しです。 tests: 一部のディレクトリで、ターゲットを定義で特定の .bzl ファイルを使用しているターゲットに推移的依存します。ここでは、 --infer_universe_scope は、特にそうしないと、--universe_scope を使用してクエリ式を自分で解析する必要があります。

そのため、ユニバーススコープの演算子を使用するクエリ式では、 allrdeps、 rbuildfiles 必ず次を使用してください: --infer_universe_scope は、動作が意図したものである場合にのみ使用します。

Sky Query には、デフォルトクエリと比較すると、いくつかの長所と短所があります。主なデメリットは、出力をグラフの順序に従って並べ替えることができないため、出力形式は禁止されています。この方法の利点は、 2 つの演算子（allrdeps と rbuildfiles）は、デフォルトクエリでは使用できないフィールドです。また Sky Query はデータベース内に存在するスカイフレームグラフ（新規作成は使用しない）デフォルトの実装と同じです。そのため処理が高速になり、メモリの使用量も少なくなります。

式: 文法の構文と意味

Bazel クエリ言語の文法を EBNF 表記で表したものです。

expr ::= word
       | let name = expr in expr
       | (expr)
       | expr intersect expr
       | expr ^ expr
       | expr union expr
       | expr + expr
       | expr except expr
       | expr - expr
       | set(word *)
       | word '(' int | word | expr ... ')'

以降のセクションでは、この文法の各単語について順番に説明します。

ターゲットパターン

expr ::= word

構文的には、ターゲットパターンは単なる単語です。これは（順序付けられていない）ターゲットのセットです。最もシンプルなターゲットパターンはラベルです。単一のターゲット（ファイルまたはルール）を識別します。たとえば、ターゲットパターンは //foo:bar は、1 つの要素（ターゲット、bar）を含むセットとして評価されます適用できます。

ターゲットパターンはラベルを一般化して、パッケージやパッケージにワイルドカードをできます。たとえば、foo/...:all（または単に foo/...）はターゲットパターンです。すべてのパッケージのすべての rules を含むセットを再帰的に評価する foo ディレクトリの下にあります。bar/baz:all は、次を評価するターゲットパターンです。 bar/baz パッケージのルールをすべて含むセットに、構成します。

同様に、foo/...:* は、次の要素を含むセットを評価するターゲットパターンです。すべてのパッケージ内のすべてのターゲット（ルールおよびファイル）が、 foo ディレクトリbar/baz:* は、すべてのターゲットを含むセットとして bar/baz パッケージは必要ですが、サブパッケージは対象外です。

:* ワイルドカードは、ファイルとルールの両方と一致するため、クエリには :all よりも有用です。逆に、:all ワイルドカード（ foo/... などのターゲットパターンなど）を使用する方が、ビルドに有用です。

bazel query ターゲットパターンは、bazel build ビルドターゲットと同じように機能します。詳細については、ターゲットパターンをご覧ください。またはタイプ bazel help target-syntax。

ターゲットパターンは、シングルトンセット（ラベルの場合）として評価できます。多くの要素を含むセット（数千の要素を含む foo/... の場合など）または空のセット（ターゲットパターンがどのターゲットにも一致しない）に割り当てられます。

ターゲットパターン式の結果のすべてのノードが正しく順序付けされている相互関係に基づいて相互に比較します。したがって、 foo:* は、パッケージ foo 内のターゲットのセットだけでなく、それらのターゲットをグラフ化します。（相対的な順序は保証されません）結果ノードを他のノードと比較します）。詳しくは、グラフの順序セクション。

変数

expr ::= let name = expr₁ in expr₂
       | $name

Bazel クエリ言語では、次の要素の定義と参照が可能です。使用します。let 式の評価結果は、次と同じです。 expr₂ の前年比（無料）変数 name は、次の値に置き換えられます。 expr₁.

たとえば、let v = foo/... in allpaths($v, //common) intersect $v は次のようになります。 allpaths(foo/...,//common) intersect foo/... と同等です。

変数参照 name が囲む let name = ... 式はエラーが発生します。つまり、トップレベルのクエリ式に空きスペースを使用します。

上記の文法生成では、name は word に似ていますが、 C プログラミングでは正規の識別子であるという追加の制約があります。変数への参照の先頭には「$」を付ける必要がありますあります。

各 let 式で定義される変数は 1 つだけですが、変数をネストできます。

ターゲットパターンと変数参照はどちらも、次の要素で構成されます。単一のトークン、単語のみであるため、構文のあいまいさが生まれます。ただし、意味のあいまいさがありません。これは、有効な変数である単語のサブセットが、名前は、正式なターゲットパターンである単語のサブセットと重複しません。

厳密に言えば、let 式は増加しません。クエリ言語の表現力。つまり、Google Cloud で表現可能なラベルがなくても言語を表現できます。ただし、多くのクエリの簡潔さが改善されます。また、クエリを効率よく評価できます

かっこで囲まれた式

expr ::= (expr)

括弧はサブ式を関連付けて、評価順序を強制します。かっこで囲まれた式は、その引数の値に評価されます。

代数の集合演算: 積、和、差分集合

expr ::= expr intersect expr
       | expr ^ expr
       | expr union expr
       | expr + expr
       | expr except expr
       | expr - expr

これら 3 つの演算子は、引数に対して通常の集合演算を計算します。各演算子には、intersect などの名詞形式と、シンボリック形式（^ など）。どちらの形式も同等です。シンボリック形式はすばやく入力できます。（わかりやすくするために、このページの残りの部分では名詞形式を使用します）。

次に例を示します。

foo/... except foo/bar/...

foo/... に一致し、foo/bar/... には一致しないターゲットのセットとして評価されます。

次のように同じクエリを作成できます。

foo/... - foo/bar/...

intersect（^）演算と union（+）演算は可換（対称）です。 except（-）は非対称です。パーサーは 3 つの演算子をすべて左結合で優先順位が等しいので、かっこを使うとよいでしょう。対象たとえば、これらの式の最初の 2 つは同じですが、3 番目の式は等価ではありません。

x intersect y union z
(x intersect y) union z
x intersect (y union z)

外部ソースからターゲットを読み取る: set

expr ::= set(word *)

set(a b c ...) 演算子は 0 以上の値の集合の和集合を計算します。ターゲットパターンを空白文字で区切る（カンマなし）。

Bourne シェルの $(...) 機能と組み合わせて、set() を使用すると、クエリの結果を通常のテキストファイルに保存し、他のプログラム（標準の UNIX シェルツールなど）を使用してそのテキストファイルを結果をさらに詳しくクエリするためにあります。例:

bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
bazel query "kind(cc_binary, set($(<foo)))"

次の例では、kind(cc_library, deps(//some_dir/foo:main, 5)) は次のようになります。 awk プログラムを使用して maxrank 値をフィルタリングすることで計算されます。

bazel query 'deps(//some_dir/foo:main)' --output maxrank | awk '($1 < 5) { print $2;} ' > foo
bazel query "kind(cc_library, set($(<foo)))"

これらの例では、$(<foo) は $(cat foo) の省略形ですが、シェル cat 以外のコマンド（前の awk コマンドなど）も使用できます。

関数

expr ::= word '(' int | word | expr ... ')'

クエリ言語では複数の関数が定義されます。関数の名前により、必要な引数の数と型が決まります。次の次の関数が用意されています。

allpaths
attr
buildfiles
rbuildfiles
deps
filter
kind
labels
loadfiles
rdeps
allrdeps
same_pkg_direct_rdeps
siblings
some
somepath
tests
visible

依存関係の推移的クロージャ: 依存関係

expr ::= deps(expr)
       | deps(expr, depth)

deps(x) 演算子は、生成されるグラフの値を求めます。その引数セットの依存関係の推移的クロージャによって x。たとえば、deps(//foo) の値は、単一ノード foo をルートとする依存関係グラフ（そのすべてのノードを含む）確認します。deps(foo/...) の値は、ルートが foo ディレクトリ以下のすべてのパッケージのルールです。ここでは「依存関係」はルールとファイルターゲットのみを意味するため、BUILD とこれらのターゲットの作成に必要な Starlark ファイルは、ここには含まれません。そのため buildfiles 演算子を使用します。

結果のグラフは依存関係に従って並べ替えられます。詳細詳しくは、グラフの順序のセクションをご覧ください。

deps 演算子は、オプションの 2 番目の引数（整数）を受け入れます。検索深度の上限を指定するリテラル。まず deps(foo:*, 0) は foo パッケージ内のすべてのターゲットを返しますが、 deps(foo:*, 1) にはさらに、 foo パッケージ。さらに deps(foo:*, 2) にはノードを直接含めます。 deps(foo:*, 1) のノードから到達可能です。（これらの数字は minrank 出力形式で示されるランクに対応します）。 depth パラメータを省略すると、検索が行われます。制限なし: 前提条件の再帰推移的クロージングを計算します。

逆依存関係の推移的クロージャ: rdeps

expr ::= rdeps(expr, expr)
       | rdeps(expr, expr, depth)

rdeps(u, x) 演算子は引数セットの逆依存関係に評価されます宇宙集合の推移的閉収内の x u。

結果のグラフは依存関係に従って並べ替えられます。詳しくは、（グラフの順序）セクションをご覧ください。

rdeps 演算子は、オプションの 3 番目の引数（整数）を受け入れます。検索深度の上限を指定するリテラル。結果任意の地点から指定された深度の範囲内にあるノードのみがグラフに含まれます。作成します。したがって、rdeps(//foo, //common, 1) はすべてのノードと評価されます //common に直接依存する //foo の推移的クロージャ内。（これらの番号は、minrank の出力に表示されるランクに対応しています。 format.)depth パラメータを省略すると、検索できるようになります

すべての逆依存関係の推移的クロージング: allrdeps

expr ::= allrdeps(expr)
       | allrdeps(expr, depth)

allrdeps 演算子は rdeps と同じように動作します。使用できますが、"ユニバース集合" は--universe_scope フラグを指定します。個別に指定されるのではなく、したがって、 --universe_scope=//foo/... が渡された場合、allrdeps(//bar) は rdeps(//foo/..., //bar) と同等です。

同じパッケージ内の直接逆依存関係: same_pkg_direct_rdeps

expr ::= same_pkg_direct_rdeps(expr)

same_pkg_direct_rdeps(x) 演算子はターゲットの完全なセットを評価します引数セット内のターゲットと同じパッケージにあり、そのターゲットに直接依存するオブジェクトです。

標的のパッケージに対処する：兄弟姉妹

expr ::= siblings(expr)

siblings(x) 演算子は、中にあるすべてのターゲットの引数セット内のターゲットと同じパッケージになります。

任意の選択: 一部

expr ::= some(expr)
       | some(expr, count )

some(x, k) 演算子最大 k 個のターゲットが引数セットとして x を使用し、次の要素を含むセットにターゲットのみに絞りますパラメータ k は省略可能です。見つからない場合、結果は 1 つのターゲットのみを含むシングルトンセットになります自動的に選択されます。引数セット x のサイズが k より小さい場合、引数セット全体 x が返されます。

たとえば、式 some(//foo:main union //bar:baz) は //foo:main または //bar:baz のいずれかを含むシングルトンセットですが、定義します。式 some(//foo:main union //bar:baz, 2) または some(//foo:main union //bar:baz, 3) は //foo:main と //bar:baz。

引数がシングルトンの場合、some 単位関数 some(//foo:main) を計算します。 //foo:main と同等です。

指定された引数セットが空の場合は、式 some(//foo:main intersect //bar:baz)。

パス演算子: somepath、allpaths

expr ::= somepath(expr, expr)
       | allpaths(expr, expr)

somepath(S, E) と allpaths(S, E) 演算子による計算 2 つのターゲットセット間のパスを定義しますどちらのクエリも 2 つの開始点のセット S と開始点のセット目的地の E。somepath は、ターゲットからの任意のパス上のノードのグラフ E のターゲットへの S。allpaths 任意のターゲットからのすべてのパス上のノードのグラフを返します。 E の任意のターゲットに S。

結果のグラフは、依存関係関係に従って並べ替えられます。詳しくは、グラフの順序のセクションをご覧ください。

ターゲットの種類によるフィルタリング: kind

expr ::= kind(word, expr)

kind(pattern, input) 演算子はターゲットのセットにフィルタを適用し、それらのターゲットを破棄します呼び出されることがあります。pattern パラメータは、照合するターゲットの種類を指定します。

たとえば、BUILD ファイルで定義された 4 つのターゲットの種類などです。表に、下に示す（パッケージ p の場合）の例を示します。

コード	ターゲット	種類
genrule( name = "a", srcs = ["a.in"], outs = ["a.out"], cmd = "...", )	`//p:a`	genrule ルール
	`//p:a.in`	ソースファイル
	`//p:a.out`	生成されたファイル
	`//p:BUILD`	ソースファイル

したがって、kind("cc_.* rule", foo/...) は次の集合を評価します。（すべての cc_library、cc_binary など）ルールのターゲットは foo、kind("source file", deps(//foo)) の下です。推移的クロージャ内のすべてのソースファイルの集合と評価します依存関係のリストを //foo します。

pattern 引数の引用符が必須になることが多いこのプロパティを使用しない場合、source file や .*_test などの多くの正規表現は、パーサーで単語と見なされないためです。

package group と照合する場合、末尾が :all では、どの結果も得られない場合があります。代わりに :all-targets を使用してください。

ターゲット名のフィルタリング: filter

expr ::= filter(word, expr)

filter(pattern, input) 演算子は、一連のターゲットにフィルタを適用し、ラベル（絶対形式）がパターンに一致しません。入力のサブセットに評価されます。

最初の引数 pattern は、元の単語にターゲット名に対する正規表現。filter 式すべてのターゲット x を含む集合として、 x は input セットのメンバーであり、ラベル（//foo:bar などの絶対形式） x 件中、（アンカーされていない）一致が含まれています正規表現の「pattern」を使用します。すべてターゲット名が // で始まる場合は、代わりに使用できます。 ^ 正規表現アンカーに追加します。

多くの場合、この演算子を使用すると、より高速かつ堅牢な intersect 演算子。たとえば、すべてのスペースを表示するには、 //foo:foo ターゲットの bar 依存関係。1 個は評価

deps(//foo) intersect //bar/...

ただし、このステートメントでは、BUILD bar ツリー。処理が遅く、エラーが発生しやすくなります。無関係な BUILD ファイル。別の方法として、次のものがあります。

filter(//bar, deps(//foo))

最初に //foo 依存関係のセットを計算し、指定したパターンに一致するターゲットのみをフィルタします。名前に //bar を部分文字列として含むターゲット。

filter(pattern, expr) 演算子のもう一つの一般的な使用方法は、名前または拡張子。次に例を示します。

filter("\.cc$", deps(//foo))

//foo のビルドに使用されたすべての .cc ファイルのリストが提供されます。

ルール属性のフィルタリング: attr

expr ::= attr(word, word, expr)

「 attr(name, pattern, input) 演算子は、指定したターゲットのセットにフィルタを適用し、一致していないターゲットは破棄します。ルール、属性 name がないルールターゲットルールターゲットの属性値が指定されたものと一致しない場合正規表現 pattern;評価する入力のサブセットに出力します。

最初の引数 name は、ルールの名前です。照合する必要があります。正規表現パターンを使用します。2 つ目の引数は、 pattern は属性の正規表現です使用できます。attr 式は、すべてのターゲットを含むセットとして評価されます x のように x がセット input の「メンバー」は、属性 name、属性値に正規表現（アンカーなし）の一致 pattern。name がオプションの属性で、ルールで明示的に指定されていない場合、属性値が比較に使用されます。次に例を示します。

attr(linkshared, 0, deps(//foo))

これにより、//foo の依存関係がすべて選択されます。リンク共有属性（cc_binary ルールなど）を作成し、明示的に 0 に設定するか、値をまったく設定しなくても、デフォルト値は 0 です（ cc_binary ルール）。

リスト型の属性（srcs、data など）は、 [value<sub>1</sub>, ..., value<sub>n</sub>] という形式の文字列に変換されます。 [ かっこで始まり ] かっこで終わるおよび「,」を使用（カンマ、スペース）を使用して複数の値を区切ります。ラベルは、ラベルです。たとえば、属性 deps=[":foo", "//otherpkg:bar", "wiz"] は、文字列 [//thispkg:foo, //otherpkg:bar, //thispkg:wiz]。角かっこは常に存在するため、空のリストでは文字列値 [] が使用されます。照合に使用されます。次に例を示します。

attr("srcs", "\[\]", deps(//foo))

//foo 個の依存関係の中から、 srcs 属性が空ですが、

attr("data", ".{3,}", deps(//foo))

指定した //foo 個の依存関係の中から、すべてのルールが選択されます。 data 属性に少なくとも 1 つの値（すべてのラベルが少なくとも // と : のため 3 文字です）。

特定の value を持つ //foo 依存関係の中からすべてのルールを選択するには、 list-type 属性には、

attr("tags", "[\[ ]value[,\]]", deps(//foo))

これは、value の前の文字が [ またはスペースになり、 value の後の文字はカンマまたは ] になります。

ルールの公開設定のフィルタリング: 表示

expr ::= visible(expr, expr)

visible(predicate, input) 演算子一連のターゲットにフィルタを適用し、可視化します。

最初の引数 predicate は、すべてのターゲット公開する必要があります。visible 式すべてのターゲット x を含む集合として評価され、次の条件に x が一致するセット input のメンバーであり、次のすべてのターゲットで y predicate x は y に公開されます。例:

visible(//foo, //bar:*)

//foo を行うパッケージ //bar 内のすべてのターゲットが選択されます。公開設定の制限に違反せずに利用できる。

ラベルタイプ: ラベルのルール属性の評価

expr ::= labels(word, expr)

labels(attr_name, inputs) 演算子は、指定された一連のターゲットをタイプが「label」の属性 attr_nameまたは「ラベルのリスト」セット inputs 内のルールがあります。

たとえば、labels(srcs, //foo) は次の要素の srcs 属性に出現するターゲット //foo ルールに適用されます。複数のルールがある場合 inputs セットに srcs 属性がある場合、 srcs の和集合が返されます。

test_suites: テストを展開してフィルタする

expr ::= tests(expr)

tests(x) 演算子は、すべてのテストのセットを返します。セット x 内のルール。test_suite ルールをすべてそれらが参照する個々のテストのセット、 tag、size。

デフォルトではすべての test_suite ルール内のテスト以外のターゲットを無視します。これは次のいずれかです。 --strict_test_suite オプションのあるエラーに変わりました。

たとえば、クエリ kind(test, foo:*) は、すべての *_test ルールと test_suite ルール foo パッケージ。すべての結果は foo パッケージのメンバーです。一方クエリ tests(foo:*) を実行すると、 bazel test foo:* によって実行される個々のテスト: これには、他のパッケージに属するテストが含まれる場合があります。直接的または間接的に参照されている test_suite ルールで適用できます。

パッケージ定義ファイル: buildfiles

expr ::= buildfiles(expr)

buildfiles(x) 演算子は集合を返します。各ターゲットのパッケージを定義するファイルが set x;つまり、パッケージごとに、その BUILD ファイル、および load を介して参照する .bzl ファイル。なお、これらを含むパッケージの BUILD ファイルも返します。 load 個のファイル。

この演算子は通常、どのファイルやファイルを特定のターゲットをビルドするには、パッケージを必要に応じて（後述の --output package オプション）。次に例を示します。

bazel query 'buildfiles(deps(//foo))' --output package

//foo が推移的に依存するすべてのパッケージのセットを返します。

警告: Bazel は、Bazel で生成された各 .bzl ファイルのふりをします。load() buildfiles には対応するターゲットがあります（例: ファイル a/b.bzl => target //a:b.bzl など）ですが、必ずしもそうであるとは限りません。したがって、 buildfiles は他のクエリ演算子とうまく組み合わせられず、その結果、誤解を招く表現を --output=xml。

パッケージ定義ファイル: rbuildfiles

expr ::= rbuildfiles(word, ...)

rbuildfiles 演算子は、パスフラグメントのカンマ区切りのリストを受け取り、これらのパスフラグメントに推移的に依存する BUILD ファイルのセット。たとえば //foo がパッケージの場合、rbuildfiles(foo/BUILD) は目標は //foo:BUILD です。foo/BUILD ファイルに load('//bar:file.bzl'... の場合、rbuildfiles(bar/file.bzl) は //foo:BUILD ターゲットと、他の BUILD ファイルのターゲットを返す //bar:file.bzl を読み込む

rbuildfiles 演算子のスコープは、 --universe_scope フラグ。BUILD ファイルと .bzl に直接対応しないファイル結果には影響しません。たとえば、ソースファイル（foo.cc など）は無視されます。（BUILD ファイルに明示的に指定されている場合でも）。ただし、シンボリックリンクは尊重されるため、 foo/BUILD が bar/BUILD へのシンボリックリンクの場合、 rbuildfiles(bar/BUILD) は結果に //foo:BUILD を含めます。

rbuildfiles 演算子は、道徳的には buildfiles 演算子。しかしこの道徳的逆転は一方向への保持が強くなります。rbuildfiles の出力は、 buildfiles の入力。前者の場合は、パッケージ内の BUILD ファイルターゲットのみが含まれます。攻撃者は、そのような標的を含む可能性があります。逆に言えば、対応は弱くなります。「 buildfiles 演算子の出力は、すべてのパッケージと .bzl 必要なファイルのみを取得します。ただし、rbuildfiles 演算子の入力は次のようになります。それらのターゲットではなく、それらのターゲットに対応するパスフラグメントです。

パッケージ定義ファイル: loadfiles

expr ::= loadfiles(expr)

loadfiles(x) 演算子は、次の値のセットを返します。各ターゲットのパッケージを読み込むために必要な Starlark ファイルが x を設定します。つまり、パッケージごとに、 BUILD ファイルから参照される .bzl ファイル。

出力形式

bazel query はグラフを生成します。コンテンツ、形式、並べ替えを bazel query はこのグラフを示しています --output コマンドラインオプションを使用します。

Sky Query で実行する場合、出力が許可されています。具体的には、graph、minrank、および maxrank 出力形式は禁止されています。

一部の出力形式では、追加のオプションを使用できます。名前各出力オプションの先頭には、出力先の出力形式が適用されるため、--graph:factored が適用されるのは、 --output=graph が使用されているとき。サイレントモードの graph 以外の出力形式が使用されている。同様に --xml:line_numbers は --output=xml の場合のみ適用されます。使用されます。

結果の順序

クエリ式は常に「グラフの順序保存（グラフの順序の保全）」、結果の提示順序付けされていない形で指定できます。以下のケースではありません。結果セット内のターゲットやクエリの計算方法に影響します。単に stdout に結果を出力する方法に影響します。さらに、Pod を順序はアルファベット順であっても、そうでないこともあります。この動作は、--order_output フラグを使用して制御できます。（--[no]order_results フラグには、Terraform の機能のサブセットがあります。 --order_output フラグの使用中であり、非推奨です）。

このフラグのデフォルト値は auto で、結果は辞書順で出力されます。 order。ただし、somepath(a,b) を使用すると、結果が deps でご注文ください。

このフラグが no で、--output が次のいずれかである場合 build、label、label_kind、location、package、proto、または xml の場合、出力は任意の順序で出力されます。これは、通常は最短のオプションです。ただし、 --output は、graph、minrank、または maxrank: これらの形式を使用すると、Bazel は常に結果を出力します。並べ替える必要があります。

このフラグが deps の場合、Bazel はなんらかのトポロジ順に結果を出力します。最初に依存関係を作成し、その後に依存関係を作成します。ただし、順序付けされていないノードは、（一方から他方へのパスがないため）依存関係が順序は問いません。

このフラグが full の場合、Bazel は完全に決定論的な（合計）順序でノードを出力します。まず、すべてのノードがアルファベット順に並べ替えられます。次に、リスト内の各ノードが最初のレイヤとして使用されます。アクセスされていないノードへの送信エッジがトラバースされる、ポストオーダー深度優先検索アルファベット順に並べ替えることができます。最後に、ノードは逆の順序で表示されます。特定できます

この順序でノードを出力すると遅くなる可能性があるため、決定論的である場合にのみ使用してください。重要です

BUILD に表示されるターゲットのソースフォームを出力する

--output build

このオプションを使用すると、各ターゲットは BUILD 言語で手書き入力を行いますすべての変数と関数呼び出し（glob、マクロなど）が展開され、その効果を確認するのに便利です。 Starlark のマクロ。また、有効なルールごとに generator_name や generator_function の値）、には、有効なルールを作成するために評価されたマクロの名前を指定します。

出力では BUILD ファイルと同じ構文が使用されますが、有効な BUILD ファイルが生成されます。

各ターゲットのラベルを印刷する

--output label

このオプションでは、各ターゲットの名前（またはラベル）のセット 1 行に 1 つのラベルが出力されます。トポロジの順序（--noorder_results が指定されていない場合は、結果の順序に関する注記をご覧ください）。（トポロジ上の順序とは、グラフを先行するすべてのノードよりも先に表示されます）。もちろんトポロジでは、グラフのトポロジの順序として postorder は 1 つのみ）。どちらを選択するかは指定されません。

somepath クエリの出力を出力する場合、順序はノードが出力される順序は、パスの順序です。

注意：特殊なケースでは、2 つの異なるターゲットが同じラベルを付けます。たとえば、sh_binary ルールとそのルールの唯一の（暗黙的）srcs ファイルの両方を foo.sh。クエリ結果に出力（label 形式）が表示されます。重複を封じ込める必要がありますlabel_kind を使用する場合（参照: 場合、その違いが明確になります。つまり、2 つのターゲットが同じ名前ですが、1 つは種類 sh_binary rule、他の種類 source file。

各ターゲットのラベルと種類を出力する

--output label_kind

label と同様に、この出力形式では、各ターゲットはトポロジ順に並べられますが、さらに、ターゲットの kind をラベルの前に付けます。

ターゲットをプロトコルバッファ形式で出力する

--output proto

クエリ出力を QueryResult プロトコルバッファです。

長さで区切られたプロトコルバッファ形式でターゲットを出力する

--output streamed_proto

出力値長さ区切りストリーム: Target プロトコルバッファです。これは（i）画面を移動する場合に便利です。サイズの制限ターゲットが多すぎて 1 つに収まらない場合のプロトコルバッファ QueryResult または(ii): Bazel が出力されている間に処理を開始します。

テキスト proto 形式でターゲットを出力する

--output textproto

--output proto と同様に、 QueryResult プロトコルバッファですが、テキスト形式。

ターゲットを ndjson 形式で出力する

--output streamed_jsonproto

--output streamed_proto と同様に、次のストリームを出力します。 Target ndjson 形式を使用します。

各ターゲットのラベルをランク順に出力する

--output minrank --output maxrank

label と同様に、minrank および maxrank 出力形式では、それぞれのラベルがグラフに表示されますが、順に表示されます。ランク番号を指定します。これらは結果の順序の影響を受けません --[no]order_results フラグ（結果の順序付け）。

この形式には、minrank ランクの 2 種類があります。各ノードをルートノードからルートノードへの最短経路の長さで割った数値です。 "ルート"ノード（受信エッジがないノード）はランク 0、といった具合です（通常どおり、エッジは前提条件（依存するターゲット）をターゲットとします。

maxrank は、最も長いノードの長さによって各ノードをランク付けします。ルーティングされます。繰り返しになりますがが 0 であり、ノードのランクは、すべてのノードの最大ランクよりも 1 つ大きく左右されます

サイクル内のすべてのノードは等しいランクとみなされます。（ほとんどのグラフは非巡回だがサイクルが発生するこれは、BUILD ファイルに誤ったサイクルが含まれているためです）。

これらの出力形式は、グラフの深さを調べるのに役立ちます。 deps(x)、rdeps(x)、または allpaths クエリの場合、ランク番号は最短（minrank）または最長 x から次のノードへの（maxrank を含む）パス表示されます。maxrank を使用すると、ターゲットのビルドに必要な最も長いビルドステップのシーケンスです。

たとえば、左のグラフの出力は右のようになります。 --output minrank と --output maxrank のとき指定されています。

      minrank

      0 //c:c
      1 //b:b
      1 //a:a
      2 //b:b.cc
      2 //a:a.cc

      maxrank

      0 //c:c
      1 //b:b
      2 //a:a
      2 //b:b.cc
      3 //a:a.cc

各ターゲットの位置を出力する

--output location

label_kind と同様に、このオプションはターゲットの種類とラベルは示されますが、そのターゲットの場所を説明する文字列がファイル名と行番号です形式は、アプリケーションの grep。したがって、後者を解析できるツール（Emacs など）は、または vi）で、クエリ出力を使用して一連のステップをステップ一致するので、Bazel クエリツールを依存関係グラフを認識できる「grep for BUILD ファイル」。

位置情報はターゲットの種類によって異なります（kind 演算子を参照）。ルールについては、 BUILD ファイル内のルールの宣言の場所が出力されます。ソースファイルの場合、実際のファイルの 1 行目の場所は表示されます。生成されたファイルの場合、出力されます。（クエリツールには、生成されたファイルの実際の場所を特定するための情報ビルドがまだ実行されていない場合は、リソースが存在しない可能性があります）。

パッケージのセットを出力する

--output package

このコマンドは、コマンドが出力されるすべてのパッケージの名前が結果セット内のいずれかのターゲットが属していると判断します名前は UDM テーブルに辞書順重複は除外されます形式上、ラベル（package、target）の集合から射影提供します。

外部リポジトリのパッケージは、 @repo//foo/bar になりますが、メインリポジトリのパッケージは foo/bar の形式にします。

deps(...) クエリと組み合わせると、この出力はオプションを使用すると、チェックが必要なパッケージのセットを特定のターゲットを構築します

結果のグラフを表示する

--output graph

このオプションを使用すると、クエリ結果が一般的な AT&T GraphViz 形式で表示できます。通常、結果が .png や .svg などのファイルに保存されます。（dot プログラムがワークステーションにインストールされていない場合、 sudo apt-get install graphviz コマンドを使用してインストールできます）。呼び出し例については、以下のセクションの例をご覧ください。

この出力形式は allpaths の場合に特に便利です。 deps または rdeps のクエリの場合、結果は場合、簡単には可視化できない一連のパスが含まれている --output label などの線形形式でレンダリングされます。

デフォルトでは、グラフは因数分解形式でレンダリングされます。つまりトポロジ上等価のノードが 1 つのノードに複数のラベルを持つノードですこれにより、グラフがコンパクトになります。一般的な結果のグラフにはさまざまな要素が学習します。たとえば、java_library ルールです。ソースコードで生成された数百の Java ソースファイルに同じ genrule;因数分解されたグラフでは単一のノードで表されます。この動作は無効になっている可能性があります --nograph:factored オプションを使用します。

`--graph:node_limit n`

このオプションは、ラベル文字列の最大長をグラフノードが表示されます。長いラベルは切り捨てられます。-1 切り捨てを無効にします。グラフは因数分解された形でノードのラベルが非常に長くなる可能性があります。GraphViz は 1, 024 文字（デフォルト値）を超えるラベルを処理します。指定します。このオプションは --output=graph が使用されています。

`--[no]graph:factored`

デフォルトでは、グラフは因数分解された形式で表示されます。上記をご覧ください。 --nograph:factored を指定すると、グラフは因数分解せずに出力されますこれにより、GraphViz を使用して可視化できます。実用的ではありませんが、シンプルな形式にすると、他のシステムによる処理が使用する必要があります。このオプションは --output=graph が使用されている場合を除きます。

XML

--output xml

このオプションを使用すると、生成されるターゲットが XML に出力されます。フォームに入力します。出力は次のような XML ヘッダーで始まります。

  <?xml version="1.0" encoding="UTF-8"?>
  <query version="2">

その後、ターゲットごとに XML 要素を記述します。トポロジ順に表示されます（ただし、順序付けられていない結果がリクエストされた場合）そして最後のステップで

</query>

file という種類のターゲットに対してシンプルなエントリが出力されます。

  <source-file name='//foo:foo_main.cc' .../>
  <generated-file name='//foo:libfoo.so' .../>

ただし、ルールの場合、XML は構造化されており、すべてのルールの属性（値が定義されていないものを含む）をルールの BUILD ファイルで明示的に指定されます。

また、結果には rule-input と rule-output 要素に変更し、ノードのトポロジが依存関係グラフを知らなくても再構築できます。たとえば、srcs 属性の要素は、（前提条件）と、モジュールの内容を outs 属性は後方依存関係（コンシューマ）です。

次の場合は、暗黙的な依存関係の rule-input 要素が抑制されます。 --noimplicit_deps が指定されている。

  <rule class='cc_binary rule' name='//foo:foo' ...>
    <list name='srcs'>
      <label value='//foo:foo_main.cc'/>
      <label value='//foo:bar.cc'/>
      ...
    </list>
    <list name='deps'>
      <label value='//common:common'/>
      <label value='//collections:collections'/>
      ...
    </list>
    <list name='data'>
      ...
    </list>
    <int name='linkstatic' value='0'/>
    <int name='linkshared' value='0'/>
    <list name='licenses'/>
    <list name='distribs'>
      <distribution value="INTERNAL" />
    </list>
    <rule-input name="//common:common" />
    <rule-input name="//collections:collections" />
    <rule-input name="//foo:foo_main.cc" />
    <rule-input name="//foo:bar.cc" />
    ...
  </rule>

ターゲットのすべての XML 要素に name が含まれる属性（その値がターゲットのラベル） location 属性。その値はターゲットの --output location によって出力される場所です。

`--[no]xml:line_numbers`

デフォルトでは、XML 出力に表示されるロケーションには行番号が含まれます。 --noxml:line_numbers を指定すると、行番号は出力されません。

`--[no]xml:default_values`

デフォルトでは、XML 出力に値を持つルール属性はその種類の属性のデフォルト値です（たとえば、 BUILD ファイルで指定されていないか、デフォルト値が明示的に指定）。このオプションを使用すると、そのような属性値に XML 出力に含まれます。

正規表現

クエリ言語の正規表現では Java 正規表現ライブラリが使用されるため、完全な構文を java.util.regex.Pattern。

外部リポジトリを使用したクエリ

ビルドが外部リポジトリのルールに依存している場合これらの依存関係がクエリ結果に含まれます対象たとえば、//foo:bar が @other-repo//baz:lib に依存している場合、次のようになります。 bazel query 'deps(//foo:bar)' は @other-repo//baz:lib を学びます。