一般ルール

問題を報告 ソースを表示 Nightly · 7.4 . 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 ルールは、ルールの別名を作成します。

エイリアスは「通常」のターゲットにのみ適用されます。特に、package_grouptest_suite にはエイリアスを設定できません。

エイリアスは、ターゲットの名前変更に多くのファイルの変更が必要となる大規模なリポジトリで役立ちます。複数のターゲットでそのロジックを再利用する場合は、エイリアス ルールを使用して select 関数呼び出しを保存することもできます。

エイリアス ルールには独自の公開設定宣言があります。その他の点では、参照先のルールと同じように動作します(例: エイリアスの testonly は無視され、代わりに参照先のルールの testonly が使用されます)。ただし、いくつかの例外があります。

  • コマンドラインにエイリアスが指定されている場合、テストは実行されません。参照先のテストを実行するエイリアスを定義するには、tests 属性に単一のターゲットを持つ test_suite ルールを使用します。
  • 環境グループを定義する場合、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 をご覧ください。一般的な機能の概要については、 構成可能な属性をご覧ください。

次のパターンは、--compilation_mode=opt または -c opt を設定するビルド(コマンドラインで明示的に設定するか、.bazelrc ファイルから暗黙的に設定)に一致します。

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

以下は、ARM をターゲットとするすべてのビルドに一致し、カスタム定義 FOO=barbazel 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 のプラットフォームをターゲットとするビルドに一致します。これは、ラベル //example:glibc_2_25constraint_value が存在することを前提としています。プラットフォームがこれらの 2 つを超える制約値を定義している場合でも、プラットフォームは一致します。

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

