一般ルール

問題を報告 ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

ルール

エイリアス

ルールのソースを表示
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

alias ルールは、ルールの別名を作成します。

エイリアス化は「regular」できます。具体的には、package_group test_suite にはエイリアスを設定できません。

エイリアスの設定は、大規模なリポジトリで、ターゲットの名前の変更に 変更されます。また、エイリアス ルールを使用して、 select 関数呼び出しを行うと、そのロジックを 複数のターゲットにできます。

エイリアス ルールには独自の公開設定宣言があります。その他すべての点では、 (たとえば、エイリアスの testonly は無視されます。また、testonly-ness が代わりに使用されます)。ただし、次のような例外があります。

  • コマンドラインにエイリアスが指定されている場合、テストは実行されません。エイリアスを定義するには 機能する場合は、test_suite を使用してください。 tests に単一のターゲットがあるルール 属性です。
  • 環境グループを定義する場合、environment ルールのエイリアスは サポートされません。--target_environment コマンドラインではサポートされていません。 いずれかを選択できます

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

引数

属性
name

名前:必須

このターゲットの一意の名前。

actual

ラベル:必須

このエイリアスが参照するターゲット。ルールである必要はなく、入力として使用することもできます。 表示されます。

config_setting

ルールのソースを表示
config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

以下の目的のための想定される構成状態(ビルドフラグまたはプラットフォームの制約)と一致している。 トリガーすることが目的ですselect: このルールの使用方法と、<ph type="x-smartling-placeholder"></ph> 構成可能な属性: 一般的な機能の概要をご覧ください。

以下は、--compilation_mode=opt または -c opt(コマンドラインで明示的に、または .bazelrc ファイルから暗黙的に):

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

以下は、ARM をターゲットとし、カスタム定義を適用するビルドに一致します。 FOO=bar(例: bazel build --cpu=arm --define FOO=bar ...):

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

以下は、 ユーザー定義のフラグ --//custom_flags:foo=1(コマンドラインで明示的に、または .bazelrc ファイル):

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

以下は、x86_64 アーキテクチャのプラットフォームと glibc をターゲットとするビルドと一致します。 バージョン 2.25(ラベル付きの constraint_value の存在を前提) //example:glibc_2_25。なお、プラットフォームは、 使用できます。

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  
いずれの場合も、ビルド内で構成を変更できます。たとえば、 ターゲットをその依存関係とは異なるプラットフォームにビルドする必要がある。つまり、たとえ config_setting はトップレベルのコマンドライン フラグと一致しません。一致する可能性はあります。 いくつかのビルド ターゲットを作成します。

メモ

  • 複数のケースが同時に実行された場合の動作については、select をご覧ください。 config_setting が現在の構成状態と一致する。
  • 省略形をサポートするフラグの場合(例: --compilation_mode-c)、values の定義では完全な形式を使用する必要があります。これらは自動的に 呼び出しを照合できます。
  • フラグが複数の値を取る場合(--copt=-Da --copt=-Db や list-type など)は、 Starlark フラグなど)、values = { "flag": "a" } は、"a" が次の場合に一致します。 実際のリストのどこかに出現する。

    values = { "myflag": "a,b" } も同じように動作します。これは次と一致します。 --myflag=a --myflag=b--myflag=a --myflag=b --myflag=c--myflag=a,b--myflag=c,b,a。正確なセマンティクスは、 使用できます。たとえば、--copt同じ インスタンス: --copt=a,b["a,b"] を生成し、--copt=a --copt=b["a", "b"] を生成します(つまり、values = { "copt": "a,b" } 前者には一致しますが後者には一致しません)。ただし、--ios_multi_cpus(Apple のルールの場合) 必要な場合: -ios_multi_cpus=a,bios_multi_cpus=a --ios_multi_cpus=b はどちらも ["a", "b"] を生成します。フラグの定義を確認し、 状況を正確に把握する必要があります。

  • 組み込みのビルドフラグでモデル化されない条件を定義する必要がある場合は、次のコマンドを使用します。 Starlark で定義されたフラグ--define も使用できますが、メリットは少なくなります サポートされないため、推奨されません。詳しくは、 こちらをご覧ください。
  • 異なるパッケージで同じ config_setting 定義を繰り返さないでください。 代わりに、正規パッケージで定義された共通の config_setting を参照してください。
  • values define_valuesconstraint_values 同じ config_setting の任意の組み合わせで使用できますが、少なくとも 1 つは使用する必要があります 特定の config_setting に対して設定することもできます。

