這次不聊框架選型也不聊奇技淫巧就說Windows開發(fā)者在C項目里繞不開的痛——依賴管理。如果你在Windows上用C做過正經(jīng)項目八成經(jīng)歷過類似的一幕想用OpenSSL去官網(wǎng)扒源碼拿Perl跑Configure然后被一堆警告刷屏想用JsonCpp下載源碼夾帶一堆構(gòu)建腳本CMake參數(shù)調(diào)半天好不容易編譯完頭文件路徑、庫文件路徑、運(yùn)行庫DLL全部手動配置一不小心版本不兼容就是一場災(zāi)難。這套流程每來一次都是在消耗生命。后來我換成了vcpkg這些折騰基本消失了。這不是廣告是我自己在多個Windows C項目里實測下來的結(jié)論。這篇東西我盡量寫全從設(shè)計理念到具體操作從經(jīng)典模式到manifest模式再到那些官方文檔里不會明說的坑希望能幫你一次性把依賴管理理順。1. Windows上C依賴管理的困局到底卡在哪想理解vcpkg的價值先得認(rèn)清Windows平臺在C依賴管理上的歷史包袱。Linux生態(tài)有apt、yum這類系統(tǒng)級包管理器macOS有Homebrew一條命令裝庫依賴自動解決版本自動管理。但Windows沒有這套東西導(dǎo)致C開發(fā)者長期靠“手工”生存。1.1 手工管理依賴的三種常見姿勢以及它們的短板第一種姿勢是“官網(wǎng)下載編譯版”。庫作者通常會提供預(yù)編譯的二進(jìn)制包zip包里通常有include目錄、lib目錄、bin目錄。你解壓后手動配置Visual Studio的附加包含目錄和附加庫目錄再把dll拷到運(yùn)行目錄或System32。這套路看著簡單實際維護(hù)成本極高不同庫依賴不同版本的運(yùn)行時比如有的用MD有的用MT不同庫之間的依賴關(guān)系沒人幫你梳理升級一個庫可能連帶要手動升級三個關(guān)聯(lián)庫出問題排查起來非常費(fèi)時。第二種姿勢是“源碼編譯”。很多庫沒有提供Windows二進(jìn)制包或者提供的版本太老就得自己編譯。典型的流程是下載源碼裝依賴工具有的需要Perl有的需要Python有的需要NASM跑Configure跑Make然后再集成到工程。每個庫的工具鏈還都不一樣OpenSSL那套和FFmpeg那套完全是兩種玩法。單個庫折騰一小時算快的項目依賴十幾個庫的時候工作量是線性疊加的關(guān)鍵是這些勞動毫無復(fù)用價值。第三種姿勢是“直接拷貝別的項目的依賴”。很多團(tuán)隊是A項目把依賴編譯好了B項目直接拷貝A項目的include和lib目錄。這招初期效率很高但隱患極大不同項目對同一個庫的版本要求不一樣你拷過來的可能是某個有已知漏洞的版本更麻煩的是一旦A項目升級了依賴B項目還在用舊版兩個項目之間的庫文件一旦混淆調(diào)試期會非常痛苦。1.2 依賴地獄在Windows C項目里的具體表現(xiàn)依賴地獄不是形容是真實場景。DLL地獄運(yùn)行時找不到dll報錯0xc000007b或者“無法定位程序輸入點(diǎn)”原因往往是某個第三方庫的dll版本覆蓋或者依賴鏈里某個庫升級后ABI不兼容。頭文件地獄同一個庫的多個版本漂在系統(tǒng)里include順序稍微不對編譯器載入的是另一個版本的頭文件和lib不匹配鏈接錯誤一堆。構(gòu)建系統(tǒng)地獄每個庫的構(gòu)建方式不同有的用CMake有的用Autotools有的直接給Visual Studio工程。你得給每個庫單獨(dú)寫構(gòu)建腳本維護(hù)這些腳本本身就是個項目。傳播依賴地獄很多庫不是孤立的OpenSSL依賴zliblibcurl依賴OpenSSL和zlib你用libcurl就得先編譯OpenSSL和zlib。這種傳遞依賴靠手工理清時間和精力都會消耗很大。這些問題在Linux上幾乎不是問題因為系統(tǒng)包管理器幫你處理好了。Windows缺一個等價的工具這就是vcpkg出現(xiàn)的根本原因。2. vcpkg的設(shè)計思路以及為什么它比手動靠譜vcpkg是微軟開源的C包管理器2016年發(fā)布現(xiàn)在已經(jīng)是Windows C開發(fā)里主流的依賴管理方案之一。它沒有選擇“倉庫里放預(yù)編譯包”這種模式而是默認(rèn)“從源碼構(gòu)建”這一點(diǎn)決定了它和其他方案本質(zhì)上的不同。2.1 為什么vcpkg堅持從源碼構(gòu)建你第一次用vcpkg裝庫的時候肯定會吐槽裝一個OpenSSL要編譯幾分鐘效率太低了。但深入了解后發(fā)現(xiàn)從源碼構(gòu)建是最穩(wěn)妥的方案。原因在于C沒有穩(wěn)定的ABI二進(jìn)制接口。同一個庫用不同版本的編譯器編譯出來或者用了不同的運(yùn)行時庫選項/MD還是/MT產(chǎn)物是不能混用的。如果vcpkg直接提供預(yù)編譯二進(jìn)制就得針對MSVC的不同版本、不同架構(gòu)、不同運(yùn)行方式分別打包維護(hù)成本極高而且用戶一旦用了非標(biāo)準(zhǔn)選項就白搭。從源碼構(gòu)建相當(dāng)于“在你自己的機(jī)器上用你的編譯器按你的配置編譯的庫”天然匹配你的開發(fā)環(huán)境。第一次編譯慢點(diǎn)但之后都是增量編譯和緩存命中實際開銷遠(yuǎn)小于你手動折騰的時間和試錯成本。2.2 vcpkg和Conan、手動編譯的對比市面上C包管理器不止vcpkgConan也是知名方案。簡單對比一下vcpkg微軟維護(hù)Windows MSVC體驗最好CMake集成幾乎是零配置的學(xué)習(xí)成本低。Conan跨平臺能力強(qiáng)Python生態(tài)配置靈活度更高但學(xué)習(xí)曲線陡配置文件復(fù)雜Windows下還需要額外適配。手動編譯為零。對于Windows開發(fā)者、特別是Visual Studio用戶來說vcpkg的“傻瓜化”程度是最高的。它不是功能最強(qiáng)大的但它是“開箱即用”程度最高的。2.3 一個關(guān)鍵概念triplet三元組vcpkg里最重要的概念之一是triplet它決定依賴庫以什么“形態(tài)”編譯。常見的幾個x86-windows32位動態(tài)鏈接MD運(yùn)行時x64-windows64位動態(tài)鏈接MD運(yùn)行時最常用x64-windows-static64位靜態(tài)鏈接MT運(yùn)行時x64-windows-static-md64位靜態(tài)鏈接但用MD運(yùn)行時這是什么意思呢簡單說動態(tài)鏈接就是你的exe依賴dll發(fā)布時要帶上dll靜態(tài)鏈接就是把庫代碼直接編進(jìn)你的exe發(fā)布時只帶exe但exe體積更大。實戰(zhàn)中如何選如果你的項目要分發(fā)成綠色免安裝版優(yōu)先考慮x64-windows-static省去dll分發(fā)問題如果你依賴的庫有許可證問題或體積特別大選動態(tài)鏈接更省心。切換方式很簡單安裝時加后綴即可vcpkg install fmt:x64-windows-static不過這里有個經(jīng)驗之談不要在同一個項目里混用不同triplet的庫否則鏈接階段會遇到各種奇怪的符號沖突。一個項目一個triplet是基本原則。3. vcpkg完整上手安裝、裝包、集成三大步這一節(jié)全程實操從零開始配置一個可用的vcpkg環(huán)境。我寫的命令以Windows環(huán)境為準(zhǔn)VS2019/2022均適用。3.1 第一步安裝vcpkg兩個關(guān)鍵操作vcpkg不需要傳統(tǒng)的installer它就是一個git倉庫加一個引導(dǎo)腳本。安裝流程git clone https://github.com/microsoft/vcpkg.git cd vcpkg .\bootstrap-vcpkg.batbootstrap-vcpkg.bat會下載vcpkg.exe本體。這里有個強(qiáng)烈建議vcpkg目錄建議放在一個固定位置比如D:\vcpkg不要放在C盤系統(tǒng)目錄。因為vcpkg會緩存下載的源碼包隨著裝的庫多了體積可能達(dá)到幾個GB放系統(tǒng)盤只會給你的C盤添堵。安裝完成后把D:\vcpkg加入系統(tǒng)PATH這樣任何終端里都能直接用vcpkg命令。如果你不想加PATH就始終用完整路徑調(diào)用。3.2 第二步安裝第一個庫并驗證以格式化庫fmt為例一條命令vcpkg install fmt不帶triplet后綴時vcpkg會為當(dāng)前默認(rèn)架構(gòu)通常是x64編譯。編譯完成后你會在輸出里看到包路徑、頭文件位置、庫文件位置。同時vcpkg會自動把依賴一起裝好——裝OpenSSL時它會自動拉取zlib、perl等依賴這些在手工時代都是自己干的活。驗證是否安裝成功vcpkg list這個命令會列出所有已安裝的庫及版本號。如果fmt在列表里說明裝好了。3.3 第三步與Visual Studio集成最簡單的一步vcpkg最省心的地方在這里——它可以一鍵集成到Visual Studio無需手動配置頭文件路徑和庫路徑。管理員權(quán)限打開命令行執(zhí)行vcpkg integrate install這一步之后Visual Studio里的所有C項目自動獲得vcpkg里所有庫的頭文件和庫文件搜索路徑。你在代碼里直接#include fmt/format.h鏈接器自己會找到lib不需要任何工程配置。這是vcpkg相比手動編譯效率提升最大的地方一個團(tuán)隊里每個成員執(zhí)行一次vcpkg integrate install大家共用的依賴庫路徑就統(tǒng)一了誰也不用再去“共享文件夾拷依賴”。如果你用的是CMake同樣有集成方式。通過工具鏈文件cmake -B build -S . -DCMAKE_TOOLCHAIN_FILED:/vcpkg/scripts/buildsystems/vcpkg.cmake這行命令的意思是告訴CMake使用vcpkg提供的工具鏈來查找依賴。CMake的find_package會自動檢索到vcpkg里裝好的庫。這個用法后面講manifest模式時還會再細(xì)說。3.4 幾個常用命令日常操作就夠用vcpkg search name搜索可用庫比如vcpkg search opensslvcpkg list列出已安裝的庫vcpkg update查看可更新的庫vcpkg upgrade執(zhí)行更新會重新編譯變更的庫耗時較長慎用vcpkg remove name卸載某個庫vcpkg help triplet查看支持的所有triplet4. Manifest模式讓依賴管理進(jìn)入“可復(fù)現(xiàn)”時代經(jīng)典模式直接vcpkg install解決了個體裝庫的便利性但團(tuán)隊協(xié)作時還是有問題你的項目依賴哪些庫、什么版本、怎么裝的新人拿到代碼后一頭霧水。vcpkg的manifest模式就是來解決這個問題的。4.1 manifest模式是什么解決了什么坑manifest模式的核心是讓“依賴描述”跟著項目走而不是跟著機(jī)器走。你在項目根目錄放一個vcpkg.json文件里面寫明這個項目需要哪些庫、哪些版本。任何人在任何機(jī)器上拿到代碼執(zhí)行一次構(gòu)建命令vcpkg會自動讀取清單把所有依賴裝好、編譯好、集成好。對比一下經(jīng)典模式新人要在自己機(jī)器上手工執(zhí)行vcpkg install裝每個庫裝錯版本只能靠肉眼排查。manifest模式新人只需要cmake -B build依賴自動處理保證每個人構(gòu)建環(huán)境一致。這解決了“我這機(jī)器上能編譯你機(jī)器上不行”的歷史難題。依賴不再是個人環(huán)境里的潛規(guī)則而是項目代碼的一部分可審查、可追溯。4.2 vcpkg.json的寫法照著抄就行vcpkg.json用JSON格式描述項目依賴。一個最簡單的例子{ name: my-project, version-string: 1.0.0, dependencies: [ fmt, spdlog, openssl ] }name是項目名version-string是項目版本dependencies是依賴庫列表。這些依賴庫默認(rèn)使用vcpkg倉庫中的最新版本。如果想鎖定版本用builtin-baseline{ name: my-project, version-string: 1.0.0, builtin-baseline: 6f8e1d196ed94692420a26e2d2e678acb4f9d9a4, dependencies: [ fmt, spdlog ] }builtin-baseline的值是vcpkg倉庫的git commit hash。vcpkg會把依賴鎖定在該commit所對應(yīng)的版本而不是一直追最新版。這在商業(yè)項目里非常重要依賴升級是主動行為不是被動默認(rèn)。如果你想為特定依賴指定更細(xì)的版本要求可以在依賴項里寫version{ dependencies: [ { name: fmt, version: 10.0.0 } ] }運(yùn)行構(gòu)建時vcpkg會以清單描述為準(zhǔn)自動安裝并編譯所有依賴。第一步是執(zhí)行vcpkg install在項目目錄下vcpkg檢測到vcpkg.json時自動進(jìn)入manifest模式或者直接用CMake工具鏈方式構(gòu)建vcpkg也會自動觸發(fā)。4.3 與CMake的深度配合一個命令拉起全套環(huán)境我在項目里的標(biāo)準(zhǔn)做法是項目根目錄放vcpkg.json然后用CMake工具鏈文件構(gòu)建。命令很簡單cmake -B build -S . -DCMAKE_TOOLCHAIN_FILED:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_MANIFEST_MODEON第一次構(gòu)建時vcpkg會檢測到項目下的vcpkg.json自動開始拉取和編譯依賴。之后每次構(gòu)建如果清單沒變vcpkg直接復(fù)用緩存耗時幾乎為零。如果清單變了vcpkg只增量處理變更部分不會全部重編。這套機(jī)制用下來最直觀的感受是新同事入職拉完代碼執(zhí)行一條cmake命令等依賴編譯完成項目就起來了。新機(jī)器上沒有任何手工裝庫的步驟出問題的概率大幅降低。4.4 版本覆蓋和自定義端口進(jìn)階玩法簡介默認(rèn)情況下vcpkg用的庫版本是它自己維護(hù)的port文件構(gòu)建配方里定義的最新版本。如果你確實需要某個在vcpkg倉庫中不存在的庫或者需要修改某個庫的構(gòu)建方式可以創(chuàng)建overlay port覆蓋端口。做法是在項目根目錄建一個overlay目錄里面放自定義的port文件比如overlay/fmt/portfile.cmake。然后在CMake配置時指定cmake -B build -S . -DCMAKE_TOOLCHAIN_FILED:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_OVERLAY_PORTSoverlay這樣vcpkg會優(yōu)先使用你的自定義port而不是倉庫自帶的。這個功能適合企業(yè)內(nèi)部封裝的庫、需打補(bǔ)丁的公共庫等場景。5. 我踩過的坑vcpkg使用中的常見問題與排查技巧vcpkg確實好用但它不是沒有坑。尤其從“手動管理”切換到vcpkg時有幾個地方需要特別小心這里以實際經(jīng)驗為主逐步說明。5.1 DLL運(yùn)行時報錯最常見的問題用vcpkg默認(rèn)的x64-windowstriplet裝上庫程序編譯通過運(yùn)行時報“找不到fmt.dll”或“找不到libssl-3-x64.dll”。原因是動態(tài)鏈接的dll不在exe目錄也不在系統(tǒng)Path里。有三種解決方式按推薦程度排序方式一推薦在Visual Studio里把dll目錄加到調(diào)試環(huán)境的PATH。項目屬性 - 調(diào)試 - 環(huán)境寫PATH$(PATH);D:\vcpkg\installed\x64-windows\bin這樣F5調(diào)試時程序能找到dll。編譯完成后把dll拷到exe同級目錄即可分發(fā)。方式二把D:\vcpkg\installed\x64-windows\bin加入系統(tǒng)PATH。未推薦因為會影響所有程序的全局搜索順序容易造成版本污染。方式三推薦改用靜態(tài)鏈接tripletx64-windows-static徹底告別dll拷貝。代價是exe體積增大編譯時間延長。發(fā)布了綠色版首選。5.2 源碼編譯失敗大概率是三個原因vcpkg裝包時偶爾會編譯失敗尤其是一些老庫。我遇到的情形主要三類缺少構(gòu)建工具。有些庫需要Perl、NASM、Python等vcpkg不會自動安裝這些工具。解決方式是先裝上對應(yīng)工具并加入PATH然后重新執(zhí)行vcpkg install。網(wǎng)絡(luò)問題導(dǎo)致源碼下載失敗。vcpkg會緩存下載的源碼包到downloads目錄但如果中途下載中斷很可能留下?lián)p壞的半成品。遇到這類問題清掉downloads目錄下對應(yīng)文件重試。編譯器和庫版本不兼容。某些新版本VC工具集編譯老庫源碼時會報錯。一個簡單做法是安裝較新的vcpkg版本定期git pull更新vcpkg倉庫port文件通常也會跟著更新適配。5.3 升級依賴引發(fā)“連鎖重編”怎么應(yīng)對vcpkg upgrade會把所有有更新的庫全部重新編譯。在項目中期執(zhí)行一次升級等于是給所有依賴做了一次大版本更新很容易引發(fā)連鎖反應(yīng)某個庫的新版本ABI變了連帶其他庫也要重編。我的建議是不要在項目開發(fā)中期隨意執(zhí)行vcpkg全局升級。優(yōu)先用manifest模式鎖定版本需要升級某個庫時單獨(dú)升級那個庫并做好回歸測試。只有在新項目初始化時才建議執(zhí)行完整的upgrade。5.4 多項目共用vcpkg時的“隱性互相影響”如果你在同一臺機(jī)器上用同一個vcpkg管理多個項目經(jīng)典模式下所有項目共用一個大池子。A項目要的OpenSSL是3.0B項目要的可能是1.1。都裝在同一個installed目錄里會發(fā)生版本沖突。manifest模式天然規(guī)避這個問題每個項目用各自的vcpkg.jsonvcpkg會在項目目錄下生成獨(dú)立的vcpkg_installed目錄項目之間互不干擾。如果堅持用經(jīng)典模式就得靠這些方式隔離不同項目用不同triplet或者每個項目配一個獨(dú)立的vcpkg副本復(fù)制一份vcpkg目錄成本不高但確實占磁盤。5.5 換機(jī)器或換目錄后緩存失效vcpkg的路徑不能隨意搬動因為它內(nèi)部存儲了很多硬編碼的絕對路徑。如果你把vcpkg從D:\vcpkg挪到E:\vcpkg已編譯的庫不會自動失效但新構(gòu)建時可能找不到舊緩存導(dǎo)致重新編譯。遇到這種情的時間成本較高最穩(wěn)妥的做法是挪動vcpkg目錄后執(zhí)行vcpkg upgrade強(qiáng)制重編所有庫或者直接把installed目錄刪掉重新vcpkg install。硬編碼路徑的問題沒有更好的辦法只能在規(guī)劃階段就選好固定位置。6. 最后分享幾個vcpkg實戰(zhàn)效率技巧這些是我在實際項目里驗證過、能明顯提升使用體驗的細(xì)節(jié)寫出來供參考。6.1 搭配vcpkg的二進(jìn)制緩存團(tuán)隊構(gòu)建速度翻倍vcpkg支持二進(jìn)制緩存binary caching默認(rèn)情況下編譯好的庫會緩存在本地。團(tuán)隊協(xié)作時可以配置一個共享的二進(jìn)制緩存目錄比如公司內(nèi)網(wǎng)共享盤或S3兼容存儲A機(jī)器編譯過的庫B機(jī)器直接下載復(fù)用省去重復(fù)編譯時間。配置方式在CMake工具鏈文件里設(shè)置環(huán)境變量或用CMake參數(shù)cmake -B build -S . -DCMAKE_TOOLCHAIN_FILED:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_BINARY_SOURCESfiles,D:/vcpkg-cache,readwrite這樣D:/vcpkg-cache就成了共享緩存目錄。團(tuán)隊內(nèi)所有人指向同一個緩存目錄裝同一個庫時只有第一臺機(jī)器需要完整編譯其他成員全部從緩存復(fù)用。對于OpenSSL這類動輒編譯十分鐘的庫來說這個技巧能節(jié)省大量時間。6.2 vcpkg結(jié)合CI/CD矩陣構(gòu)建更省心我們在CI流水線里用vcpkg做了多環(huán)境編譯驗證比如同時驗證debug/release、x86/x64、動態(tài)/靜態(tài)鏈接。流水線配置的核心是每次構(gòu)建先更新vcpkg倉庫再根據(jù)項目的vcpkg.json安裝依賴然后開始編譯。因為vcpkg天然支持從源碼編譯所以每個CI節(jié)點(diǎn)第一次構(gòu)建都會慢一些但配上二進(jìn)制緩存后后續(xù)構(gòu)建速度有了明顯提升。更重要的是CI環(huán)境不會再出現(xiàn)“本地能編、服務(wù)器編不過”的尷尬因為依賴構(gòu)建流程完全一致。6.3 清理磁盤空間和臨時文件vcpkg用久了會積累大量源碼包和編譯中間文件。vcpkg目錄里的downloads和buildtrees會比較大。定期清理vcpkg x-clear-buildtrees清空buildtrees后已安裝的庫能正常使用但新增庫時可能無法復(fù)用舊的編譯中間產(chǎn)物需要重新編譯。磁盤空間緊張時值得一用空間充裕時建議保留。6.4 不要忘記定期更新vcpkg本體vcpkg的port文件更新頻率挺高新庫、新版本、構(gòu)建修復(fù)都會定期合入。我一般每月固定執(zhí)行一次git pull和vcpkg upgrade專門挑一個空閑時段處理可能出現(xiàn)的連鎖編譯。平時開發(fā)過程中只要項目不用到的庫不影響不用天天更新。歸根結(jié)底vcpkg把我在Windows C項目里最耗時、最無聊、最易錯的那部分工作——依賴的獲取、編譯、鏈接、分發(fā)——壓縮成了幾行命令和一個清單文件。如果你的項目還在純手工管理依賴或者正在為某次DLL問題頭疼我建議你花半小時給它一個機(jī)會。第一次從源碼編譯確實會慢一些但之后每一次依賴配置你都會覺得當(dāng)初這筆投入是值得的。