Bazel クエリ リファレンス

<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 広告で使用する予約語であり、 それぞれ以下で説明します。完全なセット キーワード:

  • 単語(「foo/...」など)または「.*test rule」または「//bar/baz:all」。もし 文字シーケンスが「引用符で囲まれている」(先頭と末尾は単一引用符 ' または (二重引用符 " で始まります)は単語です。文字シーケンスが 引用符で囲まない場合、単語として解析される場合があります。引用符で囲まれていない単語はシーケンスである アルファベット文字 A ~ Za ~ z(0 ~ 9 の数字)から と特殊文字 */@.-_:$~[](アスタリスク、スラッシュ、アット、ピリオド、 ハイフン、アンダースコア、コロン、ドル記号、チルド、左角かっこ、右角 中かっこなど)を使用します。ただし、引用符で囲まれていない単語をハイフン - やアスタリスク * で始めることはできません。 相対 [ターゲット名][(/concepts/labels#target-names)] が です。

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

    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 は、ルールに暗黙的な依存関係を追加します。たとえば Java ルールは暗黙的に JavaBuilder に依存します。暗黙的な依存関係 $ で始まる属性を使用して確立され、 BUILD ファイルでオーバーライドできません。

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

健全性

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

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

グラフの順序の保持

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

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

deps(x) union y

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

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

Sky のクエリ

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

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

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

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

Sky Query モードは、次の 2 つのフラグを渡すことで有効になります。 (--universe_scope または --infer_universe_scope)と --order_output=no--universe_scope=<target_pattern1>,...,<target_patternN> はクエリを ターゲット パターンで指定されたターゲット パターンの推移的クロージャをプリロードする。 加算と減算の両方が行われますすべてのクエリは、この「スコープ」内で評価されます。特に allrdepsrbuildfiles 演算子は、このスコープからの結果のみを返します。 --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 を使用してクエリ式を自分で解析する必要があります。

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

Sky Query には、デフォルト クエリと比較すると、いくつかの長所と短所があります。主な デメリットは、出力をグラフの順序に従って並べ替えることができないため、 出力形式は禁止されています。この方法の利点は、 2 つの演算子(allrdepsrbuildfiles)は、デフォルト クエリでは使用できないフィールドです。 また 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 = expr1 in expr2
       | $name

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

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

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

上記の文法生成では、nameword に似ていますが、 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 ... ')'

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

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

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 と開始点のセット 目的地の Esomepath は、 ターゲットからの任意のパス上のノードのグラフ E のターゲットへの Sallpaths 任意のターゲットからのすべてのパス上のノードのグラフを返します。 E の任意のターゲットに S

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

<ph type="x-smartling-placeholder">
</ph> サムパス
somepath(S1 + S2, E)、1 件の結果
<ph type="x-smartling-placeholder">
</ph> サムパス
somepath(S1 + S2, E)、他に考えられる結果です。
すべてのパス
allpaths(S1 + S2, E)

ターゲットの種類によるフィルタリング: 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_librarycc_binary など) ルールのターゲットは fookind("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 を含む集合として、 xinput セットのメンバーであり、 ラベル(//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、属性値に 正規表現(アンカーなし)の一致 patternname が オプションの属性で、ルールで明示的に指定されていない場合、 属性値が比較に使用されます。次に例を示します。

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

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

リスト型の属性(srcsdata など)は、 [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 xy に公開されます。例:

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 ルールをすべて それらが参照する個々のテストのセット、 tagsize

デフォルトでは すべての 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 が推移的に依存するすべてのパッケージのセットを返します。

パッケージ定義ファイル: 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/BUILDbar/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 で実行する場合、 出力が許可されています。具体的には、graphminrank、および 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 が次のいずれかである場合 buildlabellabel_kindlocationpackageproto、または xml の場合、出力は任意の順序で出力されます。これは、 通常は最短のオプションです。ただし、 --output は、graphminrank、または maxrank: これらの形式を使用すると、Bazel は常に結果を出力します。 並べ替える必要があります。

このフラグが deps の場合、Bazel はなんらかのトポロジ順に結果を出力します。 見ていきましょう。ただし、依存関係の順序によって順序付けられていないノードは、 (どちらにもパスがないため)任意の順序で出力できます。

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

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

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

--output build

このオプションを使用すると、各ターゲットは BUILD 言語で手書き入力を行いますすべての変数と関数呼び出し (glob、マクロなど)が展開され、その効果を確認するのに便利です。 Starlark のマクロ。また、有効なルールごとに generator_namegenerator_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 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-inputrule-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

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

ビルドが外部リポジトリ( 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