Show HN：我為 C/C++ 開發了一款類 Cargo 的構建工具

背景

Craft 是一款針對 C 與 C++ 開發者設計的輕量化構建與工作流工具，其核心理念是效法 Rust 生態系中的 Cargo。開發者 randerson112 因為厭倦了每次啟動新專案都必須耗費大量時間撰寫 CMakeLists.txt、處理依賴關係與處理連結問題，因此開發了這套工具，讓使用者只需透過簡單的 craft.toml 設定檔即可自動生成 CMake 配置並管理專案生命週期。

社群觀點

Hacker News 社群對於 Craft 的出現反應兩極，這反映了 C/C++ 生態系長期以來在構建系統上的分歧。支持者認為 Craft 確實抓住了痛點，特別是對於想要快速啟動原型專案或小型應用的開發者來說，簡化 CMake 的複雜度極具吸引力。然而，資深開發者則提出了一系列務實的質疑。首先是關於「封裝層」的爭議，部分評論者認為在 CMake 之上再套一層工具（meta-meta build system）並非根本之道，若要解決問題應直接取代 CMake 而非僅是包裝它。此外，針對複雜的工業級專案，如涉及交叉編譯、嵌入式系統或特定平台的編譯器選項時，Craft 這種高度抽象化的工具是否能提供足夠的彈性（如 CMake 的 toolchain 支援）仍存有疑問。

在依賴管理方面，社群展開了激烈的討論。有人指出 C/C++ 的依賴問題遠比 Rust 複雜，因為它涉及動態連結、系統級庫的搜尋以及 ABI 兼容性等問題。雖然 Craft 提供了類似 Cargo 的指令，但評論者擔心它在處理「鑽石依賴」或需要複雜 Makefile 腳本才能構建的舊型庫時會力有未逮。此外，針對安裝方式採用 curl | sh 並修改 bashrc 的作法，也引發了關於安全性與供應鏈風險的批評，部分使用者認為這對於追求嚴謹與可重現性的系統開發者來說並非良好的實踐。

有趣的是，討論中也出現了對現代開發模式的辯論。有觀點認為在 AI 時代，學習複雜的構建語法已不再必要，透過大型語言模型即可快速生成所需的構建腳本；但反對者隨即反駁，認為 AI 無法解決路徑搜尋、版本衝突與跨平台配置等核心邏輯問題。對於專業的軟體整合商而言，他們更關心工具是否支援離線編譯、是否遵循 pkg-config 等工業標準，以及是否能避免如 -march=native 這種破壞移植性的預設選項。整體而言，社群肯定 Craft 改善開發體驗的初衷，但對其能否應付 C/C++ 領域那種極端複雜且破碎的現實環境持保留態度。

延伸閱讀

在討論過程中，社群成員也推薦了其他試圖解決類似問題的工具與資源。其中 xmake 被多次提及，認為其在易用性、功能完整度（如支援 C++20 模組）以及與現有包管理器（如 Conan, vcpkg）的整合上表現優異。此外，針對追求嚴謹依賴管理的開發者，Conan 2.0 與 Nix flakes 被視為更成熟的替代方案。對於想深入了解現代 C++ 構建系統挑戰的人，留言中也推薦了 Nicole Mazzuca 在 Meeting C++ 2025 的演講《Building C++: It Doesn't Have to be Painful!》，該演講深入探討了構建系統為何難以收斂的根本原因。最後，也有人建議參考 Python 的 pyproject.toml 標準，思考如何建立一個能被多種工具共同採納的配置規範。