目次
パッケージ
package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)
この関数は、パッケージ内のすべてのルールに適用されるメタデータを宣言します。パッケージ（BUILD ファイル）内で最大 1 回使用されます。
メタデータを宣言する対応するルールについては、
リポジトリにある場合は、Python で repo() 関数を使用します。
リポジトリのルートに REPO.bazel ファイルを配置します。
repo() 関数は、package() とまったく同じ引数を受け取ります。
package() 関数は、ファイルの先頭にあるすべての load() ステートメントの直後、ルールの前に呼び出す必要があります。
引数
| 属性 | 説明 |
|---|---|
default_applicable_licenses |
|
default_visibility |
ラベルのリスト。デフォルトは このパッケージのルールのデフォルトの公開設定。 このパッケージ内のすべてのルールは、このパッケージに含まれる公開設定に
属性（ |
default_deprecation |
文字列。デフォルトは このパッケージ内のすべてのルールにデフォルトの |
default_package_metadata |
ラベルのリスト。デフォルトは パッケージ内の他のすべてのターゲットに適用されるメタデータ ターゲットのデフォルト リストを設定します。 通常、これらは OSS パッケージとライセンス宣言に関連するターゲットです。例については、rules_license をご覧ください。 |
default_testonly |
ブール値。特に記載のない限り、デフォルトは このパッケージ内のすべてのルールにデフォルトの
|
features |
リスト文字列。デフォルトは この BUILD ファイルのセマンティクスに影響するさまざまなフラグを設定します。 この機能は主に、ビルドシステムの開発者が なんらかの特別な処理が必要なタグ パッケージをビルドします。次の場合以外は使用しないでください。 明示的にリクエストされた処理はありません。 |
例
以下の宣言では、このパッケージのルールが パッケージのメンバーにのみ公開 グループ//foo:target。ルールの個々の公開設定宣言（存在する場合）は、この仕様をオーバーライドします。package(default_visibility = ["//foo:target"])
package_group
package_group(name, packages, includes)
この関数は、パッケージのセットを定義し、そのセットにラベルを関連付けます。ラベルは visibility 属性で参照できます。
パッケージ グループは、主に公開設定に使用されます。公開されているターゲットは、ソースツリー内のすべてのパッケージから参照できます。プライベートで 可視ターゲットは、自身のパッケージ内でのみ参照できます（サブパッケージ内では参照できません）。 これらの極端な例の中間では、ターゲットは独自のパッケージに加えて、1 つ以上のパッケージ グループで記述されたパッケージへのアクセスを許可できます。詳細については、 説明については、このモジュールの 可視性 属性です。
グループに含まれるのは、
packages 属性、またはすでに他 1 つの属性に含まれています
includes 属性で指定されたパッケージ グループ。
パッケージ グループは技術的にはターゲットですが、ルールによって作成されず、それ自体に可視性保護はありません。
引数
| 属性 | 説明 |
|---|---|
name |
名前:必須 このターゲットの名前。 |
packages |
文字列のリスト。デフォルトは 0 個以上のパッケージ仕様のリスト。 各パッケージ仕様の文字列には、次のいずれかを指定できます。 フォーム:
また、最初の 2 種類のパッケージ仕様に パッケージ グループには、正の指定の少なくとも 1 つに一致し、負の指定のいずれにも一致しないパッケージが含まれます。たとえば、値 公開設定のほか、バージョン 4 に 外部にデプロイされます この属性が指定されていない場合、空のリストに設定した場合と同じになります。これは、 注: Bazel 6.0 より前では、仕様 注: Bazel 6.0 より前では、この属性が次のようにシリアル化されています。
|
includes |
ラベルのリスト。デフォルトは このパッケージ グループに含まれる他のパッケージ グループ。 この属性のラベルは他のパッケージ グループを参照する必要があります。
参照先のパッケージ グループ内のパッケージも、このパッケージに含まれます。
含まれています。パッケージ グループの場合、これは推移的です。
否定されたパッケージ仕様とともに使用する場合、各グループのパッケージセットが最初に個別に計算され、結果が結合されます。つまり グループ内の仕様に影響を与えない場合、 クリックします。 |
例
次の package_group 宣言では、
「トロピカル」というラベルの含まれることになります。
package_group(
name = "tropical",
packages = [
"//fruits/mango",
"//fruits/orange",
"//fruits/papaya/...",
],
)
次の宣言では、架空のアプリケーションのパッケージ グループを指定します。
package_group(
name = "fooapp",
includes = [
":controller",
":model",
":view",
],
)
package_group(
name = "model",
packages = ["//fooapp/database"],
)
package_group(
name = "view",
packages = [
"//fooapp/swingui",
"//fooapp/webui",
],
)
package_group(
name = "controller",
packages = ["//fooapp/algorithm"],
)
exports_files
exports_files([label, ...], visibility, licenses)
exports_files() は、オブジェクトに属するファイルのリストを指定します。
他のパッケージにエクスポートされます。
パッケージの BUILD ファイルで別のパッケージに属するソースファイルを直接参照できるのは、exports_files() ステートメントで明示的にエクスポートされている場合のみです。詳細を見る:
ファイルの可視性に優れています。
以前の動作として、ルールへの入力として指定されたファイルも、フラグ --incompatible_no_implicit_file_export が反転されるまで、デフォルトの公開設定でエクスポートされます。ただし、この動作に依存するべきではありません。また、
Google Workspace から
引数
引数は、現在のパッケージ内のファイル名のリストです。可視性の宣言を指定することもできます。この場合、ファイルは指定されたターゲットに表示されます。公開設定が指定されていない場合、
すべてのパッケージに表示されます。パッケージのデフォルトの公開設定が
package で指定
使用します。ライセンス
指定することもできます。
例
次の例では、test_data パッケージからテキスト ファイルである golden.txt をエクスポートします。これにより、他のパッケージがテストの data 属性などで使用できるようになります。
# from //test_data/BUILD exports_files(["golden.txt"])
glob
glob(include, exclude=[], exclude_directories=1, allow_empty=True)
Glob は、特定のパスパターンに一致するすべてのファイルを検索し、そのパスの新しい変更可能な並べ替え済みリストを返すヘルパー関数です。Glob はファイルのみを検索 検索され、ソースファイルのみが検索されます（生成されたファイルや できます。
ファイルのパッケージ相対パスが include パターンのいずれかに一致し、exclude パターンのいずれにも一致しない場合、ソースファイルのラベルが結果に含まれます。
include リストと exclude リストには、現在のパッケージを基準とするパスパターンが含まれています。すべてのパターンは、1 つ以上のパスセグメントで構成できます。Unix パスと同様に、これらのセグメントは / で区切られます。セグメントにはワイルドカードとして * を含めることができます。これは、次と一致します。
パスセグメント内のすべての部分文字列（空の部分文字列も含む）。ただし、
ディレクトリ区切り文字 /。このワイルドカードは、1 つのパスセグメント内で複数回使用できます。また、** ワイルドカードは、
0 個以上の完全なパスセグメントを指定できますが、スタンドアロンのものとして宣言する必要があります
作成します
foo/bar.txtは、foo/bar.txtファイルと完全に一致します。 このパッケージ内foo/*.txtは、foo/ディレクトリ内のすべてのファイルに一致します。 ファイルの末尾が.txt（foo/がサブパッケージの場合を除く）foo/a*.htm*は、foo/ディレクトリ内のすべてのファイルに一致します。これらのファイルは、aで始まり、任意の文字列（空でも可）が続き、.htmが続き、別の任意の文字列（foo/axx.htm、foo/a.html、foo/axxx.htmlなど）で終わります。**/a.txtは、このパッケージのすべてのサブディレクトリ内のすべてのa.txtファイルに一致します。**/bar/**/*.txtは、すべての.txtファイルをすべて 生成されたパスに少なくとも 1 つのディレクトリがある場合、このパッケージのbar、xxx/bar/yyy/zzz/a.txtやbar/a.txt（**はゼロにも一致する またはbar/zzz/a.txt**は、このディレクトリのすべてのサブディレクトリ内のすべてのファイルに一致します。 荷物**はセグメントとして単独で存在する必要があるため、foo**/a.txtは無効なパターンです。
exclude_directories 引数が有効になっている（1 に設定されている）場合、ディレクトリ タイプのファイルは結果から除外されます（デフォルト 1）。
allow_empty 引数が False に設定されている場合、結果が空のリストになる場合は、glob 関数はエラーになります。
いくつかの重要な制限事項と注意点があります。
-
glob()は BUILD ファイルの評価中に実行されるため、glob()はソースツリー内のファイルのみを照合し、照合しません。 表示できます。ソースファイルと生成ファイルの両方を必要とするターゲットをビルドする場合は、生成ファイルの明示的なリストを glob に追加する必要があります。例をご覧ください。:mylibと:gen_java_srcsに置き換えます。 -
ルールの名前が一致するソースファイルと同じ名前の場合、ルールはファイルを「シャドー」します。
glob()はパスのリストを返すため、他のルールの属性（srcs = glob(["*.cc"])など）でglob()を使用すると、一致したパスを明示的にリストする場合と同じ効果があります。たとえば、glob()が["Foo.java", "bar/Baz.java"]を生成する場合でも、パッケージに「Foo.java」というルールがある場合（これは許可されていますが、Bazel は警告します）、glob()のコンシューマは「Foo.java」ファイルではなく「Foo.java」ルール（その出力）を使用します。詳しくは、GitHub の問題 #10395 をご覧ください。 - Glob はサブディレクトリ内のファイルと一致する場合があります。サブディレクトリ名にはワイルドカードを使用できます。しかし...
-
ラベルはパッケージの境界を越えることはできず、glob はこれを許可する サブパッケージ内のファイルと一致しない。
たとえば、パッケージ
xの glob 式**/*.ccには、x/yがパッケージ（x/y/BUILDまたは package-path の他の場所）として存在する場合、x/y/z.ccは含まれません。つまり、glob 式の結果は実際には BUILD ファイルの存在に依存します。つまり、x/yというパッケージが存在しない場合や、--deleted_packages フラグを使用して削除済みとしてマークされている場合、同じ glob 式にx/y/z.ccが含まれます。 - 上記の制限は、使用するワイルドカードに関係なく、すべての glob 式に適用されます。
-
ファイル名が
.で始まる隠しファイルは、**ワイルドカードと*ワイルドカードの両方に完全に一致します。隠しファイルを複合パターンと照合する場合は、パターンの先頭を.にする必要があります。たとえば、*と.*.txtは.foo.txtと一致しますが、*.txtは一致しません。非表示のディレクトリも同様に照合されます。非表示のディレクトリには、入力として必要のないファイルが含まれている可能性があります。また、不要なグルーピング ファイルの数とメモリ消費量が増加する可能性があります。除外する 非表示のディレクトリを「exclude」list 引数。 -
「**」ワイルドカードには 1 つの特殊なケースがあります。パターン
"**"がパッケージのディレクトリパスと一致しないケースです。つまり、 たとえば、「glob(["**"], exclude_directories = 0)」はすべてのファイルに一致します 現在のパッケージのディレクトリに推移的 （ただし、サブパッケージのディレクトリには移動しません。前のセクションを参照してください）。 注記を参照）。
通常は、適切な拡張子（*.html など）を指定するようにしてください。 を使用します。より明示的な名前では、 自己記録であり、誤ってバックアップと照合したり emacs/vi/...の自動保存が可能です
ビルドルールを記述するときに、glob の要素を列挙できます。これにより、入力ごとに個別のルールを生成できます。詳しくは、 後述の拡張 glob の例をご覧ください。
glob の例
このディレクトリ内のすべての Java ファイルからビルドされた Java ライブラリを作成します。
:gen_java_srcs ルールによって生成されたすべてのファイルが含まれます。
java_library(
name = "mylib",
srcs = glob(["*.java"]) + [":gen_java_srcs"],
deps = "...",
)
genrule(
name = "gen_java_srcs",
outs = [
"Foo.java",
"Bar.java",
],
...
)
すべての txt ファイルを testdata ディレクトリに含めます（experiment.txt を除く）。 testdata のサブディレクトリ内のファイルは含まれません。これらのファイルを含める場合は、再帰的な glob（**）を使用します。
sh_test(
name = "mytest",
srcs = ["mytest.sh"],
data = glob(
["testdata/*.txt"],
exclude = ["testdata/experimental.txt"],
),
)
再帰的 Glob の例
テストを、testdata ディレクトリ内のすべての TXT ファイルとそのサブディレクトリ（およびそのサブディレクトリなど）に依存させます。BUILD ファイルを含むサブディレクトリは無視されます。（上記の制限事項と注意事項を参照）。
sh_test(
name = "mytest",
srcs = ["mytest.sh"],
data = glob(["testdata/**/*.txt"]),
)
このディレクトリ内のすべての Java ファイルと、 test という名前のディレクトリを含むパスは除きます。 ビルドを削減できるため、このパターンはできるだけ避けてください。 インクリメンタリティが高まり、ビルド時間が長くなります。
java_library(
name = "mylib",
srcs = glob(
["**/*.java"],
exclude = ["**/testing/**"],
),
)
拡張された Glob の例
現在のディレクトリに *_test.cc の個別の genrule を作成し、ファイル内の行数をカウントします。
# Conveniently, the build language supports list comprehensions.
[genrule(
name = "count_lines_" + f[:-3], # strip ".cc"
srcs = [f],
outs = ["%s-linecount.txt" % f[:-3]],
cmd = "wc -l $< >$@",
) for f in glob(["*_test.cc"])]
上記の BUILD ファイルがパッケージ //foo にあり、このパッケージに 3 つの
見つかった後、a_test.cc、b_test.cc、c_test.cc という
bazel query '//foo:all' は、生成されたすべてのルールを一覧表示します。
$ bazel query '//foo:all' | sort //foo:count_lines_a_test //foo:count_lines_b_test //foo:count_lines_c_test
選択
select(
{conditionA: valuesA, conditionB: valuesB, ...},
no_match_error = "custom message"
)
select() は、ルール属性を作成するヘルパー関数です。
構成可能。
画像の右側を置き換えて、
ほぼ
属性の割り当てを行えば、その値がコマンドラインの Bazel フラグに依存するようになります。
たとえば、プラットフォーム固有の依存関係を定義したり、依存関係を
ルールが「developer」に組み込まれているかどうかに応じて、異なるリソースを埋め込む
「release」（リリース）との比較モードです。
基本的な使用方法は次のとおりです。
sh_binary(
name = "mytarget",
srcs = select({
":conditionA": ["mytarget_a.sh"],
":conditionB": ["mytarget_b.sh"],
"//conditions:default": ["mytarget_default.sh"]
})
)
これにより、次の srcs 属性が
通常のラベルを置き換えることで構成可能な sh_binary
リスト割り当てを select 呼び出しでリストします。
照合します。各条件はラベルである
参照先
config_setting または
constraint_value,
「一致する」ターゲットの構成が、想定される一連の
使用できます。mytarget#srcs の値は、
label list は現在の呼び出しと一致します。
注:
- 呼び出しごとに 1 つの条件が選択されます。
- 複数の条件が一致し、そのうちの 1 つが他の条件の特殊化である場合、 スペシャライゼーションが優先されます条件 B は 条件 A の特殊化（B にすべて同じフラグと制約がある場合） 値を A として追加し、追加のフラグまたは制約値として設定できます。また、これは、スペシャライゼーションの解決が、以下の例 2 に示すように順序付けを作成するように設計されていないことを意味します。
- 複数の条件が一致し、1 つが他のすべての条件の特殊化でない場合、すべての条件が同じ値に解決されない限り、Bazel はエラーで失敗します。
- 他の条件が一致しない場合、特別な疑似ラベル
//conditions:defaultが一致と見なされます。この条件が 除外する場合は、エラーを回避するために、他のルールに一致する必要があります。 selectはより大きなサイズの内部に埋め込むことができます 割り当てられています。したがって、srcs = ["common.sh"] + select({ ":conditionA": ["myrule_a.sh"], ...})とsrcs = select({ ":conditionA": ["a.sh"]}) + select({ ":conditionB": ["b.sh"]})は有効な式です。selectはほとんどの属性で動作しますが、すべてではありません。互換性のない属性は、ドキュメントでnonconfigurableとマークされています。サブパッケージ
subpackages(include, exclude=[], allow_empty=True)
subpackages()はglob()に似たヘルパー関数です。 サブパッケージをリストします。同じglob()として指定され、任意のサブパッケージに一致します。 現在読み込み中の BUILD ファイルの直下の子孫である必要があります。include と include の詳細な説明と例については、glob を参照してください。 除外パターンを確認できます返されるサブパッケージのリストは昇順で並べられ、
excludeではなくincludeの指定されたパターンに一致する、現在の読み込みパッケージを基準としたパスが含まれます。例
次の例では、パッケージ
foo/BUILDの直接サブパッケージをすべて一覧表示します。# The following BUILD files exist: # foo/BUILD # foo/bar/baz/BUILD # foo/sub/BUILD # foo/sub/deeper/BUILD # # In foo/BUILD a call to subs = subpackages(include = ["**"]) # results in subs == ["sub", "bar/baz"] # # 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of # 'foo'
一般に、この関数を直接呼び出すのではなく、skylib の「subpackages」モジュールを使用することをおすすめします。