RFC-0153：Fuchsia 自訂 Ninja

RFC-0153：適用於 Fuchsia 的 Ninja 自訂功能
狀態	已接受
領域	建構
說明	提案：使用自訂版本的 Ninja 建構工具，協助 Fuchsia 加快建構速度、改善狀態回報功能和可用性。
問題	91545 年
毛皮變化	635356 個
作者	digit@google.com shayba@google.com tmandry@google.com
審查人員	shayba@google.com maruel@google.com abarth@google.com fangism@google.com jayzhuang@google.com rudymathu@google.com
提交日期 (年-月-日)	2022-01-22
審查日期 (年-月-日)	2022-03-17

摘要

此 RFC 建議使用開放原始碼的臨時自訂版本 Ninja 工具， 整合多個現有的第三方修補程式，大幅改進 其效能和可用性，以及上游維護人員 無法接受「無法接受」的警告，詳情請參閱 動機」部分。

具體來說，這麼做可讓您：

• 最佳化排程，明顯縮短建構總時間 計算 Ninja 採用的演算法。

• 改善狀態報告與記錄功能，並解決 觸發條件。

• 改善 Ninja 的回應速度和一般效能 改變其行為例如加速特定 Ninja 執行 22x 作業

• 因此，大幅加快團隊與產品之間的整合速度 建構系統與 IDE，如 Visual Studio Code 和 Vim 短時間內重新產生 IDE 繫結 提供絕佳的互動式程式碼編輯體驗

如要自訂，則只需在 https://fuchsia.googlesource.com/third_party/ninja，將受到管理 採用法規分支策略，密切追蹤 並透過一系列小型修補程式 排在最近的上游記錄頂端

這個實驗性分支的功能將於 2022 年第 3 季修訂。 有些計畫可協助上游維護人員接受感興趣的提取要求 但這些因素取決於許多超出此 RFC 範圍的外部因素 一般情況下，自訂分支版本不會再 。

提振精神

Ninja 建構工具則是 Google 的 Evan Martin 開發工具 為 Chrome 工作時進行實驗 1. 實驗成功後，我們決定成為 並提供開放原始碼的 Chrome 官方版本。它很快就拿起 其中有一些廣泛的建構設定工具或系統 ，包括今天：

• GN 建構工具，現已由 Chrome、Fchsia 和 Pigweed 專案採用。
• Android 專案使用的 Blueprint 和 Kati 工具。
• CMake 建構產生器，支援 Ninja 做為後端。
• 許多 Linux 開放原始碼專案使用的 Meson 建構系統。
• LLVM，開發人員可使用 CMake 或 GN 進行建構， 包含參與 LLVM 的 Fuchsia 團隊成員。

目前全球有數千位開發人員都在使用 Ninja， 並在 GitHub 上維持為開放原始碼專案。Ninja 會確保專案和實驗對象 小巧、簡單、可靠，而且極為方便攜帶。

基於多種原因，上游 Ninja 專案的進度會維持不變 並產生大量有趣的提取要求 可能需要好幾個月的時間，但審查過程可能長達好幾個月。目前的維護人員 私下聯繫，並且知道， 是因為缺乏時間正確檢查及測試重大變更 這也是迴歸測試套件狀態的結果 不過目前非常基本，在許多情況下都需要手動測試提取要求。 在這段測試中，客戶願意提供幫助，是我們的優先要務 加強了 Ninja 的維護能力，並加快 Ninja 的維護速度 與發展。舉例來說，他不必從程式碼集 從 C++03 到 C++11 的 C++03 都可以 且適用於較舊的發行版本 (即 Centos 7、Debian 8、Ubuntu 18.04 和 OSX 10.12) 使用其預設工具鍊，由適當的連續強制執行 進行整合。

可惜的是，問題太多，像您提到的那樣 要解決所有難題，必須投入大量心力 目前我們無法實現 Fuchsia 建構團隊的成就。

此 RFC 提供了一項技術主張，以暫時解決上述問題 則沒有限制 致力解決與上游共同合作的情況 維護人員這些頭銜可能來自 Fuchsia 專案或聯合組織 與 Ninja 對 Ninja 合作 未來的發展及改進但這類工作的資金不在於涵蓋範圍內 的例子。