引数

属性
name

名前:必須

このターゲットの一意の名前。

constraint_values

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

ターゲット プラットフォームが指定する必要がある constraint_values の最小セット この config_setting に一致する必要があります。(実行プラットフォームは、 考慮する必要はありません)。プラットフォームに設定されている追加の制約値は無視されます。詳しくは、 構成可能なビルド属性をご覧ください。

同じ select で 2 つの config_setting が一致し、一方に 他と同じフラグと constraint_setting に加えて、追加のフラグも 設定数が多いものが選択されますこれは「スペシャライゼーション」と呼ばれます。たとえば x86Linux に一致する config_setting が特化 x86 に一致する config_setting

2 つの config_setting が一致し、両方に constraint_value がある場合 存在しない場合、これはエラーです。

define_values

辞書: 文字列 ->String;設定不可デフォルトは {} です

values と同じですが、 特に --define フラグで使用します。

--define は特殊な構文(--define KEY=VAL)です。 Bazel フラグの観点から KEY=VALであることを意味します。

つまり、次のようになります。

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

同じキー(define)が 使用します。この属性はこの問題を解決します。

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

bazel build //foo --define a=1 --define b=2 と正しく一致します。

--define は引き続き次の場所に表示されます: 通常のフラグ構文の values。 ディクショナリのキーが一意である限り、この属性と自由に組み合わせることができます。

flag_values

辞書: label ->String;構成不可デフォルトは {}

values と同じですが、 () ユーザー定義のビルドフラグ

ユーザー定義のフラグはラベルとして参照されますが、 組み込みフラグは任意の文字列として参照されます。

values

辞書: 文字列 ->String;設定不可デフォルトは {} です

このルールに一致する構成値のセット(ビルドフラグとして表される)

このルールは、構成済みのターゲットの構成を select ステートメントで参照している。これは、 「一致」Bazel 呼び出しとは、ディクショナリ内のすべてのエントリで、 エントリの期待値と一致しているかどうかを確認します。たとえば values = {"compilation_mode": "opt"} は、次の呼び出しと一致します。 bazel build --compilation_mode=opt ... と ターゲット構成のルールに対する bazel build -c opt ...

便宜上、構成値はビルドフラグとして指定します( 先行する "--")。ただし、この 2 つは同じではないことに注意してください。この なぜなら、同じターゲット内で複数の構成でターゲットを構築できるからです。 構築できます。たとえば、exec 構成の "cpu"次の値と一致: --cpu ではなく --host_cpu。異なる複数のインスタンス間で 同じ config_setting でも、同じ呼び出しに対して異なる動作をする場合がある ルールの構成に応じて異なります。

コマンドラインでフラグが明示的に設定されていない場合は、そのデフォルト値が使用されます。 辞書でキーが複数回出現する場合、最後のインスタンスのみが使用されます。 コマンドラインで複数回設定できるフラグをキーが参照している場合(例: bazel build --copt=foo --copt=bar --copt=baz ...)、次の場合に一致が発生します。 いずれかの設定が一致している必要があります。

ファイルグループ

ルールのソースを表示
filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

filegroup を使用して、一連のターゲットの出力を 1 つの 指定します。

filegroup は、コマンドラインまたは 。これは、ターゲットにはそのルール以外にも多数のプロパティがあり、 同じ方法で収集されない出力です。ただし、それでもかなりの 一部のケース(genrule の srcs 属性など)または *_binary ルールの data 属性です。

