本頁面由 Cloud Translation API 翻譯而成。

使用 Bazel 建構程式

本頁面說明如何使用 Bazel、建構指令語法和目標模式語法建構程式。

快速入門導覽課程

如要執行 Bazel，請前往基本 workspace 目錄或其任何子目錄，然後輸入 bazel。如果您需要建立新的工作區，請參閱 build。

bazel help
                             [Bazel release bazel version]
Usage: bazel command options ...

可使用的指令

analyze-profile：分析建構設定檔資料。
aquery：在「後分析」動作圖表上執行查詢。
build：建構指定的目標。
canonicalize-flags：對 Bazel 標記進行標準化。
clean：移除輸出檔案，並視需要停止伺服器。
cquery：執行後分析依附元件圖表查詢。
dump：傾印 Bazel 伺服器程序的內部狀態。
help：顯示指令或索引的說明。
info：顯示 bazel 伺服器的執行階段資訊。
fetch：擷取目標的所有外部依附元件。
mobile-install：在行動裝置上安裝應用程式。
query：執行依附關係圖查詢。
run：執行指定的目標。
shutdown：停止 Bazel 伺服器。
test：建構並執行指定的測試目標。
version：列印 Bazel 的版本資訊。

取得協助

bazel help command：顯示 command 的說明和選項。
bazel helpstartup_options：JVM 託管 Bazel 的選項。
bazel helptarget-syntax：說明指定目標的語法。
bazel help info-keys：顯示資訊指令使用的索引鍵清單。

bazel 工具會執行許多函式，稱為指令。最常用的是 bazel build 和 bazel test。您可以使用 bazel help 瀏覽線上說明訊息。

建立目標

您需要先具備工作區，才能開始建構。工作區是一種目錄樹狀結構，其中包含建構應用程式所需的所有來源檔案。Bazel 可讓您從完全唯讀的磁碟區執行建構作業，

如要使用 Bazel 建構程式，請輸入 bazel build，並在後方加上您要建構的目標。

bazel build //foo

發出指令建構 //foo 後，您會看到類似以下的輸出內容：

INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 9.905s, Critical Path: 3.25s
INFO: Build completed successfully, 6 total actions

首先，Bazel 會「載入」目標依附元件圖表中的所有套件。這包括宣告的依附元件、直接列在目標的 BUILD 檔案中的檔案，以及遞移依附元件 (也就是目標依附元件的 BUILD 檔案中列出的檔案)。找出所有依附元件後，Bazel 會「分析」檢查內容是否正確，並建立「建構動作」。最後，Bazel 會「執行」建構作業的編譯器和其他工具。

在建構執行階段，Bazel 會顯示進度訊息。進度訊息會包含開始時目前的建構步驟 (例如編譯器或連結器)，以及建構動作總數中完成的次數。當 Bazel 發現整個動作圖時，動作總數通常會增加，但數量會在幾秒內穩定下來。

建構作業結束時，Bazel 會顯示要求的目標、是否成功建構目標以及輸出檔案所在的位置。執行建構作業的指令碼可以穩定剖析這項輸出內容；詳情請參閱 --show_result。

如果您再次輸入相同的指令，建構作業的執行速度會更快。

bazel build //foo
INFO: Analyzed target //foo:foo (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 0.144s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action

此為null build。由於沒有變更，因此沒有可以重新載入的套件，也沒有可執行的建構步驟。如果「foo」或其依附元件有所變更，Bazel 會重新執行部分建構動作，或完成漸進式建構。

建立多個目標

Bazel 允許透過多種方式指定要建構的目標。這些模式統稱為「目標模式」。這個語法會用於 build、test 或 query 等指令。

標籤是用來指定個別目標，例如在 BUILD 檔案中宣告依附元件時，Bazel 的目標模式會指定多個目標。目標模式是使用萬用字元，針對目標「集」的標籤語法進行一般化。在最簡單的情況下，任何有效的標籤也是有效的目標模式，用於識別一組僅一個目標。

所有以 // 開頭的目標模式都會根據目前的工作區解析。

