目次
パッケージ
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
属性で参照できます。
パッケージ グループは主に公開設定に使用されます。一般公開されているターゲットは、ソースツリー内のすべてのパッケージから参照できます。非公開ターゲットは、それ自体のパッケージ内でのみ参照できます(サブパッケージ内では参照できません)。この 2 つが極端な場合、ターゲットは自身のパッケージに加えて、1 つ以上のパッケージ グループによって記述されるパッケージへのアクセスも許可できます。公開設定システムの詳細については、visibility 属性をご覧ください。
packages
属性と一致するか、includes
属性で指定された他のパッケージ グループのいずれかにすでに含まれているパッケージは、グループに属していると見なされます。
パッケージ グループは技術的にはターゲットですが、ルールによって作成されるわけではなく、また、それ自体が可視性を保護することもありません。
引数
属性 | 説明 |
---|---|
name |
名前(必須) このターゲットの一意の名前。 |
packages |
文字列のリスト。デフォルトは 0 個以上のパッケージ仕様のリスト。 各パッケージ仕様の文字列は、次のいずれかの形式になります。
また、最初の 2 種類のパッケージ仕様には、それらが否定であることを示す接頭辞 パッケージ グループには、正の仕様の少なくとも 1 つに一致し、負の仕様のいずれにも一致しないパッケージが含まれます。たとえば、値 一般公開される以外に、現在のリポジトリの外部にあるパッケージを直接指定する方法はありません。 この属性がない場合は、空のリストに設定するのと同じになり、 注: 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
が反転するまで、デフォルトの公開設定でエクスポートされます。ただし、この動作に依存せず、積極的に移行しないでください。
引数
引数は、現在のパッケージ内のファイルの名前のリストです。公開設定の宣言を指定することもできます。この場合、ファイルは指定したターゲットに表示されます。公開設定が指定されていない場合、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
は、結果のパスにある少なくとも 1 つのディレクトリがbar
である場合、このパッケージのすべてのサブディレクトリ内のすべての.txt
ファイルに一致します(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/y
がパッケージとして(x/y/BUILD
または package-path の別の場所に)存在している場合、パッケージx
内の glob 式**/*.cc
にx/y/z.cc
は含まれません。つまり、glob 式の結果は、実際には BUILD ファイルの存在に依存します。つまり、x/y
というパッケージが存在しない場合、または --deleted_packages フラグを使用して削除済みとしてマークされている場合、同じ glob 式にx/y/z.cc
が含まれます。 - 上記の制限は、使用するワイルドカードに関係なく、すべての glob 式に適用されます。
-
ファイル名が
.
で始まる隠しファイルは、**
と*
の両方のワイルドカードと完全に一致します。隠しファイルを複合パターンに一致させるには、パターンを.
で始める必要があります。たとえば、*
と.*.txt
は.foo.txt
と一致しますが、*.txt
は一致しません。 非表示のディレクトリも、同じ方法で照合されます。隠しディレクトリには、入力として不要なファイルが含まれている場合があり、不必要にグロブされたファイルの数とメモリ消費量が増加する可能性があります。非表示のディレクトリを除外するには、除外リスト引数に追加します。 -
「**」ワイルドカードには特殊なケースが 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", ], ... )
testal.txt を除くすべての txt ファイルを testdata ディレクトリに含めます。 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"]), )
このディレクトリと、tests という名前のディレクトリがパスに含まれているすべてのサブディレクトリを除くすべての Java ファイルからビルドされたライブラリを作成します。このパターンは、ビルドの増分を減らし、ビルド時間が長くなる可能性があるため、できる限り避けてください。
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
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 つの条件が選択されます。
- 複数の条件が一致し、そのうちの 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」モジュールを使用することをおすすめします。