依存関係

ビルド時または実行時に A が B を必要とする場合、ターゲット A はターゲット B に依存します。depends upon 関係は、ターゲットに対して有向非巡回グラフ（DAG）を誘導します。これは依存関係グラフと呼ばれます。

ターゲットの直接依存関係とは、依存関係グラフの長さ 1 のパスで到達可能な他のターゲットです。ターゲットの推移的依存関係とは、グラフ上の任意の長さのパスを通じてターゲットが依存するターゲットです。

実際のところ、ビルドのコンテキストでは、実際の依存関係のグラフと宣言された依存関係のグラフの 2 つの依存関係グラフがあります。ほとんどの場合、2 つのグラフは類似しているため、この区別を行う必要はありませんが、以下の説明では有用です。

実際の依存関係と宣言された依存関係

X を正しくビルドするために Y が存在し、ビルドされ、最新である必要がある場合、ターゲット X は実際にはターゲット Y に依存しています。ビルドとは、生成、処理、コンパイル、リンク、アーカイブ、圧縮、実行など、ビルド中に日常的に発生するタスクのいずれかを指します。

X のパッケージに X から Y への依存関係エッジがある場合、ターゲット X にはターゲット Y に対する宣言された依存関係があります。

正しいビルドの場合、実際の依存関係のグラフ A は、宣言された依存関係のグラフ D のサブグラフである必要があります。つまり、A で直接接続されるノード x --> y のペアはすべて、D で直接接続される必要があります。D は A の過剰近似であると言えます。

BUILD ファイル ライターは、すべてのルールの実際の直接依存関係をすべてビルドシステムに明示的に宣言する必要があります。

この原則に従わないと、未定義の動作が発生します。ビルドが失敗する可能性がありますが、さらに悪いことに、ビルドが以前のオペレーションに依存する可能性があります。また、ターゲットが偶然持っている伝播宣言された依存関係に依存する可能性があります。Bazel は不足している依存関係をチェックし、エラーを報告しますが、このチェックをすべてのケースで完了することはできません。

実行時に A によって必要と判断された場合でも、間接的にインポートされたすべてのものを一覧表示する必要はありません（また、表示しないことをおすすめします）。

ターゲット X のビルド中に、ビルドツールは X の依存関係の完全な推移閉包を検査し、これらのターゲットの変更が最終結果に反映されるようにします。必要に応じて中間ファイルを再ビルドします。

依存関係の推移的な性質が、よくある間違いにつながります。1 つのファイル内のコードが、間接的な依存関係（宣言された依存関係グラフ内の直接エッジではなく、転送エッジ）によって提供されたコードを使用する場合があります。間接的な依存関係は BUILD ファイルに表示されません。ルールはプロバイダに直接依存しないため、次のタイムラインの例に示すように、変更を追跡する方法はありません。

1. 宣言された依存関係が実際の依存関係と一致している

最初はすべて正常に動作します。パッケージ a のコードは、パッケージ b のコードを使用します。パッケージ b のコードはパッケージ c のコードを使用しているため、a は c に間接的に依存しています。

a/BUILD	b/BUILD
rule( name = "a", srcs = "a.in", deps = "//b:b", )	rule( name = "b", srcs = "b.in", deps = "//c:c", )
a / a.in	b / b.in
import b; b.foo();	import c; function foo() { c.bar(); }

宣言された依存関係が実際の依存関係を過剰に近似している。順調です。

2. 宣言されていない依存関係を追加する

c に対する直接の実際の依存関係を作成するコードを a に追加し、ビルドファイル a/BUILD で宣言し忘れると、潜在的なハザードが導入されます。

a / a.in
import b; import c; b.foo(); c.garply();

宣言された依存関係が実際の依存関係を過剰に近似しなくなりました。2 つのグラフの推移閉包が等しいため、この場合、ビルドは正常に完了する可能性がありますが、問題が隠蔽されます。a には c に対する実際の依存関係がありますが、宣言されていません。

3. 宣言された依存関係グラフと実際の依存関係グラフの差異

このハザードは、b をリファクタリングして c に依存しないようにしたときに、自分の過失ではなく、意図せず a を破壊したときに明らかになります。

	b/BUILD
	rule( name = "b", srcs = "b.in", deps = "//d:d", )
	b / b.in
	import d; function foo() { d.baz(); }