`//foo/bar:wiz`	只有單一目標 `//foo/bar:wiz`。
`//foo/bar`	等同於 `//foo/bar:bar`。
`//foo/bar:all`	套件 `foo/bar` 中的所有規則目標。
`//foo/...`	`foo` 目錄下所有套件中的所有規則目標。
`//foo/...:all`	`foo` 目錄下所有套件中的所有規則目標。
`//foo/...:*`	`foo` 目錄下所有套件中的所有目標 (規則和檔案)。
`//foo/...:all-targets`	`foo` 目錄下所有套件中的所有目標 (規則和檔案)。
`//...`	工作區套件中的所有目標。這不包括外部存放區的目標。
`//:all`	頂層套件中的所有目標 (如果工作區根目錄有「BUILD」檔案)。

開頭不是 // 的目標模式會根據目前的工作目錄進行解析。這些範例假設是 foo 的工作目錄：

`:foo`	等同於 `//foo:foo`。
`bar:wiz`	等同於 `//foo/bar:wiz`。
`bar/wiz`	等同於：如果 `foo/bar/wiz` 是套件，則為 `//foo/bar/wiz:wiz` 如果 `foo/bar` 是套件，則為 `//foo/bar:wiz` 其他情況則為 `//foo:bar/wiz`
`bar:all`	等同於 `//foo/bar:all`。
`:all`	等同於 `//foo:all`。
`...:all`	等同於 `//foo/...:all`。
`...`	等同於 `//foo/...:all`。
`bar/...:all`	等同於 `//foo/bar/...:all`。

根據預設，遞迴目標模式會遵循目錄符號連結，但指向輸出基礎下方的目錄符號連結則除外，例如在工作區根目錄中建立的便利符號連結。

此外，Bazel 在評估任何包含類似以下檔案的目錄時，不會追蹤符號連結：DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN

foo/... 是「套件」上的萬用字元，表示所有套件會以遞迴方式位於 foo 目錄下 (針對套件路徑的所有根層級)。:all 是比「目標」的萬用字元，符合套件中的所有規則。這兩個項目可能會合併 (例如 foo/...:all)，當同時使用這兩種萬用字元時，它可能會縮寫為 foo/...。

此外，:* (或 :all-targets) 是符合相符套件中「每個目標」的萬用字元，包括通常並非由任何規則建構的檔案，例如與 java_binary 規則相關聯的 _deploy.jar 檔案。

這表示 :* 表示 :all 的「超集」；雖然這個語法可能會讓您混淆，但允許一般建構使用熟悉的 :all 萬用字元進行一般建構，也就是不需要建構 _deploy.jar 等目標。

此外，Bazel 允許使用斜線，不使用標籤語法所需的冒號；這通常適合使用 Bash 檔案名稱擴充。例如，foo/bar/wiz 相當於 //foo/bar:wiz (如果有套件 foo/bar) 或 //foo:bar/wiz (如果有套件 foo)。

許多 Bazel 指令接受目標模式清單做為引數，這些模式都會遵循前置字串否定運算子 -。這可用於從上述引數指定的集合中，減去一組目標。請注意，這代表順序很重要。舉例來說，

bazel build foo/... bar/...

也就是「建立 foo 底下的所有目標，並且」建立 bar 底下的所有目標，而

bazel build -- foo/... -foo/bar/...

是指「建立 foo 下的所有目標，但除外foo/bar」(這是必要的 -- 引數，以免後續引數以 - 為額外選項)。

值得注意的是，以這種方式減去目標無法保證不會建構，因為這些目標可能是未減少的目標依附元件。舉例來說，如果有某個目標 //foo:all-apis 還有其他依附於 //foo/bar:api 的目標 //foo:all-apis，那麼後者會建構為前者的一部分。

使用 bazel build 和 bazel test 等指令指定時，萬用字元目標模式 (...、:*、:all 等) 不會納入萬用字元目標模式 (...、:*、:all 等)。如要 Bazel 建構/測試這類目標，請在指令列中指定這類測試目標。tags = ["manual"]相反地，bazel query 不會自動執行這類篩選 (否則會失去 bazel query 的用途)。

擷取外部依附元件