ディレクトリを直接参照するのではなく、filegroup を使用することをおすすめします。 後者は、ビルドシステムがすべてのファイルを完全に把握しているわけではないため、問題はありません。 ため、これらのファイルが変更されても再ビルドされない可能性があります。組み合わせた場合: globfilegroup により、すべてのファイルが 明示的に認識されるようにすることもできます。

2 つのソースファイルで構成される filegroup を作成する手順は次のとおりです。

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "//a/library:target",
        "//a/binary:target",
    ],
)

または、glob を使用して testdata ディレクトリを掘り下げます。

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

これらの定義を利用するには、任意のルールのラベルで filegroup を参照します。

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

引数

属性
name

名前:必須

このターゲットの一意の名前。

srcs

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

ファイル グループのメンバーであるターゲットのリスト。

glob 式の結果は、次の場合に使用するのが一般的です。 srcs 属性の値。

data

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

実行時にこのルールで必要なファイルのリスト。

data 属性で指定されたターゲットは、 この filegroup 個のルールの runfiles。リリースを filegroup は、次の data 属性で参照されています: 別のルールの runfilesrunfiles に追加されます 表示されます。データの依存関係を確認する セクションと一般的なドキュメント data をご覧ください。

output_group

String;デフォルトは "" です。

ソースからアーティファクトを収集する出力グループ。この属性が「 指定した場合、依存関係の指定した出力グループのアーティファクトがエクスポートされます 出力グループを作成します

「出力グループ」ターゲットの出力アーティファクトのカテゴリで、 適用できます。

genquery

