関数

問題を報告する ソースを表示

目次

パッケージ

package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)

この関数は、パッケージ内のすべてのルールに適用されるメタデータを宣言します。パッケージ(BUILD ファイル)内で使用されるのは 1 回だけです。

リポジトリ内のすべてのルールに適用するメタデータを宣言する場合は、リポジトリのルートにある REPO.bazel ファイルrepo() 関数を使用します。repo() 関数は、package() とまったく同じ引数を受け取ります。

package() 関数は、ファイルの先頭にあるすべての load() ステートメントの直後、ルールよりも前に呼び出す必要があります。

引数

属性 説明
default_applicable_licenses

default_package_metadata のエイリアス。

default_visibility

ラベルのリスト。デフォルトは [] です。

このパッケージ内のルールのデフォルトの公開設定。

ルールの visibility 属性で特に指定されていない限り、このパッケージ内のすべてのルールは、この属性で指定された公開設定を持ちます。この属性の構文の詳細については、visibility のドキュメントをご覧ください。 パッケージのデフォルトの公開設定は、デフォルトで一般公開される exports_files には適用されません。

default_deprecation

文字列。デフォルトは ""

このパッケージ内のすべてのルールにデフォルトの deprecation メッセージを設定します。

default_package_metadata

ラベルのリスト。デフォルトは [] です。

パッケージ内の他のすべてのターゲットに適用されるメタデータ ターゲットのデフォルト リストを設定します。これらは通常、OSS パッケージとライセンスの宣言に関連するターゲットです。例については、rules_license をご覧ください。

default_testonly

ブール値。特に明記されていない限り、デフォルトは False です。

このパッケージのすべてのルールにデフォルトの testonly プロパティを設定します。

javatests の下のパッケージでのデフォルト値は True です。

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 個以上のパッケージ仕様のリスト。

各パッケージ仕様の文字列は、次のいずれかの形式になります。

  1. ダブル スラッシュで始まる、リポジトリを含まないパッケージの完全な名前。たとえば、//foo/bar はその名前を持ち、パッケージ グループと同じリポジトリに存在するパッケージを指定します。
  2. 上記と同じですが、末尾に /... が付きます。たとえば、 //foo/...//foo とそのすべてのサブパッケージのセットを指定します。//... は、現在のリポジトリ内のすべてのパッケージを指定します。
  3. 文字列 public または private。それぞれすべてのパッケージを指定するか、パッケージを指定しません。(このフォームでは、--incompatible_package_group_has_public_syntax フラグを設定する必要があります)。

また、最初の 2 種類のパッケージ仕様には、それらが否定であることを示す接頭辞 - を付けることもできます。

パッケージ グループには、正の仕様の少なくとも 1 つに一致し、負の仕様のいずれにも一致しないパッケージが含まれます。たとえば、値 [//foo/..., -//foo/tests/...] には、//foo/tests のサブパッケージではない //foo のすべてのサブパッケージが含まれます。(//foo 自体は含まれますが、//foo/tests 自体は含まれません)。

一般公開される以外に、現在のリポジトリの外部にあるパッケージを直接指定する方法はありません。

この属性がない場合は、空のリストに設定するのと同じになり、private のみを含むリストに設定するのと同じになります。

注: Bazel 6.0 より前のバージョンでは、//... の仕様は public と同じ動作でした。この動作は、Bazel 6.0 以降でデフォルトである --incompatible_fix_package_group_reporoot_syntax が有効な場合に修正されます。

注: Bazel 6.0 より前では、この属性が bazel query --output=proto(または --output=xml)の一部としてシリアル化されている場合、先頭のスラッシュは省略されます。たとえば、//pkg/foo/...\"pkg/foo/...\" として出力されます。この動作は、Bazel 6.0 以降でデフォルトである --incompatible_package_group_includes_double_slash が有効な場合に修正されます。

includes

ラベルのリスト。デフォルトは [] です。

このパッケージに含まれる他のパッケージ グループです。

この属性のラベルは、他のパッケージ グループを参照する必要があります。 参照されたパッケージ グループのパッケージは、このパッケージ グループの一部になります。これは推移的です。パッケージ グループ a にパッケージ グループ b が含まれ、b にパッケージ グループ c が含まれている場合、c 内のすべてのパッケージも a のメンバーになります。

否定されたパッケージ仕様と併用する場合、各グループのパッケージのセットは最初に個別に計算され、その後で結果が結合されます。つまり、あるグループ内で反転された仕様が、別のグループの仕様に作用することはありません。

次の 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.txttest_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/ がサブパッケージの場合を除く)。
  • foo/*.txt は、ファイルが .txt で終わる場合、foo/ ディレクトリ内のすべてのファイルに一致します(foo/ がサブパッケージである場合を除く)。
  • foo/a*.htm* は、foo/ ディレクトリ内で、a で始まり、任意の文字列(空でもかまいません)、.htm、そして別の任意の文字列(foo/ がサブパッケージである場合を除く)で終わるすべてのファイルに一致します。例: foo/axx.htmfoo/a.htmlfoo/axxx.html
  • foo/* は、foo/ ディレクトリ内のすべてのファイルに一致します(foo/ がサブパッケージの場合を除く)。exclude_directories が 0 に設定されていても、foo ディレクトリ自体には一致しません。
  • foo/** は、パッケージの最初のレベルのサブディレクトリ foo/ の下にあるすべてのサブパッケージ以外のサブディレクトリ内のすべてのファイルと一致します。exclude_directories が 0 に設定されている場合、foo ディレクトリ自体もパターンと一致します。この場合、** はゼロパス セグメントと一致するとみなされます。
  • **/a.txt は、このパッケージのディレクトリにある a.txt ファイルと、サブパッケージ以外のサブディレクトリに一致します。
  • **/bar/**/*.txt は、生成されたパスの少なくとも 1 つのディレクトリが bar である場合、このパッケージのすべてのサブパッケージ以外のサブディレクトリにあるすべての .txt ファイルに一致します。たとえば、xxx/bar/yyy/zzz/a.txtbar/a.txt** もゼロセグメントと一致します)、bar/zzz/a.txt などです。
  • ** は、このパッケージのすべてのサブパッケージ以外のサブディレクトリにあるすべてのファイルに一致します。
  • ** は単独でセグメントとして維持される必要があるため、foo**/a.txt は無効なパターンです。
  • / の後に定義される 2 番目のセグメントが空の文字列であるため、foo/ は無効なパターンです。