根據預設，Bazel 會在建構期間下載外部依附元件，並為其建立符號連結。但這並不理想，因為您想知道何時新增的是新的外部依附元件，或是想「預先擷取」依附元件 (例如在即將離線的航班前)。如要避免在建構期間新增依附元件，您可以指定 --fetch=false 標記。請注意，這個標記僅適用於未指向本機檔案系統中目錄的存放區規則。例如，local_repository、new_local_repository、Android SDK 和 NDK 存放區規則的變更一律會生效，無論 --fetch 值為何。

如果您在建構期間不允許擷取，且 Bazel 發現新的外部依附元件，建構作業就會失敗。

您可以執行 bazel fetch，手動擷取依附元件。如果您在建構期間不允許進行擷取，則必須執行 bazel fetch：

首次建構之前。
新增外部依附元件之後。

執行後，在 WORKSPACE 檔案變更之前，您不應再次執行該檔案。

fetch 會使用目標清單來擷取依附元件。例如，這樣做會擷取建構 //foo:bar 和 //bar:baz 所需的依附元件：

bazel fetch //foo:bar //bar:baz

如要擷取工作區的所有外部依附元件，請執行下列指令：

bazel fetch //...

如果您將使用的所有工具 (從程式庫 jar 到 JDK 本身) 在工作區根目錄下，就無須執行 bazel 擷取作業。不過，如果您使用工作區目錄以外的任何內容，Bazel 會在執行 bazel build 之前自動執行 bazel fetch。

存放區快取

即使不同工作區需要相同的檔案，或是外部存放區的定義有所變更，但需要下載同一個檔案，Bazel 仍會多次嘗試擷取同一個檔案。為此，bazel 會快取所有從存放區快取下載的檔案，這些檔案預設位於 ~/.cache/bazel/_bazel_$USER/cache/repos/v1/。--repository_cache 選項即可變更位置。這個快取由所有工作區與已安裝的 bazel 版本共用。如果 Bazel 確定擁有正確檔案的複本 (也就是下載要求擁有指定檔案的 SHA256 總和)，且含有該雜湊的檔案位於快取中，就會從快取中擷取項目。因此，從安全性的角度來看，指定每個外部檔案的雜湊不只是一個好主意，還能避免不必要的下載作業。

每次快取命中時，快取中檔案的修改時間也會隨之更新。如此一來，系統就能輕易判斷快取目錄中檔案的上次使用時間，例如手動清除快取。系統絕不會自動清理快取資料，因為其中可能包含已無法使用上游的檔案副本。

發布檔案目錄

發布目錄是另一種 Bazel 機制，可避免不必要的下載作業。Bazel 會在存放區快取之前搜尋發行版目錄。主要差異在於發行目錄需要手動準備。

您可以使用 --distdir=/path/to-directory 選項，指定其他唯讀目錄來尋找檔案，而不必擷取檔案。如果檔案名稱等於網址的基礎名稱，且檔案的雜湊值與下載要求中指定的檔案相同，系統會從這類目錄中擷取檔案。只有在 WORKSPACE 宣告中指定檔案雜湊時，才能使用這種做法。

雖然檔案名稱條件與正確性並不需要，但將候選檔案的數量減少為每個指定目錄一個。如此一來，即使這類目錄中的檔案數量變多，指定發行檔案目錄仍是有效率的。

在氣隙環境中執行 Bazel

為了確保 Bazel 的二進位檔大小較小，系統會在首次執行時，透過網路擷取 Bazel 的隱含依附元件。這些隱含依附元件包含的工具鍊和規則，可能不一定適用於所有使用者。舉例來說，系統只會在建構 Android 專案時取消組合及擷取 Android 工具。

但是，即使您已供應商所有 WORKSPACE 依附元件，在氣隙環境中執行 Bazel 時，這些隱含依附元件還是可能會發生問題。如要解決這個問題，您可以在具備網路存取權的機器上準備包含這些依附元件的發布目錄，然後透過離線方法將這些依附元件轉移至 Airgapped 環境。

如要準備分佈目錄，請使用 --distdir 標記。每個新的 Bazel 二進位檔版本都必須執行此操作，因為每個版本的隱含依附元件可能都不同。

如要在 Airgapped 環境之外建構這些依附元件，請先檢查適當版本的 Bazel 來源樹狀結構：

git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"
cd "$BAZEL_DIR"
git checkout "$BAZEL_VERSION"

