以下列出基於 Lua 的建置系統[1]。其功能類似於 make[2]、SCons[3][4]、CMake[5][6]、Autotools[7] 和 CPAN.pm[8] 等工具，差別在於這些工具或建置檔案是以 Lua 編寫的。
- 類似 SCons 的系統
- 建置腳本產生器（例如 Autotools 和 CMake）
- [premake] - 建置腳本產生器（類似 CMake，但使用 Lua 作為組態語言）
- [xmake] - 基於 Lua 的跨平台建置工具，可載入建置腳本產生器外掛程式
- [Hamster] - Lua 建置腳本產生器，API 源於 [scons]。可產生 Makefiles（GNU/BSD/nmake），使用 SCons 建置，或是不使用外部工具建置。
- [makebuild.lua] 用不到 100 行程式碼撰寫的基本 Lua Makefile 產生器。
- [9] - rockspec 轉換成 Makefile 的概念驗證
- [bang] - 可以用 Lua/LuaX 編寫腳本的 Ninja 檔案產生器
- 其他
- [jamplus] - Perforce Jam 的派生版本，加入了各種增強功能，例如輸出 Visual Studio IDE、Xcode 及 Code
- [tundra] - Lua 組態語言會產生一個 DAG，由支援快速增量建置的多執行緒 C 建置工具消耗。註解：[11][12][13]
- [luacc] - 將多個 Lua 原始檔合併成一個。它是單獨的單一檔案 Lua 指令碼
- CPAN 風格的系統
- LuaRocks - 部署 Lua 模組，包括網路擷取、自動化建置、安裝和管理（例如 Perl CPAN）
- [luapower] - 模組使用直接呼叫 gcc 的簡單 Shell 指令碼建置
- 記憶化建置系統（例如 fabricate、memoize.py、fbuild 等）
- 參見
以下列出的建置系統不一定以 Lua 實作，但仍可已用於建置與 Lua 相關的程式碼
此類建置自動化系統 ([1]) 涵蓋以下主題
- 編譯程式碼或其他檔案。其中包含一些部分
- 有些設定語言定義要建置的內容以及順序。這可能是 Makefile 的形式。它可能使用特定於問題領域的受限語言，但是由於可能需要對編譯什麼和如何編譯做出決定，因此有些通用語言功能很有用，例如變數、控制結構、函式/巨集和字串/清單處理。有些系統使用 Python（例如在 SCons 中）或 Lua。即使您的建置系統未使用 Lua 作為設定語言，您仍然有可能從中呼叫 Lua 解譯器。
- 有些方式可將設定語言中的高階建置描述（例如由 C 檔案清單編譯共享函式庫）轉譯為實際執行的指令（具備開關的編譯器命令列）。這可能需要了解每個受支援的工具鏈，工具鏈可能內建於建置工具中，或可由使用者定義。有些較簡單的建置系統（例如 make）不直接提供此等知識，而是交由使用者輸入低階建置描述。
- 有一些方法可以安排命令執行，包括確保它們基於相依性以特定順序執行、使工作排列在不同的 CPU 核心或機器上平行執行、在目標是最新的情況下略過命令（根據時間戳記或校驗和），以及查看錯誤結果。這通常與實際執行命令緊密結合，例如透過 os.execute 或一些更進階的特定平台程序控制機制或工作處理器。可在設定語言內（例如 SCons）呼叫指令。或者，這個工作可能被外包給其他現有工具，就像「makefile 產生器」（例如 Automake、CMake 或 premake）所做的那樣，它們會產生，例如 makefile、ninja 建置說明，或 msbuild 說明，以便在後續建置步驟中分別使用。如果相依性改變，可能需要重新產生 makefile，並且有些方法可以將此插入 makefile 本身。在某種程度上，可能需要動態確定相依性樹（例如 C include 檔案）。
- 可能有一些平台偵測方法（例如偵測可用的主機編譯器、函式庫和符號），例如 autoconf。這個資訊用於「翻譯高階建置說明」。有時會在建置程序的一部份執行，或（例如在 autoconf 中）可能是在建置程序之前執行的一個步驟，而且在增量建置期間不會重新執行，假設平台不會改變。工作處理器可能需要這樣做，例如在主機平台上測試編譯（假設沒有跨編譯到不同的目標平台）。
- 執行測試（make test）、部署（make install）和封裝（例如 .deb）。
- 部署和/或編譯相依性，例如 LuaRocks、LuaDist 中的部署工具，以及 CPAN。
顧慮包括
- 建置系統部署的容易性。如果建置系統通常預先安裝（例如 make），或容易安裝（apt-get install cmake），或者可能有較小的佔用空間和容易部署，甚至綑綁在您的套件中（例如 [primemover]），會很方便。
- 熟悉度。學習、除錯或維護一個不熟悉、非標準、有錯誤、不可彈性的建置系統並不好玩。會想寫自己的建置系統很誘人，但這是需要付代價的。
- 平台支援。這個工具知道如何在您的平台和工具鏈上建置嗎？
- 普遍性。如果您的建置只呼叫自訂命令（例如建置網頁或影像，而不是 C 程式碼），定義您自己的任意規則（例如在 make 中）的便利性比擁有廣泛的內建工具鏈支援更重要。
- 速度。增量建置的速度有多快？是否支援平行建置？預編譯標頭檔？
- 支援平台偵測（例如 autoconf），如果需要支援許多平台的話。
- 設定語言。
- IDE 整合，例如在 premake、CMake 中，或較小程度上 [SCons]。
- 建置程序的可靠性。
最新變更 · 選擇
編輯 · 歷史
最後於 2024 年 1 月 17 日上午 8:21 GMT 編輯 (對比)