ルールのソースを表示
genquery(name, deps, data, compatible_with, compressed_output, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery() は、指定されたクエリを実行します。 Bazel クエリ言語: 結果をダンプします 必要があります。

ビルドの整合性を保つため、クエリは scope で指定されたターゲットの推移的クロージャ 属性です。このルールに違反するクエリは、次の場合は実行中に失敗します。 strict が未指定または true(strict が false の場合、 対象外のターゲットは単にスキップされ、警告が表示されます)。「 これを防ぐ最も簡単な方法は、同じラベルを クエリ式のようにスコープ内で指定します。

ここで使用できるクエリとコマンドで許可されているクエリの唯一の違いは、 ワイルドカードのターゲット指定を含むクエリです(例: //pkg:*//pkg:all など)は使用できません。 これには 2 つの理由があります。1 つ目は、genquery が の推移的クロージャの範囲に収まらないターゲットを防止するスコープを指定します。 出力に影響を与えます。2 つ目は、BUILD ファイルが ワイルドカードの依存関係はサポートされていない(例: deps=["//a/..."]) は許可されていません)。

genquery の出力は、決定論的な出力を適用するために辞書順に並べ替えられます。 --output=graph|minrank|maxrank または somepath の場合を除きます。 がトップレベル関数として使用されます。

出力ファイルの名前はルールの名前です。

この例では、ラベルのリストを 適用できます。

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

引数

属性
name

名前:必須

このターゲットの一意の名前。

compressed_output

ブール値デフォルトは False です。

True の場合、クエリ出力は GZIP ファイル形式で書き込まれます。この設定は を使用して、クエリ出力が大きいことが予想される場合に Bazel のメモリ使用量が急増しないようにします。Bazel 220 バイトを超えるクエリ出力がすでに内部で圧縮されている True に設定すると、保持率が減少しない可能性があります。 表示されます。ただし、これにより、Bazel は出力ファイルを書き込むときに解凍をスキップできます。 メモリを大量に消費する可能性があります
expression

String;必須

実行されるクエリ。コマンドラインなどの BUILD ファイル内とは対照的に、 このラベルは、ワークスペースのルート ディレクトリを基準として相対的に解決されます。たとえば、 ファイル a/BUILD のこの属性の :b ラベルが参照するのは、 目標は //:b です。
opts

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

クエリエンジンに渡されるオプション。これらはコマンドライン モジュールの bazel query に渡すことができるオプション。一部のクエリ オプションは使用できません ここに: --keep_going--query_file--universe_scope--order_results--order_output。ここで指定されていないオプション bazel query のコマンドラインと同様に、デフォルト値が設定されます。
scope

ラベルのリスト。必須

クエリの範囲。クエリで推移的以外のターゲットをタップすることはできません 標的の締めくくりに利用すべきだと考えました。
strict

ブール値デフォルトは True です。

true の場合、クエリがスコープの推移的クロージャをエスケープするターゲットは、 構築できます。false の場合、Bazel は警告を出力し、外部に送られるクエリパスをすべてスキップします。 クエリの残りの部分を完了します。

Genrule

ルールのソースを表示
genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

genrule は、ユーザー定義の Bash コマンドを使用して 1 つ以上のファイルを生成します。

genrule は、タスクに特定のルールがない場合に使用できる汎用のビルドルールです。 たとえば、Bash のワンライナーを実行できます。ただし、C++ ファイルをコンパイルする必要がある場合は、 手間のかかる処理がすべて完了しているため、既存の cc_* ルールに適用することができます。 できます。

なお、genrule にはコマンド引数を解釈するためのシェルが必要です。 PATH 上の任意の番組を簡単に参照できますが、これによって 非密閉型のコマンドであり、再現できない可能性があります。 1 つのツールのみを実行する必要がある場合は、 run_binary してください。

他のアクションと同様に、genrules によって作成されたアクションも、 作業ディレクトリです。すべての Bazel 保証は、宣言された入力を $(location) がラベルに対して返すパス。たとえば、アクションが リモート実行の場合、サンドボックスまたはリモート実行の環境によって 作成されます。standalone 戦略を使用して直接実行した場合、 ディレクトリが実行ルート、つまり bazel info execution_root の結果になります。

テストの実行に genrule を使用しないでください。テストとテストには特別な給与が (キャッシュ ポリシーや環境変数など)の結果を確認できます。通常はテストを実行する必要があり genrules はビルド完了後にターゲット アーキテクチャで実行されるのに対し、genrules はビルド完了後に実行される ビルドと exec アーキテクチャです(この 2 つは異なる場合があります)。一般的なユースケースで sh_test を使用します。

クロスコンパイルの考慮事項

詳しくは、ユーザー マニュアルをご覧ください。 役立ちます。

genrule はビルド中に実行されますが、その出力は多くの場合、デプロイや 説明します。マイクロコントローラの C コードをコンパイルする例を考えてみましょう。コンパイラは C 言語を受け入れます。 マイクロコントローラで実行されるコードを生成できます。生成されたコードは そのビルドに使用された CPU では実行できないが、C コンパイラ(ソースからコンパイルされた場合)は 構成する必要があります

ビルドシステムは exec 構成を使ってビルドを実行するマシンを記述する ビルドの出力先のマシンを記述するためのターゲット構成 指定します。それぞれを構成するオプションが用意されており、 競合を避けるために、対応するファイルを別々のディレクトリに保存してください。

genrules では、依存関係が適切にビルドされていることがビルドシステムによって確認されます。 (必要に応じて)ターゲット構成用に srcs がビルドされます。 toolsexec 構成用にビルドされ、出力は target 構成のものである必要があります。また、 「つくる」genrule コマンドが対応するツールに渡すことができる変数があります。

genrule で deps 属性を定義しないのは意図的なことです。他の組み込みルールでは、 ルール間で渡される言語依存のメタ情報で、インフラストラクチャの ただし、genrules ではこのレベルの自動化はできません。genrule の仕組み 実行されています。

特殊なケース

Exec-exec コンパイル: 場合によっては、ビルドシステムで genrules を実行し、 出力はビルド中にも実行できます。たとえば、genrule がカスタム コンパイラを そのモデルを別の genrule で使用します。1 番目は元のルールに対して exec 構成を指定しません。他方の genrule でコンパイラが実行されるからです。この例では ビルドシステムは正しい処理を自動的に行います。つまり、srcs がビルドされ、 ターゲットではなく exec 構成の最初の genrule の outs できます。詳しくは、ユーザー マニュアルをご覧ください。

JDK とC++ ツール: JDK または C++ コンパイラ スイートのツールを使用するには、ビルドシステム 使用する変数のセットを提供します。「メーカー」変数 表示されます。

Genrule 環境

genrule コマンドは Bash シェルで実行されます。このシェルは、コマンドが失敗したときに失敗するように構成されています。 パイプラインが失敗した場合に set -e -o pipefail を使用します。

ビルドツールは、サニタイズされたプロセス環境で Bash コマンドを実行し、 PATHPWDTMPDIRなど ビルドの再現性を確保するため、ほとんどの変数はユーザーのシェル genrule のコマンドには渡されません。ただし、Bazel は Blaze など)は、ユーザーの PATH 環境変数の値を渡します。 PATH の値を変更すると、Bazel はコマンドを再実行します。 利用可能になります。

genrule コマンドでは、プロセスの接続に使用すること以外は、ネットワーク 子が存在しますが、現在は適用されていません。

ビルドシステムは既存の出力ファイルを自動的に削除するが、必要な親ファイルは作成する ルールを実行する前にディレクトリを 作成する必要があります障害が発生した場合は、出力ファイルも削除されます。

一般的なアドバイス

  • genrule によって実行されるツールが決定的かつ密閉型であることを確認してください。書くべき内容ではなく、 タイムスタンプを出力に付ける必要があります。また、セットとマップには安定した順序を使用します。また、 出力への相対ファイルパスのみを書き込み、絶対パスは書き込みません。このルールに従わない場合、 予期しないビルド動作が発生する(Bazel が予想した genrule を再構築しない)原因となり、 キャッシュのパフォーマンスが低下します
  • 出力、ツール、ソースに $(location) を幅広く使用します。これは、 出力ファイルを分離できるため、genrules はハードコードされた 指定することもできます。
  • 同一または非常に類似した genrule が Google Cloud で使用される場合に備えて、 複数の場所に存在します。genrule が複雑な場合は、スクリプトまたは Starlark ルール。これにより、可読性とテスト性が向上します。
  • 終了コードが正しく genrule の成功または失敗を示していることを確認してください。
  • stdout または stderr に情報メッセージを書き込まないでください。これはデバッグには役立ちますが、 ノイズになりやすいgenrule がサイレントになる必要があります。一方、genrule が失敗する 適切なエラー メッセージが出力されます。
  • $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x)
  • シンボリック リンクとディレクトリを作成しないようにします。Bazel がディレクトリ/シンボリック リンクをコピーしない genrules によって作成され、そのディレクトリの依存関係チェックは正常ではありません。
  • 他のルールで genrule を参照する場合は、genrule のラベルまたは 各出力ファイルのラベルです。1 つのアプローチの方が読みやすいこともあれば、 その他: 使用ルールの srcs で出力を名前で参照することで回避 Genrule の他の出力を意図せず取得しますが、genrule が 多数の出力が生成されます。