與此同時，Ninja 的自訂分支機構 最具影響力的提取要求，這對 Fuchsia 開發人員最大的好處。 為確保此分支版本盡可能靠近上游， 強制執行分支策略： 可以看出 Fuchsia 分支一律以一系列小塊布的方式表示 的近期版本

請注意，這種情況與 自訂 Android Ninja 分支，不再採用上游 而且還缺少 Fuchsia 所需的功能 建構應用程式

以下是推動這個 RFC 最有趣的提取要求：

使用更完善的排程演算法加快建構速度

三次開放式的提取要求可望縮短建構時間 重要的管理方式兩者都能改變 Ninja 接收新指令的方式 根據不同條件啟動：

• PR 2019：指派優先順序給要執行的指令 並使用建構記錄檔預估持續時間。作者狀態 大幅減少大型建構專案的建構時間 20 到 15 分鐘！

• PR 1949：限制產生新指令 以免增加負載限制這可避免建構作業造成超載 產生過多程序來執行相同 CPU 作業 再複習一下，機構節點 是所有 Google Cloud Platform 資源的根節點作者宣稱測試版本從 22 分鐘縮短為 15 分鐘 或符合特定條件的媒體規範

• PR 1140：新增對 Ninja 的支援 GNU Make taskserver 是 Ninja 和 以便協調 CPU 程序的配置。 它來自 Ninja 的 Kitware 分行。請特別留意 請參閱上一次的 PR作者沒有張貼時間，因此可能比較不會 很有用，因為叫用的程式必須明確支援此功能。

修正 Ninja 的建構輸出內容以進行長指令。

在建構期間，Ninja 只會為具有 已完成實務上，如果長時間執行的指令導致建構作業 然後：

• 如果指令逾時，如同在 CI 漫遊器一樣，在 長 Rust 連結指令，輸出內容或 Ninja 記錄檔，指出哪一個目標/指令實際上已過期！

• 在終端機上，單行狀態似乎凍結，但仍然顯示 最後一個已完成目標的名稱 令人困惑 (許多開發人員都以為造成延遲的根本原因)。如要 使用「ps」即可瞭解實際問題但只有少數幾個終端機 大家都知道這個現象

第一點是 Fchsia 版本的問題， 必須修改 Ninja 才能解決第二項功能是可用性 持續向使用者出錯 可以有多個提取要求，以不同的方式修正：

• 列印「仍在等待中」用於長時間執行指令 #678
• 建議/仍在執行 #629。
• 顯示中斷邊緣 #1026 的列印完成狀態。
• 指令啟動 #1158 時進行列印。
• 新增 NINJA_STATUS_STARTED 和 _FINISHED #1191。
• 只在等待一個邊緣時，顯示該邊緣的列印狀態。

這是因為 Ninja 輸出的文字型式， 格式有限，其中也包括任意指令輸出內容，以備不時之需 發生錯誤。這會造成各種細微的問題 進而讓輸出結果難以穩定剖析。

這的確是刻意引進目前的行為 並解決 Ninja 的建構輸出內容無法機器剖析。 因此，凡是輸出格式的任何變更，都會視為 上游。

但就 Fuchsia 而言，剖析 Ninja 輸出內容是由 Fuchsia 基礎架構團隊控制， 即使問題能夠完全解決，輸出的呈現格式也很合理。

序列化狀態更新，更精準地篩選記錄檔

Android 自訂功能的另一個有趣功能 ，而是將狀態更新傳送至外部 「前端」作為結構化二進位資料流。

這讓 Android 團隊透過以下方式儲存多個輸出串流： 收集錯誤訊息至個別檔案 以及產生可載入範本的準確建構追蹤記錄 chrome://tracing.

對於 Fuchsia 版本，我們應該能夠從 Android 分支版本都能取得相同優勢

請注意，此要求是以提取要求的形式提出，但在某個要求後卻被拒絕 長篇 討論中，上游做出的結論為 有效解決輸出剖析問題 將 Ninja 轉變成圖書館，大幅 因程式碼集狀態而付出的努力 (有人試圖用這個方式) 需要 120 個修訂版本的實驗性 PR)。

