工作區、套件和目標

回報問題 查看來源 Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

Bazel 會從目錄樹 (稱為工作區) 中整理的原始碼建構軟體。工作區中的來源檔案會整理成巢狀套件階層,每個套件都是一個目錄,內含一組相關來源檔案和一個 BUILD 檔案。BUILD 檔案會指定可從來源建構的軟體輸出內容。

工作區

工作區是檔案系統上的目錄樹,內含要建構軟體的來源檔案。每個工作區都有名為 WORKSPACE 的文字檔案,這個檔案可能是空白,也可能包含建構輸出內容所需的外部依附元件參照。

含有名為 WORKSPACE 檔案的目錄會視為工作區的根目錄。因此,Bazel 會忽略工作區中以含有 WORKSPACE 檔案的子目錄為根目錄的任何目錄樹,因為這些目錄樹會形成另一個工作區。

Bazel 也支援 WORKSPACE.bazel 檔案,做為 WORKSPACE 檔案的別名。如果兩個檔案都存在,系統會使用 WORKSPACE.bazel

存放區

程式碼會整理在存放區中。包含 WORKSPACE 檔案的目錄是主要存放區的根目錄,也稱為 @。其他 (外部) 存放區是在 WORKSPACE 檔案中,使用工作區規則定義,或從 Bzlmod 系統中的模組和擴充功能產生。詳情請參閱外部依附元件總覽

Bazel 隨附的工作區規則,請參閱建構百科全書的「工作區規則」一節,以及內嵌 Starlark 存放區規則的說明文件。

由於外部存放區本身就是存放區,因此通常也包含 WORKSPACE 檔案。不過,Bazel 會忽略這些額外的 WORKSPACE 檔案。特別是,系統不會自動新增以遞移方式依附的存放區。

套件

存放區中程式碼的主要組織單位是「套件」。套件是一組相關檔案,以及如何使用這些檔案產生輸出構件的規格。

套件定義為包含名為 BUILD (或 BUILD.bazel) 檔案的目錄。套件包含目錄中的所有檔案,以及其下方的所有子目錄,但本身包含 BUILD 檔案的子目錄除外。根據這項定義,任何檔案或目錄都不得屬於兩個不同的套件。

舉例來說,在下列目錄樹中,有兩個套件:my/app 和子套件 my/app/tests。請注意,my/app/data 不是套件,而是屬於套件 my/app 的目錄。

src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc

目標

套件是目標的容器,定義於套件的 BUILD 檔案中。大多數目標都是兩種主要類型之一:檔案規則

檔案可再細分為兩類。來源檔案通常是由人員編寫,並簽入存放區。產生的檔案 (有時稱為衍生檔案或輸出檔案) 不會簽入,而是從來源檔案產生。

第二種目標是使用「規則」宣告。每個規則例項都會指定一組輸入和一組輸出檔案之間的關係。規則的輸入內容可以是來源檔案,也可以是其他規則的輸出內容。

在大多數情況下,規則的輸入內容是來源檔案或產生檔案並不重要,重要的是檔案內容。因此,您可以輕鬆地以規則產生的檔案取代複雜的來源檔案,例如手動維護高度結構化檔案的負擔過於繁重時,有人編寫程式來衍生檔案。該檔案的使用者不需要進行任何變更。反之,如果來源檔案只有本機變更,則可輕易取代產生的檔案。

規則的輸入內容也可能包含其他規則。這類關係的確切意義通常相當複雜,且取決於語言或規則,但直覺上很簡單:C++ 程式庫規則 A 可能有另一個 C++ 程式庫規則 B 做為輸入內容。這項依附元件的效果是,編譯期間 A 可以使用 B 的標頭檔,連結期間 A 可以使用 B 的符號,執行期間 A 可以使用 B 的執行階段資料。

所有規則的不變項都是規則產生的檔案一律屬於與規則本身相同的套件;無法將檔案產生至其他套件。不過,規則的輸入內容來自另一個套件的情況並不少見。

套件群組是一組套件,目的是限制特定規則的可存取性。套件群組是由 package_group 函式定義。這類群組有三項屬性:所含套件的清單、名稱,以及所含的其他套件群組。只能從規則的 visibility 屬性或 package 函式的 default_visibility 屬性參照這些檔案,檔案不會產生或耗用。詳情請參閱 package_group 說明文件。

標籤