この例では、foo.h を生成します。このコマンドは何も渡さないため、ソースは できます。「バイナリ」genrule と同じパッケージ内の perl スクリプトです。

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

次の例は、filegroup と別の genrule の出力です。代わりに $(SRCS) を使用すると、 明示的な $(location) ディレクティブも使用できます。この例では後者を使用して 見てみましょう。

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

引数

属性
name

名前:必須

このターゲットの一意の名前。


このルールは、 他の BUILDsrcs または deps セクション できます。ルールによってソースファイルが生成される場合は、 srcs 属性。
srcs

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

このルールの入力のリスト(処理するソースファイルなど)。

この属性は、cmd によって実行されるツールのリスト表示には適していません。 tools 属性を使用してください。

ビルドシステムでは、genrule を実行する前にこれらの前提条件が確実にビルドされる command;元のビルド リクエストと同じ構成を使用してビルドされる。「 これらの前提条件のファイルの名前が、コマンドに $(SRCS) のスペース区切りリスト個々のエンティティへの srcs のターゲット //x:y は、$(location //x:y) を使用するか、それが唯一のエントリである場合は $< を使用して取得できます。 srcs

outs

ファイル名のリスト構成不可必須

このルールによって生成されたファイルのリスト。

出力ファイルはパッケージの境界を越えてはいけません。 出力ファイル名はパッケージからの相対名として解釈されます。

