C 以及 C++ 雖然經歷過標準化，但缺乏單一的掌控者。現實世界里的 C/C++ 猶如神圣羅馬帝國，固然有一個委員會在名義上號令天下，但事實上是各路諸侯的方言割據：Vistual Studio 的 C 與 GCC 的 C 不一樣，而 GCC 的 C 又與 Clang 的 C 不一樣；除去這些巨頭之外，又有 Intel 的 C、Borland 的 C、K&R C、甚至譚浩強的 C，它們彼此都不盡相同；而如果愿意再細分的話，每一類處理器、操作系統、函數庫的 C 都有或多或少的不同。

具體不同在何處呢？舉例而言，在語法層面上，GCC 為 C 增加了許多擴展

這種紛亂的異構盛況，其他語言也不是沒有，但在 C/C++ 這邊是如此嚴重，使得維護一個像 pip 這樣(在大部分時候)可以跨硬件架構、跨操作系統、跨語言版本、跨工具鏈的包管理工具變得極為困難。而且大多數 C 開發者事實上并沒有這樣的需求，因為需要用 C 語言做的事情通常比較底層，與操作系統緊密相關，甚至就是用來開發操作系統本身，畢竟它誕生的使命就是開發 Unix。五十年過去，現代 Unix-like 操作系統仍舊緊密圍繞著 C 構建而成，而這些操作系統的包管理工具實際上也管理著一部分 C/C++ 的生態。許多為人熟知的 Linux 發行版將軟件包分為「實體包」和「開發包」兩類，通過同一套命令安裝；BSD 則有「二進制包管理」和「源代碼包管理」之區分，通過 package 和 port 兩套系統完成。

以正則表達式庫 PCRE 為例，在 Debian / Redhat 一類發行版上，`apt install libpcre3` / `yum install pcre` 會安裝已經編譯好的二進制文件到 /lib 中，`apt install libpcre3-dev` / `yum install pcre-devel` 則會安裝對應的頭文件到 /usr/include 中去

當然，系統級別的包管理器畢竟由管理系統的角度而設計，無法(很好地)解決一些軟件開發所需解決的專門問題，比如多個版本的并存，依賴關系的管理，乃至于軟件的調試、包裝和部署。所以為了 C/C++ 而專門設計的包管理器同樣存在，目前看起來發展相對成熟，用戶群也相對穩定的，大概是 JFrog 的 Conan

那么 Conan 跟 vcpkg 如何解決「跨硬件架構、跨操作系統、跨語言版本、跨工具鏈」來維護程序包這個問題呢？vcpkg 解決得并不太好，至少目前(二〇二〇年底)它的出發點其實還是以 Visual Studio C++ 項目為優先服務對象提供解決方案。而 Conan 相對而言比較全面，但機制也更復雜：先以名為 conanfile.py 的 Python 腳本來描述一個包所適用的架構、操作系統、編譯類型、以及其依賴，并根據其中與編譯相關的條件生成一個 hash，然后將源代碼或者二進制庫和頭文件分別按照 hash 打包。包的使用者則自行指定、或要求 Conan 自動檢測所在編譯環境，也生成一個 hash，據此下載對應的包，然后 Conan 根據腳本進行需要的編譯、patch 等工作，然后將頭文件與二進制庫的路徑生成為可以被 MSBuild、CMake、QMake 等構建工具所使用的文件。

這個答案一直在我草稿箱里扔了五六年，剛寫好時覺得這是典型的用很多廢話來回答簡單的問題，想想還是算了。而今天寫 conanfile 到痛不欲生又想起它，感覺還是解釋了一個內行人肯定知曉、新手卻未必了然的現況，就決定還是改一下發布出來。五六年后的世界還是變化很大的，知乎早已不是那個知乎(劃掉)比如 vcpkg 這個東西，這問題提出來的時候還根本不存在。

C 語言很古老，但并不意味著它已經停止演進——嗯，我這里順便推一本書，21st Century C: C Tips from the New School：

以及，如果你還不知道的話，《C專家編程》，這本倒是有中文版：

參考

總結

以上是生活随笔為你收集整理的python中有很多包管理工具有哪些不是_C 语言中有没有类似 Python 中 pip 的包管理工具？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。