前幾節介紹了套件、目標和標籤，以及 抽象化的建構作業依附元件圖本節說明具體語法 用於定義套件
根據定義，每個套件都包含 BUILD 檔案
計畫。系統會使用命令式語言評估 BUILD 個檔案
Starlark。
這些陳述式會解讀為陳述式的連續清單。
順序通常很重要：您必須先定義變數，然後
不過，大多數 BUILD 檔案僅包含
建構規則，而這些陳述式的相對順序不具實質意義；所有
也就是開發人員自行宣告的「哪些」規則和值。
時間套件評估完成。
執行建構規則函式 (例如 cc_library) 時，系統會建立
您之後可以使用標籤來參照這個目標。
在簡單的 BUILD 檔案中，您可以自由重新排序規則宣告，不需要
改變行為
為了鼓勵明確區分程式碼與資料，BUILD 檔案不得
包含函式定義、for 陳述式或 if 陳述式 (但列出
一般形式和 if 運算式則不在此限)。函式可在
.bzl 檔案。此外，*args 和 **kwargs 引數不是
允許在 BUILD 檔案中；而是明確列出所有引數
至關重要的一點是，Starlark 中的程式無法任意執行 I/O。這個不變化
讓 BUILD 檔案 (僅依賴已知的
是確保版本可重現的關鍵要素。
詳情請參閱「Hermeticity」一文。
BUILD 檔案只能使用 ASCII 字元編寫，不過
技術上來說，系統會使用 Latin-1 字元集解讀這種字元。
由於 BUILD 檔案必須在
其實程式碼發生變更時，這類容器通常由多人
。BUILD 個檔案作者應自由加註，記錄這個角色
以及每個建構目標的狀態 (是否供公開使用)，以及
或是記錄套件本身的角色
正在載入擴充功能
Bazel 擴充功能是結尾為 .bzl 的檔案。使用 load 陳述式匯入
從擴充功能擷取的符號
load("//foo/bar:file.bzl", "some_library")
這個程式碼會載入 foo/bar/file.bzl 檔案並加上 some_library 符號
對環境的影響這可用來載入新規則、函式或常數
(例如字串或清單)。如要匯入多個符號，您可以使用
呼叫 load 的其他引數。引數必須是字串常值
(無變數) 和 load 陳述式必須顯示在頂層，不能
函式主體中
load 的第一個引數是標籤，用來識別
.bzl 檔案。如果是相對標籤，則會與
包含目前 bzl 檔案的套件 (而非目錄)。中的相對標籤：
load 陳述式應使用開頭的 :。
load 也支援別名，因此您可以為
匯入的符號。
load("//foo/bar:file.bzl", library_alias = "some_library")
您可以在一個 load 陳述式中定義多個別名。另外，
引數清單可同時包含別名和一般符號名稱。下列
此範例一律合法 (請注意使用引號的時機)。
load(":my_rules.bzl", "some_rule", nice_alias = "some_other_rule")
在 .bzl 檔案中，系統不會匯出開頭為 _ 的符號，因此無法匯出
從其他檔案載入。
您可以使用載入瀏覽權限來限制
載入 .bzl 檔案的使用者
建構規則的類型
大多數建構規則都位於系列中，並按分組依據
語言。例如 cc_binary、cc_library
和 cc_test 是 C++ 二進位檔的建構規則
程式庫和測試。其他語言相同
使用不同的前置字元，例如 java_* 的命名配置
Java。其中一些函式記錄在
建構百科全書
所有人都能建立新規則
*_binary規則會以指定語言建構可執行程式。執行 執行檔時，該執行檔位於建構工具的二進位檔中 輸出樹狀圖。 因此//my:program會顯示在 (例如)$(BINDIR)/my/program處。在某些語言中，這類規則也會建立一個 runfiles 目錄。 其中包含
data中提及的所有檔案 屬性或其轉換規則中的任何規則 依附元件關閉；這組檔案 方便您部署至實際工作環境*_test規則是*_binary規則的特殊化，用於自動化作業 進行測試。測試是成功傳回零的程式。和二進位檔一樣，測試也有執行檔案樹狀結構 裡面只有測試能夠合法開啟的檔案 執行程式碼舉例來說，
cc_test(name='x', data=['//foo:bar'])程式可能會在執行期間開啟及讀取$TEST_SRCDIR/workspace/foo/bar。 (每種程式設計語言都有自己的公用程式函式， 存取$TEST_SRCDIR的值，但它們全都 相當於直接使用環境變數)。 如未能觀察規則，測試就會失敗 它是在遠端測試主機上執行*_library規則會在指定的 程式設計語言程式庫可能會依附其他程式庫 和二進位檔和測試可能會依附於程式庫 獨立編譯行為
| 標籤 | 依附元件 |