executable フラグが設定されている場合、outs には 1 つだけ含める必要があります 指定します。

genrule コマンドでは、各出力ファイルを所定の場所に作成する必要があります。 ロケーションは、genrule 固有の「Make」を使用して cmd で使用できます。 変数$@$(OUTS)$(@D) $(RULEDIR))を指定するか、 $(location) の置換。

cmd

String;デフォルトは "" です。

実行するコマンド。 $(location) 「Make」を条件とするあります。
  1. 最初の $(location) 置換が適用され、$(location label)$(locations label)(および同様のもの)がすべて置き換えられます 関連する変数 execpathexecpathsrootpathrootpaths など)。
  2. 次に、[つくる]変数が展開されています。注: 事前定義された変数 $(JAVA)$(JAVAC)$(JAVABASE)exec 構成の下に展開されるため、Java の呼び出しは 実行されるコンテナが、共有ライブラリやその他のビルド機能を正しく 確認します。
  3. 最後に、Bash シェルを使用してコマンドが実行されます。終了コードが コマンドが失敗したとみなされます。
これは cmd_bashcmd_pscmd_bat のフォールバックです。 いずれも該当しない場合は必須です。

コマンドラインの長さがプラットフォームの上限(Linux/macOS では 64 K、Windows では 8 K)を超える場合、 genrule はコマンドをスクリプトに記述し、そのスクリプトを実行して問題を回避します。この すべての cmd 属性(cmdcmd_bashcmd_pscmd_bat など)。

cmd_bash

String;デフォルトは "" です。

実行する Bash コマンド。

この属性の優先度は cmd よりも高くなります。コマンドが展開され、 cmd 属性とまったく同じように実行されます。

cmd_bat

String;デフォルトは "" です。

Windows で実行する Batch コマンド。

この属性の優先度は cmd および cmd_bash よりも高くなります。 このコマンドは cmd 属性と同様に実行されますが、 次のような違いがあります。

  • この属性は Windows にのみ適用されます。
  • このコマンドは、次のデフォルト引数を指定して cmd.exe /c で実行されます。
    • /S - 最初と最後の引用符を削除し、その他はすべてそのまま実行します。
    • /E:ON - 拡張コマンドセットを有効にします。
    • /V:ON - 遅延変数の展開を有効にする
    • /D - AutoRun のレジストリ エントリを無視します。
  • $(location) の後と、 「メーカー」場合、パスは元の変数に Windows スタイルのパスに展開されます(バックスラッシュ付き)。
cmd_ps

String;デフォルトは "" です。

Windows で実行する Powershell コマンド。

この属性の優先度は、cmdcmd_bash、および cmd_bat。このコマンドは、cmd と同様の方法で実行されます。 属性には以下の点が異なります。

  • この属性は Windows にのみ適用されます。
  • このコマンドは powershell.exe /c で実行されます。

Powershell をより使いやすく、エラーが発生しにくくするために、次のコマンドを実行します。 genrule で Powershell コマンドを実行する前に、環境をセットアップする必要があります。

  • Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - 実行を許可 使用しないでください。
  • $errorActionPreference='Stop' - 複数のコマンドがある場合 を ; で区切って指定すると、Powershell の CmdLet が失敗した場合、アクションはすぐに終了します。 これは外部コマンドでは機能しません
  • $PSDefaultParameterValues['*:Encoding'] = 'utf8' - デフォルトを変更する UTF-16 から utf-8 にエンコードします。
executable

ブール値設定不可デフォルトは False です

出力を実行可能として宣言します。

