「Depset」是一種特殊的資料結構,可跨目標的遞移依附元件有效率地收集資料。是管理規則的重要元素
解碼器的定義功能是其時間和空間的聯集作業。depset 建構函式接受元素清單 (「直接」) 和其他部分清單 (「遞移」),並傳回代表集合,其中包含所有直接元素及所有遞移集的聯集。概念上,建構函式會建立新的圖形節點,並以直接和遞移節點做為後續節點。依據這個圖表的周遊, Depsets 具有明確定義的排序語意。
範例使用範例包括:
儲存程式程式庫所有物件檔案的路徑,然後可透過供應器傳送至連接器動作。
如為已解譯的語言,請儲存執行檔中包含的遞移來源檔案。
說明與運算
概念上,Depset 是有向非循環圖 (DAG),看起來通常與目標圖表類似。這個函式是從從左到根依序建構。依附元件鏈中的每個目標都可以在先前的頂端新增自己的內容,而不必讀取或複製這些項目。
DAG 中的每個節點都包含直接元素清單和子節點清單。該部分的內容是遞移元素,例如所有節點的直接元素。您可以使用 depset 建構函式建立新的 depset:它接受直接元素清單和另一個子節點清單。
s = depset(["a", "b", "c"])
t = depset(["d", "e"], transitive = [s])
print(s) # depset(["a", "b", "c"])
print(t) # depset(["d", "e", "a", "b", "c"])
如要擷取解碼器的內容,請使用 to_list() 方法。此方法會傳回所有遞移元素的清單,但不會傳回重複項目。您無法直接檢查 DAG 的精確結構,但這個結構會影響元素傳回順序。
s = depset(["a", "b", "c"])
print("c" in s.to_list()) # True
print(s.to_list() == ["a", "b", "c"]) # True
如同字典中允許的鍵有所限制,資料組中允許的項目也會受到限制。值得一提的是,取消設定的內容可能無法變更。
依附元件使用參照等式:除法會等於本身,但不等於其他任何解碼器,即使兩者俱有相同的內容和內部結構也一樣。
s = depset(["a", "b", "c"])
t = s
print(s == t) # True
t = depset(["a", "b", "c"])
print(s == t) # False
d = {}
d[s] = None
d[t] = None
print(len(d)) # 2
如要根據內容比較除數,請將值轉換為經過排序的清單。
s = depset(["a", "b", "c"])
t = depset(["c", "b", "a"])
print(sorted(s.to_list()) == sorted(t.to_list())) # True
無法從資料集中移除元素。如有需要,您必須讀出依附元件的完整內容、篩選要移除的元素,然後重新建構新的設定。這種做法的效率不高
s = depset(["a", "b", "c"])
t = depset(["b", "c"])
# Compute set difference s - t. Precompute t.to_list() so it's not done
# in a loop, and convert it to a dictionary for fast membership tests.
t_items = {e: None for e in t.to_list()}
diff_items = [x for x in s.to_list() if x not in t_items]
# Convert back to depset if it's still going to be used for union operations.
s = depset(diff_items)
print(s) # depset(["a"])
訂購
to_list
作業會在 DAG 上執行週遊。週遊類型取決於建構解碼器時指定的順序。Bazel 支援多個訂單,因為有時候工具會重視輸入的順序。舉例來說,連結器動作可能需要確保 B
依附 A
,則 A.o
在連結器指令列的 B.o
之前。其他工具則可能有不同的規定。
支援三種週遊訂單:postorder
、preorder
和 topological
。前兩項工作與樹狀結構週遊完全相同,但會在 DAG 上運作並略過已經造訪的節點。第三種順序的運作方式是從根到離開,基本上與預購項目相同,唯一差別在於共用子項只有在所有父項之後才會顯示。預購和事後順序會以由左至右的周遊方式運作,但請注意,每個節點中的直接元素都沒有相對於子項的順序。以拓撲來說,沒有由左至右的保證,甚至如果 DAG 的不同節點中有重複元素,則甚至不會套用 all-parents-child-child 的保證。
# This demonstrates different traversal orders.
def create(order):
cd = depset(["c", "d"], order = order)
gh = depset(["g", "h"], order = order)
return depset(["a", "b", "e", "f"], transitive = [cd, gh], order = order)
print(create("postorder").to_list()) # ["c", "d", "g", "h", "a", "b", "e", "f"]
print(create("preorder").to_list()) # ["a", "b", "e", "f", "c", "d", "g", "h"]
# This demonstrates different orders on a diamond graph.
def create(order):
a = depset(["a"], order=order)
b = depset(["b"], transitive = [a], order = order)
c = depset(["c"], transitive = [a], order = order)
d = depset(["d"], transitive = [b, c], order = order)
return d
print(create("postorder").to_list()) # ["a", "b", "c", "d"]
print(create("preorder").to_list()) # ["d", "b", "a", "c"]
print(create("topological").to_list()) # ["d", "b", "c", "a"]
基於遍歷的實作方式,使用建構函式的 order
關鍵字引數建立解碼器時,必須指定順序。如果省略這個引數,Depset 具有特殊的 default
順序,在這種情況下,無法保證其任何元素的順序 (除非是確定性)。
完整範例
這個範例可在 https://github.com/bazelbuild/examples/tree/main/rules/depsets 取得。
假設在推理語言「食物」中,如要建構每個 foo_binary
,您必須瞭解其直接或間接依附的所有 *.foo
檔案。
# //depsets:BUILD
load(":foo.bzl", "foo_library", "foo_binary")
# Our hypothetical Foo compiler.
py_binary(
name = "foocc",
srcs = ["foocc.py"],
)
foo_library(
name = "a",
srcs = ["a.foo", "a_impl.foo"],
)
foo_library(
name = "b",
srcs = ["b.foo", "b_impl.foo"],
deps = [":a"],
)
foo_library(
name = "c",
srcs = ["c.foo", "c_impl.foo"],
deps = [":a"],
)
foo_binary(
name = "d",
srcs = ["d.foo"],
deps = [":b", ":c"],
)
# //depsets:foocc.py
# "Foo compiler" that just concatenates its inputs to form its output.
import sys
if __name__ == "__main__":
assert len(sys.argv) >= 1
output = open(sys.argv[1], "wt")
for path in sys.argv[2:]:
input = open(path, "rt")
output.write(input.read())
這裡,二進位 d
的遞移來源是 a
、b
、c
和 d
中 srcs
欄位中的 *.foo
檔案。為了讓 foo_binary
目標瞭解 d.foo
以外的任何檔案,foo_library
目標必須將其傳入供應器。每個程式庫都會從自身的依附元件接收供應器,新增各自的即時來源,並傳遞包含擴增內容的新供應器。foo_binary
規則也是如此,差別在於其會使用完整的來源清單建構動作的指令列,而不會傳回供應器。
以下提供 foo_library
和 foo_binary
規則的完整導入方式。
# //depsets/foo.bzl
# A provider with one field, transitive_sources.
FooFiles = provider(fields = ["transitive_sources"])
def get_transitive_srcs(srcs, deps):
"""Obtain the source files for a target and its transitive dependencies.
Args:
srcs: a list of source files
deps: a list of targets that are direct dependencies
Returns:
a collection of the transitive sources
"""
return depset(
srcs,
transitive = [dep[FooFiles].transitive_sources for dep in deps])
def _foo_library_impl(ctx):
trans_srcs = get_transitive_srcs(ctx.files.srcs, ctx.attr.deps)
return [FooFiles(transitive_sources=trans_srcs)]
foo_library = rule(
implementation = _foo_library_impl,
attrs = {
"srcs": attr.label_list(allow_files=True),
"deps": attr.label_list(),
},
)
def _foo_binary_impl(ctx):
foocc = ctx.executable._foocc
out = ctx.outputs.out
trans_srcs = get_transitive_srcs(ctx.files.srcs, ctx.attr.deps)
srcs_list = trans_srcs.to_list()
ctx.actions.run(executable = foocc,
arguments = [out.path] + [src.path for src in srcs_list],
inputs = srcs_list + [foocc],
outputs = [out])
foo_binary = rule(
implementation = _foo_binary_impl,
attrs = {
"srcs": attr.label_list(allow_files=True),
"deps": attr.label_list(),
"_foocc": attr.label(default=Label("//depsets:foocc"),
allow_files=True, executable=True, cfg="host")
},
outputs = {"out": "%{name}.out"},
)
如要進行測試,您可以將這些檔案複製到新的套件中,適當重新命名標籤、建立包含虛擬內容的 *.foo
檔案,以及建構 d
目標。
效能
如要瞭解使用依附元件的動機,請想想如果 get_transitive_srcs()
從清單中收集來源會有什麼影響。
def get_transitive_srcs(srcs, deps):
trans_srcs = []
for dep in deps:
trans_srcs += dep[FooFiles].transitive_sources
trans_srcs += srcs
return trans_srcs
這不會將重複的項目納入考量,因此 a
的來源檔案會在指令列中出現兩次,並在輸出檔案的內容中出現兩次。
替代方法是使用一般組合進行模擬,其中鍵是元素,且所有索引鍵皆對應至 True
。
def get_transitive_srcs(srcs, deps):
trans_srcs = {}
for dep in deps:
for file in dep[FooFiles].transitive_sources:
trans_srcs[file] = True
for file in srcs:
trans_srcs[file] = True
return trans_srcs
這樣做會移除重複項目,但會未指定指令列引數 (以及檔案內容) 的順序,但這樣仍是確定性。
此外,這兩種方法都比解碼式方法更嚴重。假設食物程式庫上存在長時間的依附元件鏈結。處理每項規則時,都必須將原本輸入的所有轉換來源複製到新資料結構。這表示分析個別程式庫或二進位目標所需的時間和空間成本,與鏈結中本身的高度成正比。如為長度 n 的鏈結,foolib_1 ← foolib_2 ← ... ← foolib_n,則有效費用為 O(n^2)。
一般來說,每當您透過遞移依附元件累積資訊時,就應使用 Depset。這有助於確保您的建構能擴充,同時目標圖更深入。
最後,請務必不要在規則實作中,無謂地擷取變數的內容。由於整體費用只有 O(n),因此在二元規則結尾呼叫 to_list()
並沒有問題。也就是許多非終端目標都嘗試呼叫 to_list()
來發生二次方行為。
如要進一步瞭解如何有效使用 depset,請參閱效能頁面。
API 參考資料
詳情請參閱這裡。