目次
パッケージ
package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)
この関数は、パッケージ内のすべてのルールに適用されるメタデータを宣言します。パッケージ（BUILD ファイル）内で最大 1 回使用されます。
リポジトリ全体のすべてのルールに適用されるメタデータを宣言する場合は、リポジトリのルートにある REPO.bazel ファイルの repo() 関数を使用します。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 属性と一致する場合、または 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"],
)
exports_files
exports_files([label, ...], visibility, licenses)
exports_files() には、このパッケージに属するファイルのうち、他のパッケージにエクスポートされるファイルのリストを指定します。
パッケージの BUILD ファイルは、exports_files() ステートメントで明示的にエクスポートされた場合にのみ、別のパッケージに属するソースファイルを直接参照できます。詳細については、ファイルの公開設定をご覧ください。
従来の動作として、ルールの入力として言及されているファイルも、フラグ --incompatible_no_implicit_file_export が反転するまでデフォルトの公開設定のままエクスポートされます。ただし、この動作に依拠せず、積極的に移行すべきではありません。
引数
この引数は、現在のパッケージ内のファイルの名前のリストです。可視性の宣言を指定することもできます。この場合、指定したターゲットにファイルが表示されます。公開設定が指定されていない場合、パッケージのデフォルトの公開設定が 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ファイルと完全に一致します。- ファイルが
.txtで終わる場合、foo/*.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（**もゼロセグメントにも一致します）、bar/zzz/a.txtなどのbarという名前のディレクトリが 1 つ以上ある場合、一致します。**は、このパッケージのすべてのサブディレクトリ内のすべてのファイルに一致します。**がセグメントとして単独で存在する必要があるため、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 式の結果は、実際には BUILD ファイルの有無に依存します。つまり、x/yというパッケージが存在しない場合、または --deleted_packages フラグを使用して削除済みとしてマークされている場合、同じ glob 式にx/y/z.ccが含まれます。 - 上記の制限は、使用するワイルドカードに関係なく、すべての glob 式に適用されます。
-
ファイル名が
.で始まる非表示ファイルは、**ワイルドカードと*ワイルドカードの両方で完全に一致します。非表示のファイルを複合パターンと照合するには、パターンを.で始める必要があります。たとえば、*と.*.txtは.foo.txtと一致しますが、*.txtは一致しません。隠しディレクトリも同様に照合されます。隠しディレクトリには、入力として不要なファイルが含まれていることがあり、不必要にグロブされるファイルの数やメモリ消費量が増加する可能性があります。非表示のディレクトリを除外するには、それらを「exclude」リスト引数に追加します。 -
ワイルドカード「**」には特殊なケースが 1 つあります。パターン
"**"は、パッケージのディレクトリ パスと一致しません。つまり、glob(["**"], exclude_directories = 0)は、現在のパッケージのディレクトリの下にあるすべてのファイルとディレクトリを推移的に照合します（ただし、サブパッケージのディレクトリには移動しません。これについては前述の注をご覧ください）。
glob パターンでは、基本的な「*」を使用するのではなく、適切な拡張子（*.html など）を指定する必要があります。より明示的な名前は、自己文書化的であり、バックアップ ファイルや emacs/vi/... 自動保存ファイルを誤って一致させないようにします。
ビルドルールを記述するときに、glob の要素を列挙できます。これにより、たとえば入力ごとに個別のルールを生成できます。以下の展開された 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",
],
...
)
すべての 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"]),
)
このディレクトリと、パスに 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"])]
上記のビルド ファイルがパッケージ //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
select(
{conditionA: valuesA, conditionB: valuesB, ...},
no_match_error = "custom message"
)
select() は、ルール属性を構成可能にするヘルパー関数です。これは、ほぼすべての属性割り当ての右側を置き換えることができるため、その値はコマンドラインの Bazel フラグに依存します。
たとえば、プラットフォーム固有の依存関係を定義したり、ルールが「デベロッパー」モードと「リリース」モードのどちらでビルドされたかに応じて異なるリソースを埋め込むことができます。
基本的な使用方法は次のとおりです。
sh_binary(
name = "mytarget",
srcs = select({
":conditionA": ["mytarget_a.sh"],
":conditionB": ["mytarget_b.sh"],
"//conditions:default": ["mytarget_default.sh"]
})
)
これにより、通常のラベルリストの割り当てを、構成条件を一致する値にマッピングする select 呼び出しに置き換えることで、sh_binary の srcs 属性を構成できるようになります。各条件は 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」モジュールを使用することをおすすめします。