目次
パッケージ
package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)
この関数は、パッケージ内のすべての後続のルールに適用されるメタデータを宣言します。パッケージ（BUILD ファイル）内で使用されるのは 1 回だけです。
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 つ以上のパッケージ グループで記述されたパッケージへのアクセスを許可できます。可視性システムの詳細については、visibility 属性をご覧ください。
packages 属性と一致するパッケージ、または includes 属性で指定された他のパッケージ グループのいずれかにすでに含まれているパッケージは、グループに含まれているとみなされます。
パッケージ グループは厳密にはターゲットですが、ルールによって作成されることはありません。また、パッケージ自体の可視性も保護されません。
引数
| 属性 | 説明 |
|---|---|
name |
このターゲットの一意の名前。 |
packages |
0 個以上のパッケージ仕様のリスト。 各パッケージ仕様の文字列は、次のいずれかの形式になります。
また、最初の 2 種類のパッケージ仕様には、否定されたことを示すために パッケージ グループには、ポジティブ仕様の少なくとも 1 つとネガティブ仕様のいずれも一致しないパッケージが含まれています。たとえば、値 一般公開される以外に、現在のリポジトリの外部でパッケージを直接指定する方法はありません。 この属性がない場合は、空のリストに設定するのと同じで、 注: Bazel 6.0 より前の仕様では、 注: Bazel 6.0 より前のバージョンでは、この属性が |
includes |
このパッケージに含まれている他のパッケージ グループ。 この属性のラベルは、他のパッケージ グループを参照する必要があります。
参照されたパッケージ グループのパッケージは、このパッケージ グループの一部と見なされます。これは推移的です。パッケージ グループ パッケージ化されたパッケージの仕様と併用すると、各グループのパッケージのセットはまず個別に計算され、その結果がまとめて表示されることに注意してください。つまり、あるグループの無効化条件が別のグループの仕様に影響することはありません。 |
例
次の package_group 宣言では、熱帯果実を含む「tropical」と呼ばれるパッケージ グループを指定します。
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"],
)
export_files
exports_files([label, ...], visibility, licenses)
exports_files() には、他のパッケージにエクスポートされるこのパッケージに属するファイルのリストを指定します。
パッケージの BUILD ファイルは、exports_files() ステートメントで明示的にエクスポートされた場合にのみ、別のパッケージに属するソースファイルを直接参照できます。詳しくは、ファイルの公開設定をご覧ください。
従来の動作では、ルールへの入力として言及されているファイルも、--incompatible_no_implicit_file_export フラグが反転されるまでデフォルトの可視性でエクスポートされます。ただし、この動作は依存せず、アクティブに移行すべきではありません。
引数
引数は、現在のパッケージ内のファイルの名前のリストです。視認性の宣言も指定できます。この場合、指定したターゲットにファイルが表示されます。公開設定を指定しないと、パッケージのデフォルトの公開設定が package 関数で指定されていても、ファイルはすべてのパッケージに表示されます。ライセンスも指定できます。
例
次の例では、golden.txt（test_data パッケージのテキスト ファイル）をエクスポートします。これにより、他のパッケージがテストの 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は、ファイルの末尾が.txtの場合、foo/ディレクトリ内のすべてのファイルと一致します（foo/がサブパッケージの場合を除く）。foo/a*.htm*は、foo/ディレクトリ内で、aで始まり、任意の文字列（空でも可）、.htmで終わり、別の任意の文字列（foo/axx.htm、foo/a.html、foo/axxx.htmlなど）で終わるすべてのファイルと一致します。**/a.txtは、このパッケージのすべてのサブディレクトリにあるすべてのa.txtファイルと一致します。**/bar/**/*.txtは、このパッケージのすべてのサブディレクトリにあるすべての.txtファイルと一致します。xxx/bar/yyy/zzz/a.txtやbar/a.txtのように、生成されるパスの少なくとも 1 つがbarと呼ばれる場合（**もゼロ セグメントと一致する）、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/yがパッケージとして（x/y/BUILDや、パッケージパスの他の場所）存在する場合、パッケージxの glob 式**/*.ccにx/y/z.ccは含まれません。つまり、glob 式の結果は、実際にビルドファイルが存在するかどうかに依存します。つまり、x/yというパッケージがない場合や、--delete_packages フラグを使用して削除済みとしてマークされている場合、同じ glob 式にはx/y/z.ccが含まれます。 - 上記の制限は、使用するワイルドカードに関係なく、すべての glob 式に適用されます。
-
ファイル名が
.で始まる隠しファイルは、**ワイルドカードと*ワイルドカードの両方と完全に一致します。隠しファイルを複合パターンに一致させるには、パターンを.で始める必要があります。たとえば、*と.*.txtは.foo.txtと一致しますが、*.txtは一致しません。 非表示のディレクトリについても同様です。隠しディレクトリは、入力として不要なファイルを含む可能性があり、不要なグローブ ファイルの数とメモリ消費量を増加させる可能性があります。非表示のディレクトリを除外するには、「excluded」リスト引数に追加します。 -
ワイルドカード :** のパターンには、パターン
"**"がパッケージのディレクトリ パスと一致しないという特殊なケースがあります。つまり、glob(["**"], exclude_directories = 0)は、すべてのファイルとディレクトリを現在のパッケージのディレクトリの推移と完全に一致させます（ただし、当然ながら、サブパッケージのディレクトリには移動しません。これについては前述の注をご覧ください）。
通常は、glob パターンにベアメタル「*」を使用する代わりに、適切な拡張子（*.html など）を指定するようにしてください。明示的な名前は自己文書化であり、バックアップ ファイルや emacs/vi/... 自動保存ファイルを誤って一致させないようにします。
ビルドルールを記述する際に、glob の要素を列挙できます。これにより、たとえば、入力ごとに個別のルールを生成できます。下の expanded glob の例をご覧ください。
Glob の例
このディレクトリ内のすべての Java ファイルと、:gen_java_srcs ルールによって生成されたすべてのファイルから構築された Java ライブラリを作成します。
java_library(
name = "mylib",
srcs = glob(["*.java"]) + [":gen_java_srcs"],
deps = "...",
)
genrule(
name = "gen_java_srcs",
outs = [
"Foo.java",
"Bar.java",
],
...
)
experimental.txt を除くすべての txt ファイルをディレクトリ testdata に含めます。 testdata のサブディレクトリにあるファイルは含まれません。これらのファイルを含める場合は、再帰 glob（**）を使用します。
sh_test(
name = "mytest",
srcs = ["mytest.sh"],
data = glob(
["testdata/*.txt"],
exclude = ["testdata/experimental.txt"],
),
)
再帰 Glob の例
テストは、testdata ディレクトリとその 1 つ下のサブディレクトリにあるすべての 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 にあり、パッケージに a_test.cc、b_test.cc、c_test.cc の 3 つの一致するファイルが含まれている場合、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
select(
{conditionA: valuesA, conditionB: valuesB, ...},
no_match_error = "custom message"
)
select() は、ルール属性を構成可能にするヘルパー関数です。ほぼすべての属性割り当ての右側を置き換えることができるため、その値はコマンドラインの Bazel フラグに依存します。たとえば、プラットフォーム固有の依存関係を定義する場合や、「ルール」が「release」モードと「release」モードのどちらであるかに応じて異なるリソースを埋め込んだりできます。
基本的な使い方は次のとおりです。
sh_binary(
name = "mytarget",
srcs = select({
":conditionA": ["mytarget_a.sh"],
":conditionB": ["mytarget_b.sh"],
"//conditions:default": ["mytarget_default.sh"]
})
)
これにより、sh_binary の srcs 属性を通常のラベルリスト割り当てを select 呼び出しに置き換えて、構成条件を一致する値にマッピングすることで構成できます。各条件は config_setting または constraint_value へのラベル参照で、ターゲットの構成が期待される値のセットと一致する場合に「一致」します。mytarget#srcs の値は、現在の呼び出しに一致するラベルリストになります。
注:
- 呼び出し時に 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 ファイルの直接の子孫である任意のサブパッケージと一致します。追加パターンと除外パターンの詳細については、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」モジュールを使用することをおすすめします。