exclude_directories 引数が有効な場合(1 に設定)、ディレクトリ タイプのファイルは結果から除外されます(デフォルトは 1)。

allow_empty 引数が False に設定されている場合、結果が空リストになると glob 関数はエラーになります。

いくつかの重要な制限事項と注意点があります。

  1. glob() は BUILD ファイルの評価中に実行されるため、glob() はソースツリー内のファイルのみに一致し、生成されたファイルには一致しません。ソースファイルと生成ファイルの両方を必要とするターゲットをビルドする場合は、生成されたファイルの明示的なリストを glob に追加する必要があります。:mylib:gen_java_srcs を含む以下のをご覧ください。

  2. ルールの名前が一致したソースファイルと同じ名前の場合、ルールはそのファイルを「シャドウ」します。

    glob() はパスのリストを返すため、他のルールの属性(srcs = glob(["*.cc"]) など)で glob() を使用すると、一致したパスを明示的に一覧表示する場合と同じ効果があります。たとえば、glob()["Foo.java", "bar/Baz.java"] を生成するが、パッケージ内に「Foo.java」というルールもある場合(これは許可されていますが、Bazel が警告している場合)、glob() のコンシューマは「Foo.java」ファイルの代わりに「Foo.java」ルール(その出力)を使用します。詳しくは、GitHub の問題 #10395 をご覧ください。

  3. glob は、サブディレクトリ内のファイルと一致する場合があります。サブディレクトリ名はワイルドカードに 使用できますただし...
  4. ラベルはパッケージの境界を越えることはできず、glob はサブパッケージ内のファイルと一致しません。

    たとえば、x/y がパッケージとして(x/y/BUILD または package-path の別の場所に)存在している場合、パッケージ x 内の glob 式 **/*.ccx/y/z.cc は含まれません。つまり、glob 式の結果は、実際には BUILD ファイルの存在に依存します。つまり、x/y というパッケージが存在しない場合、または --deleted_packages フラグを使用して削除済みとしてマークされている場合、同じ glob 式に x/y/z.cc が含まれます。

  5. 上記の制限は、使用するワイルドカードに関係なく、すべての glob 式に適用されます。
  6. ファイル名が . で始まる隠しファイルは、*** の両方のワイルドカードと完全に一致します。隠しファイルを複合パターンに一致させるには、パターンを . で始める必要があります。たとえば、*.*.txt.foo.txt と一致しますが、*.txt は一致しません。 非表示のディレクトリも、同じ方法で照合されます。隠しディレクトリには、入力として不要なファイルが含まれている場合があり、不必要にグロブされたファイルの数とメモリ消費量が増加する可能性があります。非表示のディレクトリを除外するには、除外リスト引数に追加します。
  7. 「**」ワイルドカードには特殊なケースが 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_binarysrcs 属性を構成できるようになります。各条件は、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/bar/but/bad/BUILD
    # foo/sub/BUILD
    # foo/sub/deeper/BUILD
    #
    # In foo/BUILD a call to
    subs1 = subpackages(include = ["**"])
    
    # results in subs1 == ["sub", "bar/baz", "bar/but/bad"]
    #
    # 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of
    # 'foo'
    
    subs2 = subpackages(include = ["bar/*"])
    # results in subs2 = ["bar/baz"]
    #
    # Since 'bar' is not a subpackage itself, this looks for any subpackages under
    # all first level subdirectories of 'bar'.
    
    subs3 = subpackages(include = ["bar/**"])
    # results in subs3 = ["bar/baz", "bar/but/bad"]
    #
    # Since bar is not a subpackage itself, this looks for any subpackages which are
    # (1) under all subdirectories of 'bar' which can be at any level, (2) not a
    # subpackage of another subpackages.
    
    subs4 = subpackages(include = ["sub"])
    subs5 = subpackages(include = ["sub/*"])
    subs6 = subpackages(include = ["sub/**"])
    # results in subs4 and subs6 being ["sub"]
    # results in subs5 = [].
    #
    # In subs4, expression "sub" checks whether 'foo/sub' is a package (i.e. is a
    # subpackage of 'foo').
    # In subs5, "sub/*" looks for subpackages under directory 'foo/sub'. Since
    # 'foo/sub' is already a subpackage itself, the subdirectories will not be
    # traversed anymore.
    # In subs6, 'foo/sub' is a subpackage itself and matches pattern "sub/**", so it
    # is returned. But the subdirectories of 'foo/sub' will not be traversed
    # anymore.
    

    通常は、この関数を直接呼び出すのではなく、skylib の「subpackages」モジュールを使用することをおすすめします。