このフラグを True に設定すると、出力が実行可能ファイルであり、 run コマンドを使用します。この場合、genrule は 1 つの出力のみを生成する必要があります。 この属性が設定されている場合、run は できます。

生成された実行可能ファイルのデータ依存関係の宣言はサポートされていません。

local

ブール値デフォルトは False です。

True に設定すると、この genrule は強制的に「local」を使用して リモート実行、サンドボックス化、永続ワーカーのいずれもないということです。

これは "local"タグとして指定(tags=["local"])。

message

String;デフォルトは "" です。

進行状況のメッセージ。

このビルドステップの実行時に出力される進行状況メッセージ。デフォルトでは、 「出力を生成しています」というメッセージが表示されるといった表現が考えられますが、 より具体的なものにします。echo などの print の代わりに、この属性を使用します cmd コマンド内で指定する必要があります。これにより、ビルドツールが 出力するかどうかを指定できます。

output_licenses

ライセンスの種類デフォルトは ["none"] です。

common attributes を参照してください。
output_to_bindir

ブール値設定不可デフォルトは False です

True に設定すると、出力ファイルが bin に書き込まれます。 ディレクトリではなく、genfiles ディレクトリを使用します。

tools

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

このルールの tool 依存関係のリスト。定義を表示 依存関係をご覧ください。

ビルドシステムでは、genrule コマンドを実行する前に、これらの前提条件が確実にビルドされます。 exec パスを使用してビルドされます。 Terraform 構成。これらのツールはビルドの一部として実行されるため、アプリケーションの 個々の tools のターゲット //x:y は、次を使用して取得できます。 $(location //x:y)

cmd が実行する *_binary やツールは、すべてここに含まれている必要があります。 srcs ではなくリストに含めて、正しい構成で作成されるようにします。

starlark_doc_extract

ルールのソースを表示
starlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)

starlark_doc_extract() は、ルール、関数( マクロ)、アスペクト、プロバイダが特定の .bzl または .scl ファイル。このルールの出力は、定義された ModuleInfo バイナリ proto です。 stardoc_output.proto (Bazel ソースツリー)

暗黙的な出力ターゲット

  • name.binaryproto(デフォルト出力): A ModuleInfo バイナリ プロトコル。
  • name.textproto(明示的にリクエストされた場合にのみビルド): テキスト name.binaryproto の proto バージョン。

警告: このルールの出力形式は、必ずしも安定しているとは限りません。主に Stardoc の内部使用。

引数

属性
name

名前:必須

このターゲットの一意の名前。

deps

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

load() で管理される Starlark ファイルをラップするターゲットのリスト。 src。通常の使用では、これらのターゲットは必要です。 bzl_library ただし、starlark_doc_extract ルールはそれを強制せず、 DefaultInfo で Starlark ファイルを提供するターゲット。

ラップされた Starlark ファイルはソースツリー内のファイルである必要があります。Bazel ではできない load() 個の生成されたファイル。

src

ラベル:必須

ドキュメントの抽出元の Starlark ファイル。

ソースツリー内のファイルに指定する必要があります。Bazel が load() できない 表示できます。

render_main_repo_name

ブール値デフォルトは False です。

true の場合、出力されたドキュメントのメイン リポジトリに、リポジトリ コンポーネントを使用してラベルをレンダリングする (つまり、//foo:bar.bzl は次のように出力されます) @main_repo_name//foo:bar.bzl)です。

メイン リポジトリに使用する名前は module(name = ...) から取得します。 メイン リポジトリの MODULE.bazel ファイル内(Bzlmod が有効になっている場合)、または メイン リポジトリの WORKSPACE ファイル内の workspace(name = ...)

ドキュメントを生成するときは、この属性を False に設定する必要があります。 同じリポジトリ内でのみ使用されることを意図した Starlark ファイル、および Starlark ファイルのドキュメントを生成するときに、True 他のリポジトリから使用できます。

symbol_names

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

エクスポートされる関数、ルール、プロバイダ、アスペクト(またはアスペクト)の修飾名のリスト(省略可) ネストされた構造体など)を指定します。ここで、 name は、モジュールのユーザーがエンティティを使用できるようにするための名前です。 これには、名前空間のためにエンティティがネストされている構造体も含まれます。

