如果 A 在建構或建構時需要 B，則目標 A「取決於」目標 B
執行時間。取決於關係
有向非循環圖
(DAG) 取代目標，也稱為依附元件圖表。
目標的「直接」依附元件是指可透過路徑連上的其他目標 依附元件圖表中。目標的「遞移」依附元件為 透過圖表中任何長度的路徑來判定的指定目標。
事實上，在建構作業中，有兩種依附元件圖表 「實際依附元件」和「宣告的依附元件」圖表。大部分 這兩個圖表很相似，因此無須做出這項區別，但 這對於進行下方的討論會很有幫助。
實際和宣告的依附元件
如果必須含有 Y，目標 X 就實際上取決於目標 Y。
以便確保 X 能正確建構。已打造
均產生、處理、編譯、連結、封存、壓縮、執行，或是
任何在建構期間經常執行的作業。
如果有依附元件，目標 X 在目標 Y 上具有宣告的依附元件
X 套件中的邊緣從 X 到 Y。
如要正確建構，實際依附元件 A 的圖表必須是
宣告的依附元件 D 的圖表。也就是說
直接連結節點 x --> y (位於 A) 也必須
D：儘管 D 是 A 的高估值，
BUILD 檔案寫入者必須明確宣告
對建構系統而言，每個規則的依附元件都不相同。
如果未觀察到這項原則，會導致未定義的行為：建構作業可能會失敗 但更糟的是，建構作業可能會依賴之前的作業 指定要套用的依附元件Bazel 檢查是否缺少 依附元件和回報錯誤，但無法執行這項檢查 而且在所有情況下都會完成
您不一定要 (也不要) 嘗試列出所有間接匯入的、
即使在執行時由 A 需要也一樣。
在目標 X 建構期間，建構工具會檢查整個遞移性
關閉 X 的依附元件，確保這些目標的任何變更
並視情況重新建構中繼資訊。
依附元件的遞移性質會導致常見錯誤。有時候，
某個檔案中的程式碼可以使用「間接」依附元件提供的程式碼，
宣告的依附元件圖表中並未直接呈現邊緣，而非直接的邊緣間接
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. 新增未宣告的依附元件
當使用者在 a 中新增程式碼，而該物件會建立
直接使用 c 的「實際」依附元件，但忘記在建構檔案中宣告
a/BUILD。
a / a.in |
|
|---|---|
import b;
import c;
b.foo();
c.garply();
|
|
|
|
|
宣告的依附元件不再高估實際依附元件。
這比較合理，因為這兩個圖形的遞移性是平等的
但掩飾一個問題：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 中導入的 c 的 a 已在 BUILD 檔案中正確宣告。
依附元件類型
大多數的建構規則都有三個屬性，可用來指定不同種類的
一般依附元件：srcs、deps 和 data。說明如下：適用對象
如需詳細資訊，請參閱
所有規則通用的屬性：
許多規則也針對特定規則的類型有額外屬性
依附元件，例如 compiler 或 resources詳細說明請見
建構百科全書。
srcs 項依附元件
直接由輸出來源檔案的規則或規則使用的檔案。
deps 項依附元件
指向提供標頭檔案的個別編譯模組的規則。 符號、程式庫、資料等
data 項依附元件
建構目標可能需要一些資料檔案才能正確執行。這些資料檔案 ，因為它們不會影響目標的建構方式。舉例來說 單元測試可能會比較函式輸出內容與檔案內容。當您 建構單元測試不需要檔案，但執行時 需要用到 進行測試。同樣的原則也適用於執行期間啟動的工具。
建構系統會在獨立目錄中執行測試，其中僅列出下列檔案：
您可以改用 data。因此，如果二進位檔/程式庫/測試需要一些檔案才能執行
可在 data 中指定這些 API，或包含那些物件的建構規則。例如：
# 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 存取這些檔案。在測試中
您可以彙整測試來源的路徑來參照這些檔案
目錄和 Workspace 相關路徑
${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 做為資料依附元件。
| 製作檔案 | 瀏覽權限 |