常見問題集
使用 vcpkg 管理相依性的方式有兩種:
- 指令清單模式 可讓您在稱為
vcpkg.json
的檔案中宣告直接相依性、版本條件約束和使用的登錄。 此檔案應該包含在您的程式代碼存放庫中,而且可以簽入原始檔控制系統。 相依性會安裝在名為vcpkg_installed
的子資料夾中。 如此一來,每個程式代碼專案可以有自己的相依性集合;未安裝全系統。 您可以在指令清單模式中執行 vcpkg,方法是執行vcpkg install
(不含其他自變數),或利用與 MSBuild 和 CMake 專案的自動整合。 在大部分情況下,建議您在傳統模式上針對專案使用指令清單,因為您可以更妥善地控制相依性。 如需詳細資訊,請參閱我們的 指令清單模式一文 。 - 傳統模式 是管理相依性的較傳統方式,其牽涉到執行 vcpkg 命令,以指定要安裝、修改或移除的每個直接相依性。 相依性會儲存在 vcpkg 安裝目錄中,因此多個取用專案可以參考同一組相依性。 如需詳細資訊,請參閱我們的 傳統模式文章 。
可以! 首先閱讀我們的 貢獻指導方針。 另請參閱我們的 維護者指南 ,以取得更多詳細數據。 我們也提供將 埠新增至 vcpkg 的教學課程,以協助您開始使用。
如果您想要參與,但沒有特定的連結庫,請查看新的埠要求清單。
可以! export
如果您想要產生二進位檔以匯出至其他環境,請參閱 命令。
或者,如果您的目標是保留作業所產生的 vcpkg install
二進位檔以供稍後重複使用,請參閱 二進位快取功能
如果您使用指令清單(vcpkg.json檔案)來管理相依性,則必須更新該檔案。 如需詳細資訊, 請參閱版本控制參考檔 。
如果您在傳統模式中使用 vcpkg(執行命令來管理套件,沒有指令清單檔案),請參閱 vcpkg update
命令檔。 此命令會列出所有與目前 portfiles 同步的套件。 接著,您必須執行 vcpkg upgrade
命令 來確認變更。
從目錄列舉 ports\
連結庫清單。 根據設計,您可以在您自己或公司看到時,從此目錄中新增和移除連結庫,請參閱我們封裝 zipfiles 和 GitHub 存放庫的範例。
建議您直接從 GitHub 複製 ,並使用 git pull
來更新 portfiles 清單。
是。 請遵循 我們的封裝範例 來建立您自己的埠,並查看 重迭埠 和 登錄 檔,以瞭解如何管理您的私人埠。
您可以將私人連結庫發佈至登錄,以進一步採取此動作。 請參閱建立登錄一文。 登錄是埠的集合,類似於 vcpkg 提供的埠集合,其中包含 開放原始碼 連結庫。
是。 portfile.cmake
連結庫的 基本上是腳本,會將標頭和二進位檔放入 中的${CURRENT_PACKAGES_DIR}
正確排列,因此若要提取預先建置的二進位檔,您可以撰寫直接下載及排列檔案的 portfile。
若要查看此範例,請查看 ports\opengl\portfile.cmake
哪一個只是從 Windows SDK 複製檔案。
我們內建且持續整合測試的三胞胎包括:
- Windows Desktop (x86、x64、x64-static、arm64)
- 通用 Windows 平台 (x64 和 arm64)
- Mac OS X (x64-static)
- Linux (x64-static)
- Android (x64、arm64、arm-neon)
這些目標會更嚴格地測試,以與每個 vcpkg 版本相容。 不過,我們有更多的社群三元組可供更多平台和架構使用,包括iOS、MinGW、WebAssembly、freeBSD和 openBSD。
您也可以根據需求定義自己的三胞胎。 vcpkg 非常可自定義。
如需詳細資訊,請參閱 vcpkg help triplet
目前的清單,並檢閱我們的 三胞胎檔 。
可以! 我們持續測試 OS X 和 Ubuntu 22.04,不過我們知道使用者已成功使用 Arch、Fedora 和 FreeBSD。 如果您在慣用的Linux發行版時遇到問題,請在問題中告訴我們,我們很高興能提供説明!
執行 git pull
以取得最新的來源,然後執行 bootstrap-vcpkg.bat
(Windows) 或 ./bootstrap-vcpkg.sh
[Unix] 以更新 vcpkg。 或者,如果您使用隨附於 Visual Studio 的 vcpkg 複本,只要從 Visual Studio 安裝程式 更新您的 Visual Studio 版本即可。
我們建議使用 指令清單檔案 來管理個別專案的相依性,即使多個項目位於同一部計算機上,也可讓您輕鬆地管理套件版本和來自哪些登錄連結庫。
不過,如果您改為使用傳統模式,請在 vcpkg 的單一實例內(例如一組 installed\
、 packages\
ports\
等等),您只能安裝一個連結庫版本(否則標頭會彼此衝突!)。 對於具有全系統套件管理員經驗的人,vcpkg 中的套件會對應至 X-dev
或 X-devel
套件。 在此情況下,若要針對不同的專案使用不同的連結庫版本,建議您使用不同的 vcpkg 實例,並使用個別專案整合機制。 每個連結庫的版本是由 中的 ports\
檔案所指定,因此它們很容易使用標準 git
命令來操作。 這可讓您輕鬆地將整組連結庫復原到一組一致的較舊版本,這些版本全都彼此搭配使用。 如果您需要將特定連結庫轉寄,這和簽出適當的 版本 ports\<package>\
一樣簡單。 如果您的應用程式對連結庫版本非常敏感,建議您簽入原始檔控制以及專案來源所需的特定通訊埠檔集,並使用 --vcpkg-root
選項來重新導向 的工作目錄 vcpkg.exe
。
是。 如果您已經有 CMake 工具鏈檔案,您必須在工具鏈檔案的結尾包含我們的工具鏈檔案。 這應該和指示詞一 include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake)
樣簡單。 或者,您可以將我們 scripts\buildsystems\vcpkg.cmake
的內容複製到現有工具鏈檔案的結尾。
是。 在目前的版本中,還沒有標準化的全域方式可以變更它們,不過您可以編輯個別的 portfiles 並調整您想要的確切建置程式。
藉由將變更儲存到 portfile(並簽入),即使您未來從頭重建並忘記您使用的確切設定,您仍會收到相同的結果。
是。 雖然 vcpkg 只會在建置連結庫時產生標準「發行」和「偵錯」組態,但除了專案的標準組態之外,您還可以取得專案的自定義組態整合支援。
首先,vcpkg 會自動假設任何從 “Release” (resp. “Debug” 開始的自定義組態, 作為與標準 “Release” (resp. “Debug”) 設定兼容的設定,並據此採取行動。
針對其他組態,您只需要覆寫項目檔 (.vcxproj) 中的 MSBuild $(VcpkgConfiguration)
巨集,以宣告組態與目標標準組態之間的相容性。 不幸的是,由於 MSBuild 的循序本質,您必須在 vcxproj 中新增這些設定,以便在載入 vcpkg 整合之前宣告。 建議將 $(VcpkgConfiguration)
巨集新增至 「Globals」 PropertyGroup。
例如,您可以在項目檔中新增 「MyRelease」 設定的支援:
<PropertyGroup Label="Globals">
...
<VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>
當然,如果您的自定義組態與目標組態相容,這隻會產生可行的二進位檔(例如,它們應該同時連結至相同的運行時間連結庫)。
是。 您可以透過 vcpkg integrate project
命令 (輕量連結) 或 vcpkg export --nuget
命令 (shrinkwrapped) 來產生適用於每個專案使用的 NuGet 套件。
要達到與 vcpkg integrate project
NuGet 套件相同的較低層級機制是透過 <vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets
檔案。 您只需要將它匯入.vcxproj檔案,並將 取代 <vcpkg_root>
為您安裝 vcpkg 的路徑:
<Import Project="<vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets" />
如果您只關心已安裝的套件,可以安全地刪除 vcpkg 根資料夾內的下列目錄:
packages
,buildtrees
,- 和
downloads
您可以在命令中使用 vcpkg install
--clean-after-build
旗標,讓 vcpkg 在建置完成後自動刪除暫存盤。
vcpkg也會使用 vcpkg 根資料夾外部的其他暫存位置。 Visual Studio 整合檔案、預設二進位快取和登錄快取;全都位於下列路徑中,視您的操作系統而定:
在 Windows 上:
%LocalAppData%/vcpkg
在 Linux/macOS 上:
$XDG_CACHE_HOME/vcpkg
~/.cache/vcpkg
( 只有在未定義時才XDG_CACHE_HOME
)
如果您已設定本機二進制或資產快取,您可能想要視需要定期清除這些快取。
vcpkg 會在內部使用 CMake 作為組建腳本語言。 這是因為 CMake 已經是跨平臺 開放原始碼 連結庫的極通用建置系統,而且對於一般C++專案而言非常受歡迎。 很容易在 Windows 上取得、不需要全系統安裝,而且對不熟悉的使用者而言是可行的。
建議您使用慣用的組建組態建置連結庫一次,並使用 二進位快 取功能重複使用二進位檔,而不需要每次重新建置。 當您在本機和跨多部機器、容器、虛擬機等連續整合環境中建置時,這非常有用。
我們支援 Visual Studio 2015 Update 3 和更新版本。
啟用全使用者整合 (vcpkg integrate install
) 會變更某些專案屬性的預設值。 特別是「C/C++/一般/其他 Include 目錄」和「連結器/一般/其他連結庫目錄」通常為空白 ,而不需要 全使用者整合。 使用 整合時,空白值表示會覆寫 vcpkg 所提供的增強型預設值,而且找不到標頭/連結庫。 若要恢復預設值,請將屬性設定為繼承自父系。
NuGet 是 .NET 連結庫的套件管理員,具有 MSBuild 的強式相依性。 這至少三種方式不符合 Native C++ 客戶的特定需求。
編譯類別。 由於編譯選項的許多可能組合,提供一組真正完整的選項的工作本質上是不可能的。 此外,合理完整二進位套件的下載大小會變得非常龐大。 這可讓您將結果分割成多個套件,但搜尋會變得非常困難。
二進位與來源。 NuGet 非常緊密地系結到第一個點,從頭開始設計,以提供相對較小的預先建置二進位檔。 由於原生程式代碼的性質,開發人員必須能夠存取原始程式碼,以確保ABI相容性、效能、完整性和可偵錯性。
Per-dll 與 Per-application。 NuGet 以專案為中心。 這在具有自然穩定 ABIS 的 Managed 語言中運作良好,因為基底連結庫可以繼續發展,而不會中斷這些較高版本。 不過,在 ABI 更為脆弱的原生語言中,唯一健全的策略是針對最終應用程式中包含的確切相依性明確建置每個連結庫。 在 NuGet 中,這很難確保會導致高度中斷連線且獨立版本的生態系統。
Conan.io 是以 python 撰寫的公開同盟、以專案為中心的跨平臺C++套件管理員。 我們的主要差異如下:
公用同盟與私人同盟。 Conan 依賴個別發行每個套件的獨立複本。 我們相信這種方法鼓勵大量套件以不同方式中斷。 我們認為,浪費使用者的時間,挑選 20 個以上公用套件的 Boost 1.56 清單,以判斷少數將適用於他們特定情況的時間。 相反地,我們認為應該有一個單一、共同維護的版本,適用於絕大多數案例,並允許使用者自由破解其私人版本。 我們相信,這將會產生一組高品質的套件,這些套件彼此經過大量測試,並形成您所需的任何私人修改的絕佳基礎。
Per-dll 與 Per-application。 當相依性在連結庫層級上獨立建立版本時,它會鼓勵每個建置環境完全是唯一的,無法利用或參與穩固且經過良好測試的生態系統。 相反地,藉由將所有連結庫版本設定為平臺(類似於系統套件管理員),我們希望將非常常見的連結庫版本集合進行測試和努力,以最大化生態系統的質量和穩定性。 這也完全設計了連結庫要求與應用程式選擇衝突的版本的能力(我想要 openssl Z 並提升 X,但 X 只聲稱使用 openssl Y)。
跨平臺與單一平臺。 雖然裝載在許多平臺上是優秀的北星,但我們相信apt-get、yum和homebrew所提供的系統整合和穩定性水準非常值得在自動化腳本中交換
apt-get install libboost-all-dev
brew install boost
。 我們選擇盡可能輕鬆地將系統整合到一個世界與這些非常成功的系統管理員 -- 一行vcpkg install boost
-- 而不是試圖取代他們已經如此成功和深受愛戴的地方。C++/CMake 與 python。 雖然 Python 是許多人喜愛的優秀語言,但我們相信透明度和熟悉度是選擇工具作為套件管理員時最重要的因素。 因此,我們選擇盡可能接受實作語言:C++應該用於C++程式設計人員的C++套件管理員中。 您不應該需要學習另一種程式設計語言,只要瞭解套件管理員即可。
Chocolatey 是管理應用程式的絕佳系統。 不過,它目前並非設計來取得可轉散發的開發人員資產,並協助您進行偵錯。 相比之下,vcpkg 的設計目的是要讓您了解建置應用程式所需的連結庫,並協助您傳遞您想要的任何平臺(包括 Chocolatey!)。