関数

問題を報告する ソースを表示 ナイトリー · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

目次

パッケージ

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 属性で参照できます。

パッケージ グループは、主に公開設定に使用されます。一般公開されている ターゲットはソースツリー内のすべてのパッケージから参照できます。非公開で公開されるターゲットは、独自のパッケージ（サブパッケージではない）内でのみ参照できます。これらの極端な例の中間では、ターゲットは独自のパッケージに加えて、1 つ以上のパッケージ グループで記述されたパッケージへのアクセスを許可できます。詳細については、 説明については、このモジュールの 可視性 属性です。

グループに含まれるのは、 packages 属性、またはすでに他 1 つの属性に含まれています 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 のサブパッケージがすべて含まれます。 //foo/tests のサブパッケージ。（//foo 自体は //foo/tests 自体は含まれません）。

公開設定のほか、バージョン 4 に 外部にデプロイされます

この属性が指定されていない場合、空のリストに設定した場合と同じになります。これは、private のみを含むリストに設定した場合と同じです。

注: Bazel 6.0 より前のバージョンでは、//... には、public と同じ従来の動作がありました。この 動作は修正されました。 --incompatible_fix_package_group_reporoot_syntax は 有効（Bazel 6.0 より後のデフォルト）です。

注: Bazel 6.0 より前は、この属性が bazel query --output=proto（または --output=xml）の一部としてシリアル化される場合、先頭のスラッシュは省略されます。対象 //pkg/foo/... は次のように出力されます。 \"pkg/foo/...\"。この動作は、次の場合に修正されます。 --incompatible_package_group_includes_double_slash は 有効（Bazel 6.0 より後のデフォルト）です。
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.txt、 テキスト ファイルが test_data パッケージから提供されるため、 パッケージで、たとえば data 属性内で使用できます。 含まれています。 

# from //test_data/BUILD

exports_files(["golden.txt"])

glob

glob(include, exclude=[], exclude_directories=1, allow_empty=True)

glob は、特定のパスパターンに一致するすべてのファイルを検索するヘルパー関数です。 このメソッドは、パスの新しい変更可能な並べ替え済みリストを返します。Glob は、独自のパッケージ内のファイルのみを検索し、ソースファイルのみを検索します（生成されたファイルや他のターゲットではありません）。

ソースファイルのラベルは、ファイルのパッケージ相対 URL が結果に含まれる場合、 path は 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.htm、foo/a.html、foo/axxx.html
  • foo/* は foo/ ディレクトリ内のすべてのファイルに一致します。 （foo/ がサブパッケージの場合を除く）。foo と一致しません exclude_directories が次のように設定されていても、ディレクトリ自体に 0
  • foo/** は、パッケージの最初のレベルのサブディレクトリ foo/ の下にあるサブパッケージ以外のすべてのサブディレクトリ内のすべてのファイルに一致します。exclude_directories が 0 に設定されている場合、foo ディレクトリ自体もパターンに一致します。この場合、** はゼロのパスセグメントに一致します。
  • **/a.txt は、このパッケージの a.txt 個のファイルに一致します 非サブパッケージサブディレクトリです。
  • **/bar/**/*.txt は、結果パスのディレクトリが 1 つ以上 bar（xxx/bar/yyy/zzz/a.txt、bar/a.txt、**（** はゼロ セグメントにも一致します）など）と呼ばれている場合、このパッケージのサブパッケージ以外のすべてのサブディレクトリ内のすべての .txt ファイルに一致します。bar/zzz/a.txt
  • ** は、 このパッケージ
  • foo**/a.txt は無効なパターンです。** は セグメントとして独立していて
  • foo/ は無効なパターンです。2 番目のセグメントで定義されているためです / の後ろは空の文字列

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 はこれを許可する サブパッケージ内のファイルと一致しない。

    たとえば、パッケージ内の glob 式 **/*.cc は、 次の場合、x に x/y/z.cc は含まれません。 x/y はパッケージとして存在します（または x/y/BUILD、または package-path の別の場所）。この glob 式の結果は、実際の依存関係に BUILD ファイルが存在することを意味します。つまり、同じ glob 式が 呼び出されたパッケージがない場合は x/y/z.cc を含めます。 x/y であるか、 --deleted_packages 設定されます。

  5. 上記の制限は、使用するワイルドカードに関係なく、すべての glob 式に適用されます。
  6. ファイル名が . で始まる隠しファイルは、** ワイルドカードと * ワイルドカードの両方に完全に一致します。隠しファイルを複合パターンと照合する場合は、パターンの先頭を . にする必要があります。たとえば * と .*.txt は .foo.txt と一致しますが、*.txt と一致します。 できません。 隠しディレクトリも同様に照合されます。隠しディレクトリ 入力として不要なファイルが含まれていることがあり、 メモリ消費量を削減できます非表示のディレクトリを除外するには、それらを「除外」リスト引数に追加します。
  7. 「**」ワイルドカードには 1 つの特殊なケースがあります。パターン "**" がパッケージのディレクトリパスと一致しないことです。つまり、glob(["**"], exclude_directories = 0) は、現在のパッケージのディレクトリの下にあるすべてのファイルとディレクトリと厳密に、転送で一致します（ただし、サブパッケージのディレクトリには入りません。この点については、前述の注記をご覧ください）。

通常は、適切な拡張子（*.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"]),
)

このディレクトリ内のすべての Java ファイルと、パスに testing というディレクトリが含まれていないすべてのサブディレクトリからビルドされたライブラリを作成します。ビルドを削減できるため、このパターンはできるだけ避けてください。 インクリメンタリティが高まり、ビルド時間が長くなります。 

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 の値は、現在の呼び出しに一致するラベルリストになります。

注:

  • 呼び出しごとに 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 をご覧ください。

    返されるサブパッケージのリストは並べ替えられ、次の内容が含まれます 現在の読み込みパッケージからの相対パスで、 include であり、exclude 内のものは対象外です。

    例

    次の例では、パッケージ 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