提升開發人員體驗

Android 分支實作了大幅加快 (最高 22 倍) 的剖析速度 Ninja 輸入檔案，透過使用執行緒剖析輸入的分割。 導致最終傳遞中合併的符記

這項結果的動力是 Android 建構工具在 API 中 1.2 GiB 的 Ninja 建構方案，花費 12 秒的時間完成剖析，然後才執行任何作業 （位於有熱檔案系統快取的強大工作站上）。

Fuchsia 版本正好遇到類似情況， 目前 Ninja 建構計畫大約有 800 MiB，需要 10 秒才能剖析 讓漸進式建構令人煩惱Fuchsia 打造團隊 這些改進是很重要的 版本使用的 Ninja 版本。

編寫程式碼時，編譯器錯誤訊息和警告是 提供意見回饋給開發人員對靜態語言來說更是如此 在 Rust 這類新語言中，Rust 的用途在於檢查 系統在編譯期間提供多種條件因此，就輪到取得意見回饋的時間 是提升開發人員工作效率的關鍵每秒都在等待編譯器的時間 就是開發人員正在猜測程式碼是否正確 或者可能分心 而快速提供意見 尤其是仍在學習語言的程式設計人員。

最具工作效率的環境在開發過程中立即提供意見回饋 儲存環境這裡有「心流」的感覺非常重要 Fuchsia 開發人員開發出實用工具， 或是不同的建構系統 (貨比)，以便快速取得意見回饋和測試週期。 儘管這項工具不受支援，但部分開發人員仍在使用這項工具 並定期違規

對 Fuchsia 來說，每次叫用時最多需要 10 秒的時間 剖析本身的建構檔案 (build.ninja 檔案及其他檔案) 包含)。這部分的產品速度比我們多快 而且比起現今可提供的貨物，速度還慢了 25 倍以上。 搭配其他工具工作流程，將剖析時間縮減 25 至 100 倍。 我們能夠將撰寫程式碼 取自「慢板搖曳的螺旋槳」的 Fuchsia「簡潔、靈敏」的概念。 大幅加快開發週期、工程師更快樂，且更高 品質軟體

下方是目前變更程式碼體驗的螢幕截圖 並檢查編譯錯誤。

開發人員意見回饋的延遲幾乎完全歸因於 Ninja 是花費在剖析檔案的時間與 IDE 體驗下方的示範比較 與修補的 Ninja 相見歡

同樣地，fx setup-go 是專為單獨使用 Go 建構系統而建立 正因如此 速度太慢

提醒您，這項功能是由 Android 團隊在 2019 年提出，但 當時遭到上游維護人員拒絕，原因是 C++11 (系統尚未視為可接受的) 這個 C++11。此時間已經過了 這類切換程序可用於 Google 保持動力部分

改善使用者介面

下列 PR 是 並在互動式終端機中實作類似資料表的狀態輸出內容 靈感來自於 Buck 建構系統 (請參閱 動畫範例)。

雖然 PR 遭到作者捨棄，但為了提供 改善本機建構 Fuchsia 時的使用者介面。

相關人員

講師：

pascallouis@google.com 已委任 FEC 指派此 RFC 執行 RFC 程序

審查者：

shayba@google.com、版本 maruel@google.com、Fchsia Platform EngProd abarth@google.com，平台主管

積極參與先前討論這些議題的團隊成員 主題：

brettw@google.com (做為 Fuchsia 工具的貢獻者)。 angism@google.com、Build haowei@google.com、LLVM for Fuchsia jayzhuang@google.com，版本 olivernewman@google.com、Fchsia CI phosek@google.com、Fchsia Toolchain

諮詢：

angism@google.com、Build jayzhuang@google.com，版本 tmandry@google.com, Fuchsia 上的 Rust rudymathu@google.com、Fchsia EngProd

社交功能：

這個想法由 Fuchsia 團隊的 Rust 堅持提出，然後 透過 Google 內部電子郵件討論串加入社群，現在則在這裡 ，以便進一步討論及核准產品

