Nejčastější dotazy
Pomocí nástroje vcpkg můžete spravovat závislosti dvěma způsoby:
- Režim manifestu umožňuje deklarovat přímé závislosti, omezení verzí a používané registry v souboru s názvem
vcpkg.json
. Tento soubor by měl být součástí úložiště kódu a můžete ho vrátit se změnami do systému správy zdrojového kódu. Závislosti se instalují do podsložky s názvemvcpkg_installed
. Každý projekt kódu tak může mít svou vlastní sadu závislostí; nic není nainstalováno v celém systému. Vcpkg můžete spustit v režimu manifestu spuštěnímvcpkg install
(bez dalších argumentů) nebo použitím automatické integrace s projekty MSBuild a CMake. Ve většině případů doporučujeme používat manifesty pro vaše projekty v klasickém režimu, protože máte lepší kontrolu nad závislostmi. Další podrobnosti najdete v článku o režimu manifestu. - Klasický režim je tradičnější způsob správy závislostí, který zahrnuje spouštění příkazů vcpkg, které určují jednotlivé přímé závislosti pro instalaci, úpravu nebo odebrání. Závislosti jsou uloženy v instalačním adresáři vcpkg, takže více náročných projektů může odkazovat na stejnou sadu závislostí. Další podrobnosti najdete v našem článku o klasickém režimu.
Ano. Začněte tím, že si přečtete naše pokyny pro příspěvky. Podívejte se také na našeho průvodce údržbou, který obsahuje další podrobnosti. Máme také kurz pro přidání portu do vcpkg , který vám pomůže začít.
Pokud chcete přispívat, ale nemáte na paměti konkrétní knihovnu, podívejte se na seznam nových požadavků na porty.
Může vcpkg vytvářet předem připravené binární balíčky? Jaký je binární formát používaný nástrojem vcpkg?
Ano. Pokud chcete vytvořit binární soubory pro export do jiných prostředí, podívejte se na export
příkaz .
Pokud je vaším cílem zachovat binární soubory vytvořené operacemi vcpkg install
pro pozdější opětovné použití, podívejte se na funkci binární mezipaměti.
Pokud ke správě závislostí používáte manifest (vcpkg.json soubor), musíte tento soubor aktualizovat. Podrobnosti najdete v referenční dokumentaci ke správě verzí.
Pokud používáte vcpkg v klasickém režimu (spouštění příkazů pro správu balíčků, žádný soubor manifestu), prohlédněte si dokumentaci k příkazům.vcpkg update
Tento příkaz zobrazí seznam všech balíčků, které nejsou synchronizované s vašimi aktuálními soubory portů. Pak budete muset spustit vcpkg upgrade
příkaz , abyste potvrdili změny.
Seznam knihoven se vypíše z ports\
adresáře. Podle návrhu můžete přidávat a odebírat knihovny z tohoto adresáře, jak se vám to hodí pro sebe nebo vaši společnost – podívejte se na příklady balení souborů ZIP a úložišť GitHub.
Doporučujeme klonování přímo z GitHubu a použití git pull
k aktualizaci seznamu souborů portů.
Ano. Podle našeho příkladu balení vytvořte vlastní port a podívejte se do dokumentace k překryvým portům a registrům , kde se dozvíte, jak spravovat privátní porty.
Můžete to dále provést publikováním privátních knihoven do registru. Přečtěte si článek o vytváření registrů. Registr je kolekce portů, podobně jako vcpkg, která obsahuje opensourcové knihovny.
Ano. Knihovna portfile.cmake
je v podstatě skript, který umístí hlavičky a binární soubory do správného uspořádání v ${CURRENT_PACKAGES_DIR}
souboru , takže pro načtení předem připravených binárních souborů můžete napsat soubor portu, který přímo stáhne a uspořádá soubory.
Pokud chcete vidět příklad, podívejte se ports\opengl\portfile.cmake
, který jednoduše kopíruje soubory ze sady Windows SDK.
Naše integrované trojité trojité testy kontinuální integrace jsou:
- Windows Desktop (x86, x64, x64 static, arm64)
- Univerzální platforma Windows (x64 a arm64)
- Mac OS X (x64-static)
- Linux (x64-static)
- Android (x64, arm64, arm-neon)
Tyto cíle se testují důkladněji kvůli kompatibilitě s jednotlivými verzemi vcpkg. Máme však mnohem větší počet komunitních tripletů dostupných s více platformami a architekturami, včetně pro iOS, MinGW, WebAssembly, freeBSD a openBSD.
V závislosti na vašich potřebách můžete také definovat vlastní trojité sady. vcpkg je velmi přizpůsobitelný.
Další vcpkg help triplet
podrobnosti najdete v aktuálním seznamu a projděte si naši dokumentaci k trojitým trojitým uzlům.
Ano. Nepřetržitě testujeme na OS X a Ubuntu 22.04, ale víme, že uživatelé byli úspěšní s Archem, Fedora a FreeBSD. Pokud máte potíže s vaší oblíbenou distribucí Linuxu, dejte nám vědět o problému a rádi vám pomůžeme!
Spusťte git pull
, abyste získali nejnovější zdroje, a pak spusťte bootstrap-vcpkg.bat
(Windows) nebo ./bootstrap-vcpkg.sh
Unix a aktualizujte vcpkg. Nebo pokud používáte kopii vcpkg, která se dodává se sadou Visual Studio, jednoduše aktualizujte verzi sady Visual Studio z Instalační program pro Visual Studio.
Doporučujeme použít soubory manifestu ke správě závislostí pro jednotlivé projekty, což funguje i v případě, že je na stejném počítači více projektů a umožňuje snadnou správu verzí balíčků a knihoven registrů pocházejících.
Pokud ale místo toho používáte klasický režim, můžete mít v rámci jedné instance vcpkg (např. jednu sadu installed\
, packages\
ports\
atd.), můžete mít nainstalovanou jenom jednu verzi knihovny (jinak by hlavičky vzájemně kolidovaly!). Pro ty, kteří mají zkušenosti se správci balíčků pro celý systém, balíčky vcpkg odpovídají X-dev
těmto balíčkům nebo X-devel
balíčkům. V tomto případě doporučujeme použít různé verze knihovny pro různé projekty, doporučujeme vytvořit samostatné instance vcpkg a používat mechanismy integrace jednotlivých projektů. Verze každé knihovny jsou určeny soubory v ports\
, takže jsou snadno manipulovány pomocí standardních git
příkazů. Díky tomu je velmi snadné vrátit celou sadu knihoven do konzistentní sady starších verzí, které vzájemně fungují. Pokud potřebujete poté připnout konkrétní knihovnu dopředu, je to stejně snadné jako rezervace odpovídající verze ports\<package>\
. Pokud je vaše aplikace velmi citlivá na verze knihoven, doporučujeme zkontrolovat konkrétní sadu souborů portů, které potřebujete, do správy zdrojového kódu spolu se zdroji projektu a pomocí --vcpkg-root
možnosti přesměrovat pracovní adresář vcpkg.exe
.
Všechny informace týkající se ochrany osobních údajů najdete v dokumentu Ochrana osobních údajů.
Ano. Pokud již máte soubor CMake toolchain, budete muset na konec vašeho souboru toolchain zahrnout náš soubor toolchain. To by mělo být stejně jednoduché jako direktiva include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake)
. Případně můžete obsah našeho scripts\buildsystems\vcpkg.cmake
souboru zkopírovat na konec existujícího souboru toolchain.
Ano. V aktuální verzi ještě neexistuje standardizovaný globální způsob, jak je změnit, ale můžete upravit jednotlivé soubory portů a upravit přesný proces sestavení, ale chcete.
Uložením změn do souboru portu (a jejich vrácením se změnami) získáte stejné výsledky, i když v budoucnu znovu sestavujete a zapomněli jste, jaká přesná nastavení jste použili.
Ano. I když vcpkg při vytváření knihovny vytvoří pouze standardní konfigurace Release a Debug, můžete kromě standardních konfigurací projektu získat podporu integrace pro vlastní konfigurace vašich projektů.
Za prvé, vcpkg automaticky předpokládá všechny vlastní konfigurace začínající na "Release" (resp. "Debug") jako konfigurace, která je kompatibilní se standardní konfigurací Release (resp. Debug) a bude fungovat odpovídajícím způsobem.
V případě jiných konfigurací stačí přepsat makro MSBuild $(VcpkgConfiguration)
v souboru projektu (.vcxproj) a deklarovat kompatibilitu mezi konfigurací a cílovou standardní konfigurací. Vzhledem k sekvenční povaze nástroje MSBuild budete bohužel muset tato nastavení přidat mnohem výš ve vcxproj, aby byla deklarována před načtením integrace vcpkg. Doporučujeme, aby $(VcpkgConfiguration)
se makro přidalo do skupiny PropertyGroup "Globals".
Podporu konfigurace MyRelease můžete například přidat přidáním do souboru projektu:
<PropertyGroup Label="Globals">
...
<VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>
Samozřejmě se tím vytvoří pouze přijatelné binární soubory, pokud je vaše vlastní konfigurace kompatibilní s cílovou konfigurací (např. obě by měly být propojeny se stejnou knihovnou modulu runtime).
Ano. Balíček NuGet vhodný pro použití jednotlivých projektů lze vygenerovat buď vcpkg integrate project
příkazem (zjednodušené propojení), nebo vcpkg export --nuget
příkazem (shrinkwrapped).
Mechanismus nižší úrovně, který dosáhne stejného jako vcpkg integrate project
balíček NuGet, je prostřednictvím <vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets
souboru. Stačí ho naimportovat do souboru .vcxproj a nahradit <vcpkg_root>
cestou, do které jste nainstalovali vcpkg:
<Import Project="<vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets" />
Pokud vás zajímají jenom nainstalované balíčky, je bezpečné odstranit následující adresáře v kořenové složce vcpkg:
packages
,buildtrees
,- a
downloads
Příznak v vcpkg install
příkazu můžete použít --clean-after-build
k automatickému odstranění dočasných souborů po dokončení sestavení vcpkg.
Vcpkg také používá jiná dočasná umístění externí do kořenové složky vcpkg. Integrační soubory sady Visual Studio, výchozí binární mezipaměť a mezipaměť registrů; jsou všechny umístěny v následující cestě v závislosti na vašem operačním systému:
Ve Windows:
%LocalAppData%/vcpkg
V Linuxu nebo macOS:
$XDG_CACHE_HOME/vcpkg
~/.cache/vcpkg
(pouze pokudXDG_CACHE_HOME
není definován)
Pokud jste nakonfigurovali místní binární mezipaměť nebo mezipaměť prostředků, můžete je podle potřeby pravidelně vyčistit.
Vcpkg používá CMake interně jako skriptovací jazyk sestavení. Důvodem je to, že CMake je už velmi běžný systém sestavení pro opensourcové knihovny multiplatformních opensourcových knihoven a obecně se stává velmi populárním pro projekty C++. Je snadné získat v systému Windows, nevyžaduje instalaci v celém systému a čitelné pro neznámé uživatele.
Doporučujeme vytvářet knihovny jednou s upřednostňovanými konfiguracemi sestavení a pomocí funkce binárního ukládání do mezipaměti znovu používat binární soubory, aniž byste museli znovu sestavovat pokaždé. To je užitečné při práci na týmovém projektu nebo při místním vytváření prostředí kontinuální integrace napříč několika počítači, kontejnery, virtuálními počítači atd.
Podporujeme Visual Studio 2015 Update 3 a novější.
Povolení integrace pro celou uživatele (vcpkg integrate install
) změní výchozí nastavení pro některé vlastnosti projektu. Konkrétně jsou adresáře C/C++/General/Additional Include Adresáře a Linker/General/Additional Library Directories obvykle prázdné bez integrace pro celou uživatele. Při integraci prázdná hodnota znamená, že rozšířená výchozí hodnota zadaná nástrojem vcpkg je přepsána a hlavičky a knihovny se nenajdou. Chcete-li obnovit výchozí hodnotu, nastavte vlastnosti, které mají dědit z nadřazeného objektu.
NuGet je správce balíčků pro knihovny .NET se silnou závislostí na MSBuildu. Nesplňuje konkrétní potřeby nativních zákazníků jazyka C++ alespoň třemi způsoby.
Kompilační příchutě. Díky tolika možným kombinacím možností kompilace je úloha poskytnutí skutečně kompletní sady možností vnitřně nemožné. Kromě toho se velikost stahování pro přiměřeně úplné binární balíčky stává obrovskou. To znamená, že je nutné rozdělit výsledky do několika balíčků, ale vyhledávání je velmi obtížné.
Binární vs. zdroj. Velmi úzce svázaný s prvním bodem je NuGet navržen od základů tak, aby poskytoval relativně malé předem připravené binární soubory. Vzhledem k povaze nativního kódu musí mít vývojáři přístup ke zdrojovému kódu, aby zajistili kompatibilitu, výkon, integritu a ladění ABI.
Per-dll vs. Per-application. NuGet je vysoce orientovaný na projekt. To funguje dobře ve spravovaných jazycích s přirozeně stabilními identifikátory ABI, protože základní knihovny se můžou dál vyvíjet, aniž by se tyto vyšší úrovně rozbily. V nativních jazycích, kde je ABI mnohem křehkější, je jedinou robustní strategií explicitně sestavit každou knihovnu proti přesným závislostem, které budou zahrnuty do konečné aplikace. To je obtížné zajistit v NuGetu a vede k vysoce odpojené a nezávislé verzi ekosystému.
Conan.io je veřejně federovaný, multiplatformní, multiplatformní správce balíčků C++, který je napsaný v Pythonu. Mezi naše hlavní rozdíly patří:
Veřejná federace vs. privátní federace Conan spoléhá na jednotlivce, kteří publikují nezávislé kopie každého balíčku. Věříme, že tento přístup podporuje velký počet balíčků, které jsou všechny rozbité různými způsoby. Věříme, že je plýtvání časem uživatele vybrat si seznam 20+ veřejných balíčků pro Boost 1,56, aby bylo možné určit hrst, která bude fungovat pro jejich konkrétní situaci. Naproti tomu jsme přesvědčeni, že existuje jedna, společně udržovaná verze, která funguje pro velkou většinu případů a umožňuje uživatelům volně hackovat své soukromé verze. Věříme, že to bude mít za následek sadu vysoce kvalitních balíčků, které jsou silně testovány mezi sebou a tvoří fantastický základ pro všechny soukromé úpravy, které potřebujete.
Per-dll vs. Per-application. Pokud jsou závislosti nezávislé na úrovni knihovny, vybízí každé prostředí sestavení, aby bylo zcela jedinečné, nemohlo využívat výhod nebo přispívat k solidnímu a dobře otestovanému ekosystému. Naproti tomu díky společné správě verzí všech knihoven jako platformy (podobně jako správce systémových balíčků) doufáme, že spojíme testování a úsilí o velmi běžné sady verzí knihoven, abychom maximalizovali kvalitu a stabilitu ekosystému. To také zcela navrhne schopnost knihovny požádat o verze, které jsou v konfliktu s volbami aplikace (chci openssl Z a zvýšit X, ale X pouze deklarace identity pro práci s openssl Y).
Multiplatformní vs. jednoplatformní. Zatímco hostování na mnoha platformách je vynikající severní hvězdou, věříme, že úroveň integrace a stability systému, kterou poskytuje apt-get, yum a homebrew, stojí za to si vyměňovat
apt-get install libboost-all-dev
s automatizovanýmibrew install boost
skripty. Rozhodli jsme se systém co nejsnadněji integrovat do světa s těmito velmi úspěšnými systémovými manažery – jeden další řádek provcpkg install boost
– místo toho, abychom je nahradili tam, kde jsou již tak úspěšní a dobře milí.C++/CMake vs python. I když je Python vynikající jazyk, který mnoho z nich miluje, věříme, že transparentnost a znalost jsou nejdůležitějšími faktory při výběru nástroje, který je pro váš pracovní postup důležitý jako správce balíčků. Proto jsme se rozhodli, že jazyky implementace budou co nejsnáze přijímané: C++ by se měl používat ve správci balíčků C++ pro programátory jazyka C++. Abyste porozuměli správci balíčků, neměli byste se vyžadovat, abyste se naučili jiný programovací jazyk.
Chocolatey je vynikající systém pro správu aplikací. V současné době ale není určen k získání redistribuovatelných vývojářských prostředků a pomáhá vám s laděním. Ve srovnání s vcpkg je navržen tak, aby vám získal knihovny, které potřebujete k sestavení vaší aplikace a které vám pomohou dodávat prostřednictvím libovolné platformy, kterou chcete (včetně Chocolatey!).
Zpětná vazba k produktu vcpkg
vcpkg je open source projekt. Vyberte odkaz pro poskytnutí zpětné vazby: