ルール
- <ph type="x-smartling-placeholder"></ph> エイリアス
- <ph type="x-smartling-placeholder"></ph> config_setting
- <ph type="x-smartling-placeholder"></ph> ファイル グループ
- <ph type="x-smartling-placeholder"></ph> genquery
- <ph type="x-smartling-placeholder"></ph> genrule
- <ph type="x-smartling-placeholder"></ph> test_suite
エイリアス
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
alias ルールは、ルールの別名を作成します。
エイリアス化は「regular」できます。具体的には、package_group
test_suite にはエイリアスを設定できません。
エイリアス ルールには独自の公開設定宣言があります。その他すべての点では、 （たとえば、エイリアスの 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 など）は、 <ph type="x-smartling-placeholder"></ph> 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,bとios_multi_cpus=a --ios_multi_cpus=bはどちらも["a", "b"]を生成します。フラグの定義を確認し、 状況を正確に把握する必要があります。 - 組み込みのビルドフラグでモデル化されない条件を定義する必要がある場合は、次のコマンドを使用します。
<ph type="x-smartling-placeholder"></ph>
Starlark で定義されたフラグ。
--defineも使用できますが、メリットは少なくなります サポートされないため、推奨されません。詳しくは、 こちらをご覧ください。 - 異なるパッケージで同じ
config_setting定義を繰り返さないでください。 代わりに、正規パッケージで定義された共通のconfig_settingを参照してください。 valuesdefine_values、constraint_values同じconfig_settingの任意の組み合わせで使用できますが、少なくとも 1 つは使用する必要があります 特定のconfig_settingに対して設定することもできます。
引数
| 属性 | |
|---|---|
name |
このターゲットの一意の名前。 |
constraint_values
|
constraint_values の最小セット
この config_setting に一致する必要があります。（実行プラットフォームは、
考慮する必要はありません）。プラットフォームに設定されている追加の制約値は無視されます。詳しくは、
<ph type="x-smartling-placeholder"></ph>
構成可能なビルド属性をご覧ください。
2 つの |
define_values
|
values と同じですが、
特に --define フラグで使用します。
つまり、次のようになります。
config_setting(
name = "a_and_b",
values = {
"define": "a=1",
"define": "b=2",
})
同じキー（
config_setting(
name = "a_and_b",
define_values = {
"a": "1",
"b": "2",
})
|
flag_values
|
values と同じですが、
（）
ユーザー定義のビルドフラグ。
ユーザー定義のフラグはラベルとして参照されますが、 組み込みフラグは任意の文字列として参照されます。 |
values
|
このルールは、構成済みのターゲットの構成を
便宜上、構成値はビルドフラグとして指定します（
先行する コマンドラインでフラグが明示的に設定されていない場合は、そのデフォルト値が使用されます。
辞書でキーが複数回出現する場合、最後のインスタンスのみが使用されます。
コマンドラインで複数回設定できるフラグをキーが参照している場合（例:
|
ファイルグループ
filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
filegroup を使用して、ターゲットのコレクションにわかりやすい名前を付けます。
これらは他のルールから参照できます。
ディレクトリを直接参照するのではなく、filegroup を使用することをおすすめします。
後者は、ビルドシステムがすべてのファイルを完全に把握しているわけではないため、問題はありません。
ため、これらのファイルが変更されても再ビルドされない可能性があります。組み合わせた場合:
glob、filegroup により、すべてのファイルが
明示的に認識されるようにすることもできます。
例
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
|
glob 式の結果は、次の場合に使用するのが一般的です。
|
data
|
|
output_group
|
「出力グループ」ターゲットの出力アーティファクトのカテゴリで、 適用できます。 |
genquery
genquery(name, deps, data, compatible_with, 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 つの理由があります。1 つ目は、genquery が
の推移的クロージャの範囲に収まらないターゲットを防止するスコープを指定します。
出力に影響を与えます。2 つ目は、BUILD ファイルが
ワイルドカードの依存関係はサポートされていない（例: deps=["//a/..."]）
は許可されていません）。
genquery の出力は、--order_output=full を使用して並べ替えられます。
決定論的な出力を適用します
出力ファイルの名前はルールの名前です。
例
この例では、ラベルのリストを 適用できます。
genquery(
name = "kiwi-deps",
expression = "deps(//kiwi:kiwi_lib)",
scope = ["//kiwi:kiwi_lib"],
)
引数
| 属性 | |
|---|---|
name |
このターゲットの一意の名前。 |
expression
|
a/BUILD のこの属性の :b ラベルが参照するのは、
目標は //:b です。
|
opts
|
bazel query に渡すことができるオプション。一部のクエリ オプションは使用できません
ここに: --keep_going、--query_file、--universe_scope、
--order_results、--order_output。ここで指定されていないオプション
bazel query のコマンドラインと同様に、デフォルト値が設定されます。
|
scope
|
|
strict
|
|
Genrule
genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, 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 を使用しないでください。テストとテストには特別な給与が
（キャッシュ ポリシーや環境変数など）の結果を確認できます。通常はテストを実行する必要があり
genrules はビルド完了後にターゲット アーキテクチャで実行されるのに対し、genrules はビルド完了後に実行される
ホスト アーキテクチャによって異なります（この 2 つは異なる場合があります）。一般的なユースケースで
sh_test を使用します。
クロスコンパイルの考慮事項
詳しくは、ユーザー マニュアルをご覧ください。 役立ちます。
genrule はビルド中に実行されますが、その出力は多くの場合、デプロイや 説明します。マイクロコントローラの C コードをコンパイルする例を考えてみましょう。コンパイラは C 言語を受け入れます。 マイクロコントローラで実行されるコードを生成できます。生成されたコードは そのビルドに使用された CPU では実行できないが、C コンパイラ（ソースからコンパイルされた場合）は 構成する必要があります
ビルドシステムはホスト構成を使用して、ビルドを実行するマシンを記述します ビルドの出力先のマシンを記述するためのターゲット構成 指定します。それぞれを構成するオプションが用意されており、 競合を避けるために、対応するファイルを別々のディレクトリに保存してください。
genrules では、依存関係が適切にビルドされていることがビルドシステムによって確認されます。
（必要に応じて）ターゲット構成用に srcs がビルドされます。
tools は host 構成用にビルドされ、出力は
target 構成のものである必要があります。また、
「つくる」genrule コマンドが対応するツールに渡すことができる変数があります。
genrule で deps 属性を定義しないのは意図的なことです。他の組み込みルールでは、
ルール間で渡される言語依存のメタ情報で、インフラストラクチャの
ただし、genrules ではこのレベルの自動化はできません。genrule の仕組み
実行されています。
特殊なケース
ホストとホスト間のコンパイル: 場合によっては、ビルドシステムで genrule を実行し、
出力はビルド中にも実行できます。たとえば、genrule がカスタム コンパイラを
そのモデルを別の genrule で使用します。1 番目は元のルールに対して
他の genrule でコンパイラが実行されるためです。この例では
ビルドシステムは正しい処理を自動的に行います。つまり、srcs がビルドされ、
ターゲットではなく、ホスト構成の最初の genrule の outs
できます。詳しくは、ユーザー マニュアルをご覧ください。
JDK とC++ ツール: JDK または C++ コンパイラ スイートのツールを使用するには、ビルドシステム 使用する変数のセットを提供します。「メーカー」変数 表示されます。
Genrule 環境
genrule コマンドは Bash シェルで実行されます。このシェルは、コマンドが失敗したときに失敗するように構成されています。
パイプラインが失敗した場合に set -e -o pipefail を使用します。
ビルドツールは、サニタイズされたプロセス環境で Bash コマンドを実行し、
PATH、PWD、
TMPDIRなど
ビルドの再現性を確保するため、ほとんどの変数はユーザーのシェル
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 asls $(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 |
このターゲットの一意の名前。 このルールは、 他の BUILD の srcs または deps セクション
できます。ルールによってソースファイルが生成される場合は、
srcs 属性。
|
srcs
|
この属性は、
ビルドシステムでは、genrule を実行する前にこれらの前提条件が確実にビルドされる
command;元のビルド リクエストと同じ構成を使用してビルドされる。「
これらの前提条件のファイルの名前が、コマンドに
|
outs
|
出力ファイルはパッケージの境界を越えてはいけません。 出力ファイル名はパッケージからの相対名として解釈されます。
genrule コマンドでは、各出力ファイルを所定の場所に作成する必要があります。
ロケーションは、genrule 固有の「Make」を使用して |
cmd
|
$(location)
と「Make」を条件とするあります。
cmd_bash、cmd_ps、cmd_bat のフォールバックです。
いずれも該当しない場合は必須です。
コマンドラインの長さがプラットフォームの上限（Linux/macOS では 64 K、Windows では 8 K）を超える場合、
genrule はコマンドをスクリプトに記述し、そのスクリプトを実行して問題を回避します。この
すべての cmd 属性（ |
cmd_bash
|
この属性の優先度は |
cmd_bat
|
この属性の優先度は
|
cmd_ps
|
この属性の優先度は、
Powershell をより使いやすく、エラーが発生しにくくするために、次のコマンドを実行します。 genrule で Powershell コマンドを実行する前に、環境をセットアップする必要があります。
|
exec_tools
|
tools 属性。ただし、これらの依存関係は
は、ホスト設定ではなくルールの実行プラットフォームに対して設定されます。
つまり、exec_tools の依存関係には同じものが適用されません。
制限を tools の依存関係として提供します。特に、インフラストラクチャを
自身の推移的依存関係にホスト構成を使用する。詳しくは、
tools。
Blaze チームは、 |
executable
|
このフラグを True に設定すると、出力が実行可能ファイルであり、
生成された実行可能ファイルのデータ依存関係の宣言はサポートされていません。 |
local
|
True に設定すると、この
これは "local"タグとして指定（ |
message
|
このビルドステップの実行時に出力される進行状況メッセージ。デフォルトでは、
「出力を生成しています」というメッセージが表示されるといった表現が考えられますが、
より具体的なものにします。 |
output_licenses
|
common attributes
を参照してください。
|
output_to_bindir
|
True に設定すると、出力ファイルが |
tools
|
ビルドシステムでは、genrule コマンドを実行する前に、これらの前提条件が確実にビルドされます。
host コマンドを使用してビルドされます。
Terraform 構成。これらのツールはビルドの一部として実行されるため、アプリケーションの
個々の
|
test_suite
test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
test_suite は、「有用」と見なされるテストのセットを定義します。制御します。この
では、プロジェクトで「チェックイン前に実行する必要があるテスト」、「Google の
「プロジェクトのストレステスト」を“すべて小規模なテスト”という
表現を使うこともできます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」テストの「small」と指定します。他のすべてのタグが考慮されます 検出します。 必要に応じて、ポジティブ タグを明示するために、 「+」この文字はタグのテキストでは評価されません。これは、 プラスとマイナスの区別が読みやすくなるだけです。 すべての正のタグに一致し、負のタグにはまったく一致しないルールのみをテストする タグがテストスイートに含まれます。ただし、これはエラーチェックが 除外されたテストの依存関係はスキップされます。依存関係がスキップされて テストは依然として適切である必要があります（たとえば、可視性の制約によってブロックされていないこと）。
テストの
相互に排他的なタグを持つテストを含む |
tests
|
ここでは、言語に関係なく、すべての
|