然後，建構該 Bazel 版本內含隱含執行階段依附元件的 tarball：

bazel build @additional_distfiles//:archives.tar

將這個 tarball 匯出到可以複製到 Airgapped 環境的目錄。請留意 --strip-components 旗標，因為 --distdir 可以使用目錄巢狀層級完成最終設定：

tar xvf bazel-bin/external/additional_distfiles/archives.tar \
  -C "$NEW_DIRECTORY" --strip-components=3

最後，在 Airgapped 環境中使用 Bazel 時，請傳送指向該目錄的 --distdir 標記。為了方便起見，您可以將其新增為 .bazelrc 項目：

build --distdir=path/to/directory

建構設定和跨程式碼編譯

所有指定特定建構行為和結果的輸入項目都可以拆分成兩個不同的類別。第一種是儲存在專案 BUILD 檔案中的內建資訊：建構規則、屬性的值，以及該規則的完整遞移依附元件集。第二種是使用者或建構工具提供的外部或環境資料：選擇目標架構、編譯和連結選項，以及其他工具鍊設定選項。我們將完整的環境資料稱為「設定」。

在任何建構作業中，可能都有多項設定。假設您採用跨編譯技術，針對 64 位元架構建構 //foo:bin 執行檔，但工作站為 32 位元機器。很明顯，建構作業必須透過能夠建立 64 位元執行檔的工具鍊建構 //foo:bin，但建構系統也必須在建構期間建構使用的各種工具 (例如以來源建構的工具，隨後在建構過程中使用的工具 (例如 Genrule) 都必須在工作站上執行。因此，我們可以識別兩種設定：用於建構在建構期間執行的工具「主機設定」，以及「目標設定」(或「要求設定」，但我們會更常說「目標設定」，不過該字詞已具有許多含義，但這個字詞會用於建構您最終要求的二進位檔)。