メモ

  • 複数の config_setting が現在の構成状態と一致した場合の動作については、select をご覧ください。
  • 省略形をサポートするフラグ(--compilation_mode-c など)の場合、values の定義では完全な形式を使用する必要があります。これらは、どちらの形式を使用した呼び出しとも自動的に一致します。
  • フラグが複数の値(--copt=-Da --copt=-Db やリスト型の 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 を参照します。
  • valuesdefine_valuesconstraint_values は、同じ config_setting で任意の組み合わせで使用できますが、特定の config_setting に対して少なくとも 1 つは設定する必要があります。

引数

属性
name

名前: 必須

このターゲットの名前。

constraint_values

ラベルのリスト。構成できません。デフォルトは [] です。

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

2 つの config_setting が同じ select で一致する場合、この属性は、一方の config_setting が他方の特殊化であるかどうかを判断する目的では考慮されません。つまり、ある config_setting が別のプラットフォームより強く一致することはできません。

define_values

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

values と同じですが、--define フラグ専用です。

--define は特別な値です。その構文(--define KEY=VAL)は、Bazel フラグから見た KEY=VALであることを意味します。

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

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

は機能しません。これは、同じキー(define)が辞書に 2 回出現しているためです。この属性を使用すると、その問題を解決できます。

            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 -> 文字列。構成不可。デフォルトは {}

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

これは、ユーザー定義フラグはラベルとして参照されるのに対し、組み込みフラグは任意の文字列として参照されるため、明確な属性です。

values

辞書: 文字列 -> 文字列。構成不可。デフォルトは {} です。

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

このルールは、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

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

filegroup を使用して、ターゲットのコレクションに便利な名前を付けます。これらの変数は、他のルールから参照できます。

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

2 つのソースファイルで構成される filegroup を作成するには、次の操作を行います。

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

または、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

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

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

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

data

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

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

data 属性で指定されたターゲットは、この filegroup ルールの runfiles に追加されます。filegroup が別のルールの data 属性で参照されると、その runfiles は依存するルールの runfiles に追加されます。データファイルに依存して使用する方法については、データの依存関係のセクションと data の一般的なドキュメントをご覧ください。

output_group

文字列。デフォルトは "" です。

ソースからアーティファクトを収集する出力グループ。この属性を指定すると、デフォルトの出力グループではなく、指定した依存関係の出力グループのアーティファクトがエクスポートされます。

「出力グループ」は、そのルールの実装で指定されたターゲットの出力アーティファクトのカテゴリです。

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() は、Blaze クエリ言語で指定されたクエリを実行し、結果をファイルにダンプします。

ビルドの一貫性を維持するため、クエリは scope 属性で指定されたターゲットの推移閉包のみを訪問できます。strict が指定されていないか true の場合、このルールに違反するクエリは実行中に失敗します(strict が false の場合、スコープ外のターゲットは警告とともにスキップされます)。これを防ぐ最も簡単な方法は、クエリ式と同じラベルをスコープ内で指定することです。

ここで使用できるクエリとコマンドラインで許可される唯一の違いは、ワイルドカード ターゲット指定(//pkg:*//pkg:all など)を含むクエリは使用できないことです。その理由は 2 つあります。まず、genquery では、クエリの推移閉包外のターゲットが出力に影響しないようにスコープを指定する必要があります。次に、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

文字列(必須)

実行するクエリ。コマンドラインや 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 つ以上のファイルを生成します。

Genrules は、タスクに特定のルールがない場合に使用できる汎用のビルドルールです。たとえば、Bash ワンライナーを実行できます。ただし、C++ ファイルをコンパイルする必要がある場合は、既存の cc_* ルールに従ってください。すべての面倒な作業はすでに行われています。

genrule では、コマンド引数を解釈するシェルが必要です。PATH で使用可能な任意のプログラムを参照することも簡単ですが、この場合、コマンドは非ヘルメティックになり、再現できない可能性があります。1 つのツールを実行するだけの場合は、代わりに run_binary を使用することを検討してください。

テストの実行に genrule を使用しないでください。テストとテスト結果には、キャッシュ ポリシーや環境変数など、特別な例外があります。通常、テストはビルドの完了後にターゲット アーキテクチャで実行する必要がありますが、genrule はビルド中に実行され、実行アーキテクチャで実行されます(2 つは異なる場合があります)。汎用のテストルールが必要な場合は、sh_test を使用します。

クロスコンパイルに関する考慮事項

クロスコンパイルの詳細については、ユーザー マニュアルをご覧ください。

genrule はビルド中に実行されますが、その出力はビルド後にデプロイやテストに使用されることがよくあります。マイクロコントローラの C コードをコンパイルする場合を考えてみます。コンパイラは C ソースファイルを受け入れ、マイクロコントローラで実行されるコードを生成します。生成されたコードはビルドに使用された CPU では実行できませんが、C コンパイラ(ソースからコンパイルされた場合)自体は実行する必要があります。

ビルドシステムは exec 構成を使用してビルドを実行するマシンを記述し、ターゲット構成を使用してビルドの出力を実行するマシンを記述します。これらのそれぞれを構成するオプションが提供され、対応するファイルを別々のディレクトリに分離して競合を回避します。

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

genrule で deps 属性を定義しないという意図があります。他の組み込みルールは、ルール間で渡された言語依存のメタ情報を使用して、依存ルールの処理方法を自動的に決定しますが、genrule ではこのレベルの自動化は不可能です。Genrules は、ファイルと runfile レベルでのみ動作します。

特別なケース

Exec-exec コンパイル: 場合によっては、ビルドシステムで genrules を実行して、ビルド中に出力も実行できるようにする必要があります。たとえば、genrule でビルドしたカスタム コンパイラが後に別の genrule で使用される場合、最初のカスタム コンパイラで exec 構成の出力を生成する必要があります。これは、コンパイラがもう一方の genrule で実行されるためです。この場合、ビルドシステムは自動的に正しいことを行います。ターゲット構成ではなく、実行構成の最初の genrule の srcsouts をビルドします。詳しくは、ユーザー マニュアルをご覧ください。

JDK と C++ ツール: JDK または C++ コンパイラ スイートのツールを使用するには、ビルドシステムが使用する一連の変数を提供します。詳細については、「Make」変数をご覧ください。

Genrule 環境

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

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

genrule コマンドでは、コマンド自体の子プロセスを接続する場合を除き、ネットワークにアクセスできません。ただし、これは現在は適用されていません。

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

一般的なアドバイス

  • genrule によって実行されるツールが確定的かつ完全密閉であることを確認してください。出力にタイムスタンプを書き込むことはできません。また、セットとマップには安定した順序を使用し、出力には相対ファイルパスのみを書き込み、絶対パスは書き込まないでください。このルールに従わないと、予期しないビルド動作(Bazel が予想した genrule を再構築しない)が発生し、キャッシュのパフォーマンスが低下します。
  • 出力、ツール、ソースに $(location) を広範に使用します。異なる構成の出力ファイルが分離されているため、genrules はハードコードされたパスや絶対パスに依存できません。
  • 同一または非常に類似した genrule が複数の場所で使用される場合は、共通の Starlark マクロを作成します。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 のラベルまたは個々の出力ファイルのラベルを使用できます。一方のアプローチのほうが読みやすい場合もありますが、使用ルールの 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 の出力を示しています。明示的な $(location) ディレクティブの代わりに $(SRCS) を使用することもできます。この例では、デモのために後者を使用しています。

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

名前: 必須

このターゲットの名前。


このルールは、他の BUILD ルールの srcs セクションまたは deps セクションで名前で参照できます。ルールがソースファイルを生成する場合は、srcs 属性を使用する必要があります。
srcs

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

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

この属性は、cmd によって実行されるツールを一覧表示するには適していません。代わりに tools 属性を使用してください。

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

outs

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

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

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

executable フラグが設定されている場合、outs には 1 つのラベルのみを含める必要があります。

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

cmd

文字列。デフォルトは "" です。

実行するコマンド。$(location) 「Make」変数の置換が適用されます。
  1. まず $(location) の置換が適用され、$(location label)$(locations label) のすべての出現箇所(および関連する変数 execpathexecpathsrootpathrootpaths を使用した同様の構造)が置き換えられます。
  2. 次に、「Make」変数が展開されます。事前定義変数 $(JAVA)$(JAVAC)$(JAVABASE)exec 構成で展開されるため、ビルドステップの一部として実行される Java 呼び出しで、共有ライブラリやその他の依存関係を正しく読み込むことができます。
  3. 最後に、生成されたコマンドが Bash シェルを使用して実行されます。終了コードがゼロ以外の場合、コマンドは失敗したと見なされます。
cmd_bashcmd_pscmd_bat のいずれにも該当しない場合の、これらのフォールバックです。

コマンドライン長がプラットフォームの上限(Linux / macOS では 64,000、Windows では 8,000)を超えると、genrule はコマンドをスクリプトに書き込み、そのスクリプトを実行して回避します。これは、すべての cmd 属性(cmdcmd_bashcmd_pscmd_bat)に適用されます。

cmd_bash

文字列。デフォルトは "" です。

実行する Bash コマンド。

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

cmd_bat

文字列。デフォルトは "" です。

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

この属性は、cmdcmd_bash よりも優先度が高くなります。 このコマンドは cmd 属性と同様に実行されますが、次の点が異なります。

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

文字列。デフォルトは "" です。

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

この属性は、cmdcmd_bashcmd_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 は「ローカル」戦略を使用して強制的に実行されます。つまり、リモート実行、サンドボックス、永続ワーカーは使用されません。

これは、タグ(tags=["local"])として「local」を指定するのと同じです。

message

文字列。デフォルトは ""

進行状況メッセージ。

このビルドステップの実行時に出力される進行状況メッセージ。デフォルトでは、メッセージは「出力の生成中」ですが、より具体的なメッセージを指定することもできます。cmd コマンドの echo や他の出力ステートメントの代わりにこの属性を使用すると、このような進行状況メッセージが出力されるかどうかをビルドツールで制御できます。

output_licenses

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

common attributes をご覧ください。
output_to_bindir

ブール値。構成不可。デフォルトは False です。

このオプションを True に設定すると、出力ファイルは genfiles ディレクトリではなく bin ディレクトリに書き込まれます。

tools

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

このルールのツールの依存関係のリスト。詳細については、依存関係の定義をご覧ください。

ビルドシステムは、genrule コマンドを実行する前にこれらの前提条件がビルドされるようにします。これらのツールはビルドの一部として実行されるため、exec 構成を使用してビルドされます。個々の 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 ファイルで定義または再エクスポートされたルール、関数(マクロを含む)、アスペクト、プロバイダのドキュメントを抽出します。このルールの出力は、Bazel ソースツリーの stardoc_output.proto で定義されている ModuleInfo バイナリ proto です。

暗黙的な出力ターゲット

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

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

引数

属性
name

名前: 必須

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

deps

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

src によって load() された Starlark ファイルをラップするターゲットのリスト。通常の使用では、これらのターゲットは bzl_library ターゲットである必要がありますが、starlark_doc_extract ルールではそれが適用されず、DefaultInfo で Starlark ファイルを提供するターゲットはすべて受け入れられます。

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

src

ラベル: 必須

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

これはソースツリー内のファイルである必要があります。Bazel は load() 生成ファイルを使用できません。

render_main_repo_name

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

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

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

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

symbol_names

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

ドキュメントを抽出するエクスポートされた関数、ルール、プロバイダ、アスペクト(またはそれらがネストされている構造体)の完全修飾名のリスト(省略可)。ここで、修飾名とは、モジュールのユーザーがエンティティを利用できる名前を意味します。これには、名前空間のためにエンティティがネストされている構造体も含まれます。

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

  1. エンティティの完全修飾名の各コンポーネントが公開されている(つまり、完全修飾名の各コンポーネントの最初の文字が "_" ではなく英字である)。
    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 は、人間にとって「有用」と見なされる一連のテストを定義します。これにより、プロジェクトで「チェックイン前に実行する必要があるテスト」、「プロジェクトのストレステスト」、「すべて小規模なテスト」などの一連のテストを定義できます。blaze test コマンドは、このような組織を尊重します。blaze test //some/test:suite などの呼び出しの場合、Blaze はまず、//some/test:suite ターゲットに帰属するすべてのテストターゲットを列挙します(これを「test_suite 拡張」と呼びます)。次に、Blaze はこれらのターゲットをビルドしてテストします。

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

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 タグキーワードは、ワイルドカード ターゲット パターンを含む呼び出しで blaze test コマンドが実行する「test_suite 拡張」によって、上記とは異なる方法で処理されます。ここでは、「手動」のタグが付いた test_suite ターゲットは除外されます(拡張されません)。この動作は、blaze buildblaze test がワイルドカード ターゲット パターンを一般に処理する方法と一致します。manual タグに関係なく、スイートは常に tests クエリ関数によって展開されるため、これは blaze query 'tests(E)' の動作とは明確に異なります。

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

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

tests

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

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

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

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