Bazel クエリ リファレンス

外部ソースからの読み取りターゲット: 設定

expr ::= set(word *)

set(a b c ...) 演算子は、ゼロ個以上のターゲット パターンをスペースで区切って結合を計算します（カンマなし）。

Bourne シェルの $(...) 機能と組み合わせて、set() は 1 つのクエリの結果を通常のテキスト ファイルに保存し、他のプログラム（標準の UNIX シェルツールなど）を使用してそのテキスト ファイルを操作し、さらに処理するために値としてクエリ結果にクエリを再開する手段を提供します。次に例を示します。

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

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

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) の省略形ですが、前の awk コマンドなど、cat 以外のシェルコマンドも使用できます。

関数

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) 演算子は、ユニバースセット u の推移的なクロージャ内で、引数セット x の逆依存関係を評価します。

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

rdeps 演算子は、オプションの 3 番目の引数を受け入れます。これは、検索深度の上限を示す整数リテラルです。結果のグラフには、引数セット内のノードから指定された深度までの距離にあるノードのみが含まれます。そのため rdeps(//foo, //common, 1) は、//common に直接依存する //foo の推移的なクロージャに含まれるすべてのノードを評価します。（これらの数値は、minrank 出力形式で示されるランクに対応しています）。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) 演算子は、引数セット x から最大 k 個のターゲットを任意に選択し、それらのターゲットのみを含むセットに評価します。パラメータ 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 は ID 関数を計算します。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 つの引数を受け入れます。1 つはセットの S、もう 1 つはセットの E です。somepath は、S のターゲットから E のターゲットへの任意のパスにあるノードのグラフを返します。allpaths は、S のターゲットから E のターゲットへのすべてのパスにあるノードのグラフを返します。

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

ターゲット種類のフィルタリング: 種類

expr ::= kind(word, expr)

kind(pattern, input) 演算子は、一連のターゲットにフィルタを適用し、想定外の種類のターゲットを破棄します。pattern パラメータは、照合するターゲットの種類を指定します。

以下の表に、BUILD ファイル（パッケージ p 用）で定義されている 4 つのターゲットの種類を示します。

        genrule(
            name = "a",
            srcs = ["a.in"],
            outs = ["a.out"],
            cmd = "...",
        )
      

したがって、kind("cc_.* rule", foo/...) は foo の下にあるすべての cc_library、cc_binary などのルール ターゲットのセットを評価し、kind("source file", deps(//foo)) は //foo ターゲットの依存関係の推移的なクロージャに含まれるすべてのソースファイルのセットに評価します。

pattern 引数の指定は、多くの場合、source file や .*_test などの多くの正規表現がパーサーによって単語と見なされないために必要となります。

package group を照合する場合、:all で終わるターゲットは結果を生成しないことがあります。:all-targets を代わりに使用してください。

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

expr ::= filter(word, expr)

filter(pattern, input) 演算子は一連のターゲットにフィルタを適用し、ラベル（絶対形式）がパターンと一致しないターゲットを破棄します。つまり、入力のサブセットに対して評価を行います。

最初の引数 pattern は、ターゲット名の正規表現を含む単語です。filter 式は、x がセット input のメンバーであり、x のラベル（絶対形式、//foo:bar など）に正規表現 pattern に対する（アンカー）一致が含まれるように、すべてのターゲット x を含むセットとして評価されます。すべてのターゲット名は // で始まるため、^ 正規表現アンカーの代替として使用できます。

この演算子は、多くの場合、intersect 演算子に代わる非常に高速で堅牢なツールです。たとえば、//foo:foo ターゲットのすべての bar 依存関係を表示するには、次のように評価します。

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

ただし、このステートメントでは、bar ツリー内のすべての BUILD ファイルを解析する必要があります。これには低速で、無関係な BUILD ファイル内でエラーが発生しやすくなります。代替策:

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

この場合、最初に //foo 依存関係のセットを計算し、指定されたパターンに一致するターゲット（つまり、//bar を部分文字列として含むターゲット）のみをフィルタリングします。

filter(pattern, expr) 演算子の一般的な用途は、特定のファイルを名前または拡張子でフィルタリングすることです。次に例を示します。

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

//foo の作成に使用されたすべての .cc ファイルのリストが表示されます。

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

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))

linkshared 属性（cc_binary ルールなど）を持つことができる //foo 依存関係をすべて選択し、明示的に 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))

srcs 属性が空の //foo 依存関係の中ですべてのルールを選択します。

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

data 属性に 1 つ以上の値を指定する //foo 依存関係の中で、すべてのルールを選択します（// と : のため、すべてのラベルは 3 文字以上です）。

リスト型属性で特定の value を持つ //foo 依存関係の中ですべてのルールを選択するには、次のコマンドを使用します。

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

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

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

expr ::= visible(expr, expr)

visible(predicate, input) 演算子は、一連のターゲットにフィルタを適用し、必要な公開設定を指定せずにターゲットを破棄します。

最初の引数 predicate は、出力内のすべてのターゲットに表示されるターゲットのセットです。visible 式は、x がセット input のメンバーであり、predicate x のすべてのターゲット y が y が見えるように、すべてのターゲット x を含むセットに評価されます。次に例を示します。

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

パッケージ //bar の中で、公開設定の制限に違反することなく //foo が依存できるすべてのターゲットを選択します。

ラベルタイプ「labels」のルール属性の評価

expr ::= labels(word, expr)

labels(attr_name, inputs)演算子は、セット inputs のルール内で、型が attr_name の「label」または「label のリスト」で指定されたターゲットのセットを返します。

たとえば、labels(srcs, //foo) は、//foo ルールの srcs 属性に表示されるターゲットのセットを返します。inputs セットに srcs 属性を持つルールが複数ある場合、ルールの srcs が返されます。

test_suites を開いてテストする: テスト

expr ::= tests(expr)

tests(x) 演算子はセット x 内のすべてのテストルールのセットを返し、test_suite ルールを参照の個々のテストセットに展開し、tag と size によるフィルタリングを適用します。

デフォルトでは、クエリ評価はすべての test_suite ルールのテスト以外のターゲットを無視します。これは --strict_test_suite オプションでエラーに変更できます。

たとえば、クエリ kind(test, foo:*) は、foo パッケージ内のすべての *_test ルールと test_suite ルールを一覧表示します。すべての結果は（定義上）foo パッケージのメンバーになります。これに対して、クエリ tests(foo:*) は bazel test foo:* によって実行される個々のテストをすべて返します。これには、test_suite ルールを介して直接的または間接的に参照される他のパッケージに属するテストが含まれる場合があります。

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

expr ::= buildfiles(expr)

buildfiles(x) 演算子は、セット x 内の各ターゲットのパッケージを定義するファイルのセットを返します。つまり、各パッケージの BUILD ファイルと、load を介して参照するすべての .bzl ファイルを返します。なお、これはこれらの load されたファイルを含むパッケージの BUILD ファイルも返します。

通常、この演算子は、指定されたターゲットの構築にどのファイルまたはパッケージが必要かを決定する際に使用されます（多くの場合、下記の --output package オプションと組み合わせて使用します）。次に例を示します。

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

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

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

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

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

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) 演算子は、セット x 内の各ターゲットのパッケージを読み込むために必要な一連の Starlark ファイルを返します。つまり、各パッケージの BUILD ファイルから参照されている .bzl ファイルが返されます。

出力形式

bazel query はグラフを生成します。コンテンツ、形式、順序は、bazel query がこのグラフを表示するのに --output コマンドライン オプションで指定します。

Sky Query で実行する場合、順序付けされていない出力と互換性のある出力形式のみが許可されます。具体的には、graph、minrank、maxrank 出力形式は禁止されています。

出力形式の中には、追加オプションを受け入れるものがあります。各出力オプションの名前には、適用する出力形式が接頭辞付きます。そのため、--graph:factored は --output=graph が使用されている場合にのみ適用されます。graph 以外の出力形式が使用されている場合、効果はありません。同様に、--xml:line_numbers は --output=xml が使用されている場合にのみ適用されます。

結果の並べ替え

クエリ式は常にグラフ順序の保存法に従いますが、結果の表現は、依存関係の順序付きまたは順序なしのいずれかで行われます。これは、結果セットのターゲットやクエリの計算方法には影響しません。これは、結果が stdout に出力される方法にのみ影響します。また、依存関係の順序と同等のノードは、アルファベット順に並べられる場合もあれば、そうでない場合もあります。この動作を制御するには、--order_output フラグを使用します。（--[no]order_results フラグは --order_output フラグの機能のサブセットであり、非推奨です）。

このフラグのデフォルト値は auto で、結果は辞書順で出力されます。ただし、somepath(a,b) が使用されている場合、結果は deps の順序で出力されます。

このフラグが no で、--output が build、label、label_kind、location、package、proto、xml のいずれかである場合、出力は任意の順序で出力されます。通常、このオプションは最速のオプションです。ただし、--output が graph、minrank、maxrank のいずれかである場合、これらの形式を使用すると、Bazel は常に依存関係の順序またはランク順に結果を出力します。

このフラグが deps の場合、Bazel はトポロジの順序、すなわち依存関係を出力します。ただし、依存関係の注文で順序付けされていないノードは（一方から他方へのパスがないため）任意の順序で出力できます。

このフラグが full の場合、Bazel はノードを完全に確定的な（合計）順序で出力します。まず、すべてのノードがアルファベット順に並べ替えられます。次に、リスト内の各ノードが、訪問後のノードへの送信エッジを後継ノード順で走査するポストオーダー深度検索の開始として使用されます。最後に、ノードはアクセスされた順序とは逆の順序で出力されます。

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

ビルド時に表示されるターゲットのソース形式を出力します。

--output build

このオプションを使用すると、各ターゲットは、ビルド言語で手書きされたものが表現されます。すべての変数と関数呼び出し（glob、マクロなど）が展開されます。これは、Starlark マクロの効果を確認する際に役立ちます。さらに、有効なルールごとに generator_name や generator_function）の値がレポートされ、有効なルールを生成するために評価されたマクロの名前が付与されます。

出力には BUILD ファイルと同じ構文が使用されますが、有効な BUILD ファイルを生成するとは限りません。

各ターゲットのラベルを出力します

--output label

このオプションでは、結果のグラフの各ターゲットの名前ラベルがトポロジ形式で 1 行に 1 ラベルずつ出力されます（--noorder_results が指定されている場合を除く、結果の順序に関する注意事項）。（トポロジの順序は、グラフノードが後続要素よりも前に出現する順序です）。もちろん、グラフには多くのトポロジの規則的な並び順があります（逆順は 1 つにすぎません）。どの順序が選択されるかは指定されません。

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

注意点: 場合によっては、同じラベルを持つ 2 つの異なるターゲットが存在することがあります。たとえば、sh_binary ルールと唯一の（暗黙的）srcs ファイルは foo.sh と呼ばれることがあります。クエリの結果にこれらのターゲットの両方が含まれている場合、出力（label 形式）に重複があるように表示されます。label_kind 形式を使用すると（後述）、2 つのターゲットは同じ名前ですが、一方のターゲットは sh_binary rule 型で、もう一方は source file 型であるということが明確になります。

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

--output label_kind

label と同様に、この出力形式では、結果のグラフの各ターゲットのラベルがトポロジ形式で出力されますが、ラベルの前にターゲットの kind が付加されます。

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

--output minrank --output maxrank

label と同様に、minrank と maxrank の出力形式では、結果のグラフの各ターゲットのラベルが出力されますが、トポロジ形式では表示されず、ランク番号付きになります。これらは、結果の順序 --[no]order_results フラグの影響を受けません（結果の順序に関する注を参照）。

この形式には 2 つのバリアントがあります。minrank は、ルートノードからそのノードへの最短パスの長さを基準に各ノードをランク付けします。「ルート」ノード（受信エッジのないノード）はランク 0 で、後継はランク 1 のようになります（エッジは通常どおり、ターゲットからその前提条件（依存するターゲット）を指します）。

maxrank は、ルートノードからノードへの最長パスの長さで各ノードをランク付けします。ここでも、「ルート」のランクは 0 であり、他のすべてのノードのランクは、前の全ノードの最大ランクを 1 よりも上回っています。

サイクル内のすべてのノードは同じランクと見なされます。（ほとんどのグラフは非巡回ですが、単にサイクルBUILDに誤ったサイクルが含まれているためです）。

これらの出力形式は、グラフの深さを検出するのに役立ちます。deps(x)、rdeps(x)、または allpaths クエリの結果で使用される場合、ランク番号は x からそのランク内のノードへの最短パス（minrank あり）または最長パス（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」として使用できます。

場所の情報はターゲットの種類によって異なります（kind 演算子を参照してください）。ルールの場合、BUILD ファイル内でのルール宣言の場所が出力されます。ソースファイルの場合、実際のファイルの 1 行目の場所が出力されます。生成されたファイルの場合は、それを生成したルールの場所が出力されます。（このツールには、生成されたファイルの実際の場所を見つけるための十分な情報がありません。ビルドがまだ実行されていない場合は、存在しない可能性があります）。

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

--output package

このオプションは、結果セット内のターゲットが属するすべてのパッケージの名前を出力します。名前は辞書順に並べ替えられます。重複は除外されます。形式的には、これは一連のラベル（パッケージ、ターゲット）からパッケージへの投影です。

外部リポジトリのパッケージは @repo//foo/bar としてフォーマットされ、メイン リポジトリ内のパッケージは foo/bar としてフォーマットされます。

この出力オプションを deps(...) クエリと組み合わせて使用すると、特定のターゲット セットをビルドするためにチェックアウトする必要があるパッケージ セットを検出できます。

結果のグラフを表示します

--output graph

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

この出力形式は、allpaths、deps、rdeps クエリにおいて特に有用です。これらのクエリには、--output label などの線形形式でレンダリングしたとき、簡単に視覚化できる一連のパスが含まれています。

デフォルトでは、グラフは因数形式でレンダリングされます。つまり、トポロジ的に同等のノードは、複数のラベルを持つ単一のノードにマージされます。一般的な結果グラフには繰り返しの多いパターンが含まれているため、グラフがよりコンパクトで読みやすくなります。たとえば、java_library ルールは、同じ genrule で生成された数百の Java ソースファイルに依存している場合があります。因数分解グラフでは、これらのファイルはすべて 1 つのノードで表されます。この動作は、--nograph:factored オプションを使用して無効にできます。

--graph:node_limit n

このオプションでは、出力内のグラフノードのラベル文字列の最大長を指定します。長いラベルは切り捨てられます。-1 に設定すると、切り捨てが無効になります。通常はグラフが出力される因数分解形式により、ノードラベルが非常に長くなる場合があります。GraphViz は、このオプションのデフォルト値である 1, 024 文字を超えるラベルを処理できません。--output=graph を使用していない場合、このオプションは無効です。

--[no]graph:factored

デフォルトでは、上記のとおり、グラフは因数分解形式で表示されます。--nograph:factored を指定すると、因数分解なしでグラフが出力されます。これにより、GraphViz を使用した可視化は実用的ではありませんが、形式がシンプルなほど他のツール（grep など）による処理が容易になります。--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 属性のコンテンツがバックワード依存関係（コンシューマー）であることを認識しなくても、依存関係グラフのトポロジを再構築できます。

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

  <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 属性と、値が --output location によって出力されるターゲットの場所である location 属性が含まれます。

--[no]xml:line_numbers

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

--[no]xml:default_values

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

正規表現

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

外部リポジトリに対するクエリ

ビルドが外部リポジトリ（WORKSPACE ファイルで定義されている）のルールに依存している場合、クエリ結果にはこれらの依存関係が含まれます。たとえば、//foo:bar が //external:some-lib に依存し、//external:some-lib が @other-repo//baz:lib にバインドされている場合、bazel query 'deps(//foo:bar)' は @other-repo//baz:lib と //external:some-lib の両方を依存関係としてリストします。

外部リポジトリ自体はビルドの依存関係ではありません。つまり、上記の例では //external:other-repo は依存関係ではありません。ただし、次のように //external パッケージのメンバーとしてクエリできます。

  # Querying over all members of //external returns the repository.
  bazel query 'kind(http_archive, //external:*)'
  //external:other-repo

  # ...but the repository is not a dependency.
  bazel query 'kind(http_archive, deps(//foo:bar))'
  INFO: Empty results