starlark_doc_extract は、次の場合にのみエンティティのドキュメントを出力します。

  1. エンティティの修飾名の各要素は public である(つまり、最初の 修飾名の各要素の文字がアルファベットであり、"_" ではない。 および
    1. symbol_names リストが空(デフォルト ケース)、または
    2. エンティティの修飾名、またはエンティティが格納されている構造体の修飾名 ネストされ、symbol_names リストに含まれている。

test_suite

ルールのソースを表示
test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite は、「有用」と見なされるテストのセットを定義します。制御します。この では、プロジェクトで「チェックイン前に実行する必要があるテスト」、「Google の 「プロジェクトのストレステスト」を“すべて小規模なテスト”という 表現を使うこともできますbazel test コマンドはこの並べ替え順に従います。 組織: bazel test //some/test:suite のような呼び出しでは、最初に Bazel を使用 //some/test:suite ターゲットによって推移的に含まれているすべてのテスト ターゲットを列挙します( これを「test_suite 拡張」と呼ぶ)、Bazel はこれらのターゲットをビルドおよびテストします。

現在のパッケージ内の小規模なテストをすべて実行するテストスイート。

test_suite(
    name = "small_tests",
    tags = ["small"],
)

指定されたテストセットを実行するテストスイート:

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

現在のパッケージ内の不安定でないすべてのテストを実行するためのテストスイート。

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

引数

属性
name

名前:必須

このターゲットの一意の名前。

tags

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

「small」などのテキストタグのリストまたは「database」「-flaky」などです。タグには任意の有効な文字列を指定できます。

「-」で始まるタグ文字は否定タグと見なされます。「 先行する「-」文字はタグの一部とは見なされないため、 「-small」テストの「small」と指定します。他のすべてのタグが考慮されます 検出します。

必要に応じて、ポジティブ タグを明示するために、 「+」この文字はタグのテキストでは評価されません。これは、 プラスとマイナスの区別が読みやすくなるだけです。

すべての正のタグに一致し、負のタグにはまったく一致しないルールのみをテストする タグがテストスイートに含まれます。ただし、これはエラーチェックが 除外されたテストの依存関係はスキップされます。依存関係がスキップされて テストは依然として適切である必要があります(たとえば、可視性の制約によってブロックされていないこと)。

manual タグのキーワードは、 "test_suite の展開"呼び出しで bazel test コマンドによって実行される ワイルドカードを含む ターゲット パターン 「手動」のタグが付けられた test_suite 個のターゲットがありますフィルタで除外されます(つまり、 開いています)。この動作は、bazel buildbazel test は通常、ワイルドカードのターゲット パターンを処理します。なお、これは bazel query 'tests(E)' の動作と明示的に異なるため、スイートは 例外の有無にかかわらず、常に tests クエリ関数で展開されます。 manual タグ。

テストの size は、フィルタリングを目的としたタグと見なされます。

相互に排他的なタグを持つテストを含む test_suite が必要な場合 すべてのテスト(例: すべての小規模テストと中規模テスト)でテストするには、3 つの test_suite を作成する必要があります。 1 つはすべての小規模テスト用、1 つは中規模テスト用、もう 1 つはすべてのテスト用 確認します。

tests

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

任意の言語のテストスイートとテスト ターゲットのリスト。

ここでは、言語に関係なく、すべての *_test を使用できます。× ただし、*_binary ターゲットはたまたまテストを実行した場合でも受け入れられます。 指定された tags によるフィルタリングは、 指定します。この属性に test_suite が含まれている場合、その中のテストは これらはこの test_suite でフィルタされません( など)。

tests 属性が指定されていないか空の場合、ルールはデフォルトで 現在の BUILD ファイルに、タグとしてタグ付けされていないすべてのテストルールが含まれます。 manual。これらのルールは引き続き tag フィルタリングの対象となります。