宣言された依存関係グラフは、推移的に閉じられている場合でも、実際の依存関係の下限近似になります。ビルドは失敗する可能性があります。

この問題は、ステップ 2 で導入した a から c への実際の依存関係が BUILD ファイルで適切に宣言されていれば回避できたでしょう。

依存関係のタイプ

ほとんどのビルドルールには、さまざまな種類の汎用依存関係を指定する 3 つの属性（srcs、deps、data）があります。以下で説明します。詳細については、すべてのルールに共通する属性をご覧ください。

多くのルールには、compiler や resources など、ルール固有の依存関係を表す追加の属性もあります。詳しくは、Build Encyclopedia をご覧ください。

srcs の依存関係

ソースファイルを出力するルールによって直接使用されるファイル。

deps 依存関係

ヘッダー ファイル、シンボル、ライブラリ、データなどを提供する、個別にコンパイルされたモジュールを指すルール。

data 依存関係

ビルド ターゲットが正しく実行するために、データファイルが必要になる場合があります。これらのデータファイルはソースコードではなく、ターゲットのビルド方法には影響しません。たとえば、単体テストでは、関数の出力をファイルの内容と比較できます。単体テストをビルドするときにはファイルは必要ありませんが、テストを実行するときには必要です。実行中に起動するツールについても同様です。

ビルドシステムは、data としてリストされているファイルのみが使用可能な分離されたディレクトリでテストを実行します。したがって、バイナリ、ライブラリ、テストを実行するためにファイルが必要な場合は、data でそれらのファイル（またはそれらを含むビルドルール）を指定します。例:

# I need a config file from a directory named env:
java_binary(
    name = "setenv",
    ...
    data = [":env/default_env.txt"],
)

# I need test data from another directory
sh_test(
    name = "regtest",
    srcs = ["regtest.sh"],
    data = [
        "//data:file1.txt",
        "//data:file2.txt",
        ...
    ],
)

これらのファイルには、相対パス path/to/data/file を使用してアクセスできます。テストでは、テストのソース ディレクトリのパスとワークスペース相対パスを結合して、これらのファイルを参照できます（例: ${TEST_SRCDIR}/workspace/path/to/data/file）。

ラベルを使用してディレクトリを参照する

BUILD ファイルを調べると、一部の data ラベルがディレクトリを参照していることがわかります。次の例のように、これらのラベルは /. または / で終わります。使用しないでください。

非推奨 - data = ["//data/regression:unittest/."]

非推奨 - data = ["testdata/."]

非推奨 - data = ["testdata/"]

これは、テストでディレクトリ内のすべてのデータファイルを使用できるため、特にテストに便利です。

ただし、このようなことは行わないでください。変更後に適切な増分再ビルド（およびテストの再実行）を確実に行うには、ビルドシステムが、ビルド（またはテスト）への入力であるファイルの完全なセットを認識している必要があります。ディレクトリを指定すると、ファイルの追加や削除によってディレクトリ自体が変更された場合にのみ再ビルドが実行されますが、個々のファイルに対する編集は、それを含むディレクトリには影響しないため、個々のファイルの編集は検出できません。ビルドシステムへの入力としてディレクトリを指定するのではなく、明示的に、または glob() 関数を使用して、ディレクトリ内に含まれるファイルのセットを列挙する必要があります。（** を使用して、glob() を強制的に再帰にします）。

推奨 - data = glob(["testdata/**"])

残念ながら、シナリオによってはディレクトリ ラベルを使用しなければなりません。たとえば、testdata ディレクトリに、名前がラベル構文に準拠していないファイルが含まれている場合、ファイルの明示的な列挙または glob() 関数の使用により、無効なラベルエラーが発生します。この場合はディレクトリ ラベルを使用する必要がありますが、前述の誤った再ビルドに伴うリスクに注意してください。

ディレクトリラベルを使用する必要がある場合は、相対 ../ パスで親パッケージを参照することはできません。代わりに、//data/regression:unittest/. などの絶対パスを使用します。

複数のファイルを使用する必要があるテストなどの外部ルールは、それらすべてへの依存関係を明示的に宣言する必要があります。filegroup() を使用して、BUILD ファイルでファイルをグループ化できます。

filegroup(
        name = 'my_data',
        srcs = glob(['my_unittest_data/*'])
)

これにより、テストでデータの依存関係としてラベル my_data を参照できます。