設計

系統會使用 Fuchsia 控管的 Git 存放區，將上游 Ninja 分支 master 分支版本，用於管理包含 Fuchsia 專屬分支版本 自訂項目，同時追蹤上游 origin/master。修補程式會 應由分支的 OWNERS 審查，應視為 視個案情形而定：

• 提供的福利
• 修補程式的可維護性
• 從上游衍生，這會影響可維護性。

和其他擁有者認為適用的其他條件。

本機修改清單會由 FUCHSIA.readme敬上 導入為標準做法

該分支的維護人員就是 Fuchsia Build Team 負責 Fuchsia 建構系統及其正確性 可維護性和效能

這個 RFC 旨在確保這個分支版本不會 導致上游變更難以整合。 為達成此目標，系統會採用下列策略：

設法讓 Fuchsia 分支接近上游

Fuchsia Ninja 分支版本應合併為 我們會定期建立模型 "usptream-sync"表示變更是一系列乾淨的 修補程式。幾張圖片應該有所幫助 解釋成效

建立自訂 Git 分支時，一般會在上方建立新的分支 現有的上游版本，並且新增修訂版本。下圖 說明「上游」將歷史深藏在 「Fuchsia」 的分支版本，在其上新增 3 個修訂版本：

upstream  ___U1__U2___
                      \
fuchsia                \__F1__F2__F3

維護人員會將修訂版本新增至上游專案。上游 冰沙的歷史發展現在有別以往，例如：

upstream  ___U1__U2______U3__U4__U5
                      \
fuchsia                \__F1__F2__F3

要將上游變更套用至冰箱分支版本，最簡單的方法就是執行 合併作業，這可能會揭露需要執行的修訂版本之間的衝突 手動解析，如下所示：

upstream  ___U1__U2______U3__U4___U5___
                      \                \
fuchsia                \__F1__F2__F3____\F4__

其中 F4 代表合併修訂版本。現在的「Fuchsia」具有所有 改善成效，但無法以序列方式表示 更新修補程式 (即 U5)。

為維持這個目標，請避免直接合併到 毛茸茸星請改為建立 Fuchsia 分支版本的複本 重新使用 U5 層，並解決任何衝突 (這樣做都可以 本機先執行，並使用 git rebase 作業)。我們來稱呼這個分支版本 upstream-sync-U5，如：

upstream  ___U1__U2______U3__U4__U5
                      \            \
upstream-sync-U5       \            \__F1'__F2'__F3'
                        \
fuchsia                  \__F1__F2__F3

fuchsia 和 upstream-sync-U5 的功能應等同於 (透過測試強制執行)，新修訂版本 F1 的內容 到 F3'甚至可能與 F1 和 F3 相同，除非某些衝突需要使用 均已解決。

現在您可以將後者合併到前者，解決 直接套用 upstream-sync-U5 的變更來發生衝突，例如：

upstream  ___U1__U2______U3__U4__U5
                      \            \
upstream-sync-U5       \            \__F1'__F2'__F3'
                        \                           \
fuchsia                  \__F1__F2__F3_______________\F4

之後在與其他上游變更同步時，可以重複上述步驟，例如 於：

upstream  ___U1__U2______U3__U4__U5__________________U6__U7
                      \            \                       \
upstream-sync-U5       \            \__F1'__F2'__F3'        \
                        \                           \        \
upstream-sync-U7         \                           \        \__F1"__F2"__F3"__F5"
                          \                           \                            \
fuchsia                    \__F1__F2__F3_______________\F4__F5______________________\F6

每個新的 upstream-sync-XXX 分支版本都會表示自訂狀態 發布新的修補程式這個 讓 Fuchsia 將改變更容易理解，並改善 視需要將圖片導回上游

Fuchsia 分支版本的維護人員應建立上游同步分支版本 。

實作

分支版本會在以下位置的 Git-on-Borg 執行個體中維護： https://fuchsia.googlesource.com/third_party/ninja (已存在)， 和其公開 Gerrit 執行個體將用於審查並接受修補程式。

