1. 中心點不一樣
vcpkg: 以cmake為中心钮莲，只做cmake的額外補充痊焊，本質上不改變cmake原有的特性囊陡，僅僅是為cmake提供了額外的自動依賴庫下載，以及版本控制蛾绎，而且還額外添加了一些自動化成分（比如：自動設置rpath昆箕、自動拷貝dll），所有的工作幾乎都是非侵入式的 租冠，可以做到不修改現有代碼就能移除vcpkg鹏倘。
conan: 以自己為中心，cmake只是它支持的構建系統(tǒng)其中之一顽爹，同時支持Visual Studio Solution纤泵、Meson、AutoTools镜粤、MakeFile等
正是因為conan是以自我為中心的捏题，因此，它自己提供了一套自己的API來覆蓋別的構建系統(tǒng)的肉渴，看起來像是重復造輪子公荧，下面舉2個小案例，比如：
- CMake明明自己可以通過
cmake_minimum_required(VERSION 3.0.0)約束最小cmake版本同规。然而循狰，Conan必須在conanfile.text或者conanfile.py里定義最低cmake版本：
# conanfile.text
----------------------------------
[tool_requires]
cmake/3.22.6
- CMake工程內部的子模塊可以通過add_subdirectory()的方式加入窟社，可以說構建的時候想加哪幾個就加幾個，如果你加了一個example子模塊绪钥，通過add_subdirectory(example)在Conan里卻還要接受Conan的管控灿里，還需要在
conanfile.py里配置：
exports_sources = "CMakeLists.txt", "src/*", "example/*"
如果你的項目集成了gtest，即便你能通過find_package(gtest)集成gtest到你的項目里了昧识，然而conan還要插一腳钠四，即：在conanfile.py里通過配置控制是否啟用gtest，其實就是啟用后往CMake注入一個BUILD_TESTING變量跪楞，然后CMake得通過它判斷是否要find_pacakge(gtest)：
def build(self):
cmake = CMake(self)
cmake.configure()
cmake.build()
if not self.conf.get("tools.build:skip_test", default=False):
test_folder = os.path.join("tests")
if self.settings.os == "Windows":
test_folder = os.path.join("tests", str(self.settings.build_type))
self.run(os.path.join(test_folder, "test_hello"))
cmake_minimum_required(VERSION 3.15)
project(hello CXX)
...
if (NOT BUILD_TESTING STREQUAL OFF)
add_subdirectory(tests)
endif()
...
通過設置
tools.build:skip_test這個屬性往CMake注入BUILD_TESTING變量缀去，這是非常典型的重新發(fā)明輪子來覆蓋CMake的，其實Conan的很多配置處處在提現重新包裝CMake甸祭，正常我們的項目只用CMake作為構建系統(tǒng)的話缕碎，那么Conan這么個搞法會顯得很繞，多此一舉池户。
其實咏雌，當今的C/C++已經全面向CMake轉變了，包括Android系統(tǒng)源碼從MakeFile轉向支持CMake校焦、Qt的源碼從QMake構建轉向CMake構建赊抖，以及Visual Studio也全面支持CMake，多樣化構建系統(tǒng)已經慢慢被CMake統(tǒng)一了寨典，Conan的走兼容多構建系統(tǒng)會不會有些過了氛雪？而且在Conan的官網教程里所有的篇幅基本都是圍繞著CMake，感覺它的理想和現實有點尷尬耸成。
2. 跨平臺的思路不一樣
??vcpkg的跨平臺是利用C/C++實現的报亩，以及對CMake函數的再次擴充，在使用vcpkg實現包管理的過程中都是通過執(zhí)行它額外擴充的cmake函數來實現的（可能內部調用了它的C/C++可執(zhí)行性文件）井氢，因為都是cmake函數因此看起來無關平臺差異弦追。
??conan的跨平臺屬于自造體系，自立門戶花竞，將python的運行環(huán)境搬進來作為跨平臺的支持劲件，然后發(fā)明了一套適配并操作多構建系統(tǒng)的API，同時又利用了windows的batch和linux的shell约急，比如：生成了用于自動設置LD_LIBRARY_PATH和DYLD_FRAMEWORK_PATH的shell零远，不過vcpkg會默默后臺幫你做這類事情，讓你感覺不到額外的工作和侵入性烤宙。
3. 托管庫的策略不一樣
??Conan明顯走Java Maven的路線遍烦，即：用Web文件服務器托管編譯好的二進制的思路，跟Java的Maven服務器托管Jar包如出一轍躺枕，但別忘記了Java的Jar是跨平臺的服猪，同一個庫所有平臺只要一個Jar供填，而C/C++就不一樣了，多平臺多ABI的庫文件是不兼容的罢猪，正常的C/C++庫都有一堆頭文件近她、SO文件、DLL文件膳帕、Lib文件粘捎，托管一個庫的所有平臺的二進制庫文件壓力是很大的，磁盤占用會遠比Mava那套占用的多危彩，即便是ConanCenter也做不到所有庫全平臺托管攒磨，想象下所有platform（android、iOS汤徽、mac娩缰、linux、windows）和所有ABI(arm64谒府、arm-v7a拼坎、arm-v8a、mips完疫、mips-64泰鸡、arm64、x86壳鹤、x64)來個笛卡爾積——恐怖如斯盛龄，也因此，這些巨大的補全工作丟給了社區(qū)器虾，然后你會偶爾發(fā)現同一個庫的不同版本可能是來自不同源碼構建出來的讯嫂，質量良莠不齊——很不幸我們項目就遇到了, 然后不得已自己編譯那個庫的源碼蹦锋，并托管在私有jfrog里兆沙，然后又因為此庫在私有托管的jfrog和conancenter里托管的沖突，不得已得將conancenter禁止了莉掂，隨后所有的別的依賴都得單獨在自己的jfrog里重新傳一遍——痛啊葛圃。
??vcpkg不走托管方式，vcpkg只做映射方式憎妙，在vcpkg維護了所有主流C库正、C++的開源庫，每一個庫都是通過配置文件指向庫對應的官網源碼下載地址（github, gitlab, bitbucket,文件服務器）厘唾，并同時指定版本(對于git庫則是commit id或者對于zip文件則是SHA265)褥符。Conan引導的方向是即時編譯成所在平臺所需的庫，因此抚垃，vcpkg不像conan需要一個單獨web文件服務器來存放編譯好的二進制庫文件喷楣，當然編譯緩存肯定是重復利用的趟大，不然每次編譯會耗費巨大等待時間∠澈福可能逊朽，你要問了，同樣的庫代碼每個人都要經歷一次編譯也挺費時間曲伊，其實vcpkg是允許配置一個共享服務器來實現緩存共享的叽讳，vcpkg建議的策略是通過CI來貢獻編譯緩存，然后開發(fā)者配置共享服務器路徑來獲取編譯緩存坟募，然后本地開發(fā)的效率會得到極大提升岛蚤！即便緩存損壞，只要再跑一遍CI即可懈糯，遷移緩存也容易灭美，復制到另外一個共享盤目錄下并配置下新的緩存路徑即可。
