如果 A
在建構或執行期間需要 B
,目標 A
就會依附目標 B
。取決於關係
有向非循環圖
(DAG) 取代目標,也稱為依附元件圖表。
目標的「直接」依附元件是指可透過路徑連上的其他目標 依附元件圖表中。目標的遞移依附元件,是指透過圖表中任意長度的路徑,依附於目標的目標。
事實上,在建構作業的背景下,有兩個依附元件圖表,分別是實際依附元件的圖表,以及已宣告依附元件的圖表。在大多數情況下,這兩張圖表非常相似,因此不需要做出區分,但這點對於後續的討論相當實用。
實際和宣告的依附元件
如果必須含有 Y
,目標 X
就實際上取決於目標 Y
。
以便確保 X
能正確建構。已打造
均產生、處理、編譯、連結、封存、壓縮、執行,或是
任何在建構期間經常執行的作業。
如果 X
套件中存在從 X
到 Y
的依附元件邊緣,則目標 X
就會對目標 Y
有已宣告的依附元件。
如要正確建構,實際依附元件 A 的圖表必須是
宣告依附元件 D 的圖表。也就是說,在 A 中,每對直接連線的節點 x --> y
也必須在 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 中引入的 a
到 c
的實際依附元件已在 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
取得。在測試中,您可以彙整測試來源目錄的路徑和工作區相對於路徑 (例如 ${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
做為資料依附元件。
製作檔案 | 瀏覽權限 |