用於建構 Ninja 預先建構二進位檔的 LUCI 方案 對於 Fuchsia 平台版本，我們會據此切換來源的 GIT 網址， 因為該架構目前指向上游 GitHub 存放區的鏡像。

成效

縮短 Fuchsia 平台的建構時間是此 RFC 的主要動機 同時也改善開發人員體驗，同時加快工具回應速度 次。

人體工學

縮短提供開發人員意見所需的時間，可讓開發人員更臻完善 並減少環境切換

這種縮短延遲時間也開創了新的用途，供 Fuchsia 的建構系統使用，例如 回報 IDE 內部對依附於 產生的檔案。包括使用 FIDL 的程式碼，以及所有 Rust 和 Go 的程式碼 Cloud Build 觸發條件 會在您變更原始碼時自動啟動建構作業

回溯相容性

樹狀結構內工具可以使用由 紫紅色的支柱任何要在 Fuchsia 樹外使用的工具 不得假設自己的忍者有福希西亞的 Ninja。

不過，這些 Fuchsia 專用功能應只有嚴格的最低限制 因為能復原至上游是這個 RFC 的一大目標

例如，對於某些用途，有效的替代方式是編寫離線工具 會直接剖析 Ninja 建構計畫並執行運算 (與 https://fuchsia-review.googlesource.com/c/fuchsia/+/644561).

安全性考量

這項異動應該不會對安全性造成任何重大影響。Ninja 已經 能夠在開發人員的系統上執行任何指令任何安全性 Ninja 的漏洞也很容易出自上游，而我們的分支 邀請 Fuchsia 工程師一同審視每一項變更，所有變更 維持營運

使用 Google 的標準原始碼工具套件， 可能發生的程式碼供應鏈問題

隱私權注意事項

本提案不會對隱私權造成任何影響。

測試

與目前的情況相同，Ninja 測試套件將可執行任何變更 提交至 Fuchsia 的 Ninja 分支，包括上游同步合併。 變更內容必須遵循 Ninja 的標準測試做法，包括 單元測試

說明文件

標準 README.fuchsia敬上 檔案就會在 Fuchsia Git 分支版本的頂端，提供說明 分支版本與上游目前狀態之間的差異。

郵件中會包含這個 RFC 的連結，用於說明分支管理策略 來說明

缺點、替代方案和未知

本提案的主要缺點是確保 執行上游同步分支版本 每項此類作業都可能會觸發一或多項操作 重增衝突，維護人員需要手動解決 Fuchsia 分支版本

提醒您，想要輕鬆修正這些問題，最好的方式是 在許多小小塊中分解 Fuchsia 分支版本的變更 (每個項目都會產生可完整測試的來源樹狀結構)。

嘗試使用 Android Ninja 分支版本做為起點 但差距非常大剛剛合併近期更新 需要解決大量變更 衝突 (例如將所有內容都切換至 C++17 並移除 C++03 支援程式碼)，而且無法重新建構 放入整組乾淨的上游程式庫

從上游開始，並重述幾項 Android 專屬功能 因此，這個解決方案似乎是更好的解決方案，能夠帶來成果 幾週後

此外，我們還做了幾項嘗試，藉此達到相同目的 完全不需要變更上游修補程式 Ninja，但是它們都很短。最值得注意的是 多年調查和 我們進行了多項改變 Ninja 免人工管理建構時間。然而，找到這顆星球真的很失望 我們只達到了邊際改善

請注意 Ninja 目前由多個不同的 Google 團隊使用 有些人表達對統一的管理方式 Ninja 在整個公司推動發展，或是設法讓 上游維護人員此 RFC 並未防止任何上述情況 但其首要之務是迅速為 Fuchsia 平台帶來優勢 首先。

最後， Fuchsia 現在有 Bazel SDK，並展示了 Bazel 為 Fuchsia 元件打造 (請參閱 RFC-0139)。 長期來看， Fuchsia 應該考慮改用 Ninja 的替代方案 做為建構後端的平台，探索未來一年可能的發展 遷移作業。基於此 RFC 目的，我們會將這類遷移作業視為 不要超出服務範圍