通常，要求的建構目標 (//foo:bin) 和一或多項主機工具都是必要的程式庫，例如一些基本程式庫。這類程式庫必須建立兩次，一次用於主機設定，一次則用於目標設定。Bazel 會確保兩個變數建構完成，並將衍生檔案分開以免造成乾擾；由於這類目標彼此獨立，通常可以並行建構這類目標。如果您看到進度訊息，說明指定目標正在建構兩次，這很有可能是上述情況。

Bazel 會根據 --distinct_host_configuration 選項，使用兩種方式選取主機設定。這個布林值選項有些微不足，設定可能會提高 (或降低) 建構速度。

`--distinct_host_configuration=false`

如果這個選項為 false，主機和要求設定會相同：建構期間需要的所有工具都會採用與目標程式相同的建構方式。這項設定表示在單一建構作業中不必建構兩次程式庫。

但是，這代表對要求設定的任何變更也會影響您的主機設定，導致需要重建所有工具，且會重新建構任何依賴工具輸出內容的項目。因此，例如，僅在建構之間變更連結器選項可能會導致系統重新連結所有工具，接著使用這些工具進行重新執行的所有動作，進而產生非常大的重新建構。

`--distinct_host_configuration=true` (預設)

如果此選項為 true，則會使用完全不同的主機設定，而不是針對主機和要求使用相同的設定。主機設定衍生自目標設定，如下所示：

除非已指定 --host_crosstool_top，否則使用與要求設定中指定的相同的 Crosstool (--crosstool_top) 版本。
針對 --cpu 使用 --host_cpu 的值 (預設值：k8)。
使用與要求設定中指定的相同值：--compiler 和 --use_ijars。如果使用 --host_crosstool_top，則會使用 --host_cpu 的值，在 Crosstool 中查詢主機設定的 default_toolchain (忽略 --compiler)。
針對「--javabase」使用「--host_javabase」的值
針對「--java_toolchain」使用「--host_java_toolchain」的值
使用針對 C++ 程式碼 (-c opt) 的最佳化版本。
不產生偵錯資訊 (--copt=-g0)。
從執行檔和共用程式庫中移除偵錯資訊 (--strip=always)。
將所有衍生檔案放在特殊位置，而不是任何可能的要求設定使用的位置。
利用建構資料限制二進位檔的戳記 (請參閱 --embed_* 選項)。
所有其他值都保留預設值。

建議從要求設定中選取不同的主機設定可能的原因有很多。有些題目太誇張了，所以在這裡一一介紹，但其中兩個是值得特別注意的。

首先，透過使用經過簡化的最佳化二進位檔，您就能減少連結和執行工具的時間、工具佔用的磁碟空間，以及分散式建構中的網路 I/O 時間。

其次，將所有建構作業中的主機和要求設定分離，可避免因要求設定有些微變更而產生高成本的重新建構作業，例如變更連結器選項的行為，如前文所述。

但在某些版本上，這個選項可能比較複雜。尤其是在不常有設定變更的情況下 (尤其是某些 Java 版本) 的建構作業，以及必須在主機和目標設定下建構程式碼量相當大的建構作業，可能沒有幫助。

修正漸進式重建錯誤

Bazel 專案的其中一個主要目標是確保正確的漸進式重新建構。在實作漸進式建構作業時，先前的建構工具 (尤其是以 Make 為基礎的工具) 會在實作過程中做出幾項不公平的假設。

首先，檔案的時間戳記會隨時間增加。雖然這是一般情況，但很容易做出這項假設；如果與檔案較早的修訂版本同步，會導致檔案的修改時間縮短；「Make 型系統」不會重新建構。

更廣泛來說，雖然 Make 可以偵測檔案變更，但不會偵測指令變更。如果您在特定建構步驟中修改傳遞至編譯器的選項，Make 不會重新執行編譯器，因此您必須使用 make clean 手動捨棄先前建構的無效輸出內容。

此外，當子程序開始寫入其輸出檔案後，對於其中一個子程序的終止失敗情形，Make 會堅持不穩。雖然現在 Make 的執行失敗，但後續叫用 Make 時，系統會假設截斷輸出檔案是有效 (因為比輸入內容更新得新)，因此不會重新建構。同樣地，如果 Make 程序終止，也可能會發生類似情況。

Bazel 能避免這些假設和其他假設。Bazel 會維護先前完成所有工作的資料庫，且只有在發現建構步驟的輸入檔案 (及其時間戳記) 符合該建構步驟時，才會省略建構步驟；而該建構步驟的編譯指令必須與資料庫中的一個檔案完全相符，且資料庫項目的輸出檔案集 (及其時間戳記) 與磁碟中檔案時間戳記完全相符。任何對輸入檔案或輸出檔案進行的任何變更，或對指令本身進行的任何變更，都會使重新執行建構步驟。

正確漸進式建構對使用者的好處是：比較不容易造成混淆。(此外，無論是有必要或先佔情況，使用 make clean 導致的重新建構時間也縮短了)。

建構一致性及漸進式建構

正式上，我們會在所有預期輸出檔案存在時，將版本的狀態定義為「一致性」，且其內容皆正確無誤，如建立這些檔案所需要的步驟或規則所指定。當您編輯來源檔案時，系統會認為建構狀態不一致，並保持一致，直到您下次執行建構工具以順利完成為止。我們會將這種情況描述為不穩定不一致的情況，因為這只是暫時性的，而且透過執行建構工具可以還原一致性。

還有另一種常見的不一致情形：「穩定不一致」。如果建構作業達到穩定的狀態，那麼在成功多次成功叫用建構工具的情況下也無法還原一致性：建構作業發生「停滯」，輸出仍不正確。至於穩定的狀態，是使用者採用 Make (及其他建構工具) 類型 make clean 的主要原因。發現建構工具以這種方式失敗 (然後從這項工具復原) 可能會耗費大量時間與困擾。

在概念上，如要達成一致的建構作業，最簡單的方法就是捨棄先前的所有建構作業輸出內容，然後重新開始建構，也就是讓每個建構作業都有簡潔的建構作業。這種做法顯然太耗時 (除了發布工程師以外)，也很有用，因此建構工具必須能在不影響一致性的情況下執行漸進式建構作業。

修正漸進式依附元件分析並不容易，如上所述，許多其他建構工具都無法避免在漸進式建構作業期間產生穩定的狀態不一致。相較之下，Bazel 提供以下保證：在成功叫用建構工具後未進行任何編輯，建構作業將維持一致的狀態。(如果您在建構期間編輯來源檔案，Bazel 無法保證目前建構結果的一致性。但這可以保證「下一個」建構的結果會還原一致性。)

與所有保證一樣，有一些注意事項：在某些情況下，某些已知方法會讓 Bazel 發生狀態不一致的狀態。我們不保證會調查因故意在漸進式依附元件分析中找出錯誤而導致的問題，但我們會調查並盡力修正因正常或「合理」使用建構工具而產生的所有穩定不一致狀態。

如果您透過 Bazel 偵測到穩定不一致的狀態，請回報錯誤。

採用沙箱機制的執行作業

Bazel 會使用沙箱，確保動作能經過嚴謹且正確執行。Bazel 會在沙箱中執行 spawns (大致說法：動作)，僅包含工具執行工作所需的最少檔案組合。目前沙箱功能適用於已啟用 CONFIG_USER_NS 選項的 Linux 3.12 以上版本，以及 macOS 10.11 以上版本。

如果您的系統不支援沙箱功能，Bazel 將會輸出警告，提醒您建構作業無法保證其語意，且可能以不明方式影響主機系統。如要停用此警告，您可以將 --ignore_unsupported_sandboxing 標記傳送至 Bazel。

在 Google Kubernetes Engine 叢集節點或 Debian 等某些平台上，基於安全性考量，使用者命名空間預設為停用。您可以透過查看 /proc/sys/kernel/unprivileged_userns_clone 檔案進行檢查：如果檔案存在且包含 0，您就能使用 sudo sysctl kernel.unprivileged_userns_clone=1 啟用使用者命名空間。

在某些情況下，Bazel 沙箱會因系統設定而無法執行規則。問題通常為失敗，會輸出類似 namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory 的訊息。在這種情況下，請嘗試使用 --strategy=Genrule=standalone 和 --spawn_strategy=standalone 停用其他 Genrules 的沙箱。此外，請在我們的 Issue Tracker 中回報錯誤，並提及您使用的 Linux 發行版，以便我們調查並在後續版本中提供修正。

建構階段

在 Bazel 中，建構作業會在三個不同的階段進行；使用者瞭解兩者之間的差異，有助於深入瞭解控制建構作業的選項 (詳情請見下文)。

正在載入階段

首先是「載入」，其中初始目標的所有必要 BUILD 檔案及其依附元件的遞移性都會被載入、剖析、評估和快取。

對於啟動 Bazel 伺服器後的第一個建構作業，載入階段通常需要幾秒鐘的時間，才能從檔案系統載入許多 BUILD 檔案。在後續的建構作業中，特別是在沒有 BUILD 檔案變更的情況下，載入速度就會非常快。

這個階段回報的錯誤包括：找不到套件、找不到目標、BUILD 檔案中的語詞和文法錯誤，以及評估錯誤。

分析階段

第二階段「分析」包含每個建構規則的語意分析和驗證、建構依附元件圖表的結構，以及決定建構各步驟中要執行的確切工作。

如同載入，分析也需要幾秒鐘的時間才能完整計算。然而，Bazel 會將依附元件圖表從一個建構快取至下一個版本，而且只會重新分析其所需內容，這樣即使在先前建構後未變更套件，漸進式建構作業也能讓漸進式建構作業的執行速度非常快。

此階段回報的錯誤包括：不當的依附元件、對規則的輸入內容無效，以及與規則相關的所有錯誤訊息。

由於 Bazel 會在這個階段避免不必要的檔案 I/O，因此只會讀取 BUILD 檔案，藉此判斷要完成的工作，因此載入和分析階段的速度很快。這是在設計上，讓 Bazel 成為分析工具的良好基礎，例如於載入階段上方實作的 Bazel 的 query 指令。

執行階段

版本的第三個階段是「執行」。這個階段可確保建構中每個步驟的輸出內容與輸入內容一致，並視需要重新執行編譯/連結等工具。這個步驟是建構花費大部分時間的地方，大小從幾秒鐘到多小時不等，適用於大型建構作業。在此階段回報的錯誤包括：缺少來源檔案、某些建構動作執行的工具錯誤，或工具未能產生預期輸出組合。