Domande frequenti
Esistono due modi per gestire le dipendenze con vcpkg:
- La modalità manifesto consente di dichiarare le dipendenze dirette, i vincoli di versione e i registri usati in un file denominato
vcpkg.json
. Questo file deve essere incluso nel repository di codice e può essere archiviato nel sistema di controllo del codice sorgente. Le dipendenze vengono installate in una sottocartella denominatavcpkg_installed
. In questo modo, ogni progetto di codice può avere un proprio set di dipendenze; nulla è installato a livello di sistema. È possibile eseguire vcpkg in modalità manifesto eseguendovcpkg install
(senza altri argomenti) o sfruttando l'integrazione automatica con i progetti MSBuild e CMake. È consigliabile usare manifesti per i progetti in modalità classica nella maggior parte dei casi, in quanto è possibile controllare meglio le dipendenze. Per altri dettagli, vedere l'articolo Modalità manifesto. - La modalità classica è il modo più tradizionale per gestire le dipendenze, che prevede l'esecuzione di comandi vcpkg che specificano ogni dipendenza diretta da installare, modificare o rimuovere. Le dipendenze vengono archiviate all'interno della directory di installazione di vcpkg, quindi più progetti che utilizzano possono fare riferimento allo stesso set di dipendenze. Per altri dettagli, vedere l'articolo sulla modalità classica.
Sì. Per iniziare, leggere le linee guida per i contributi. Vedere anche la guida del manutenitore che fornisce maggiori dettagli. È disponibile anche un'esercitazione per l'aggiunta di una porta a vcpkg per iniziare.
Se si vuole contribuire ma non si ha una particolare libreria in mente, esaminare l'elenco delle nuove richieste di porta.
Sì. Vedere il export
comando se si desidera produrre file binari per l'esportazione in altri ambienti.
In alternativa, se l'obiettivo è mantenere i file binari prodotti dalle vcpkg install
operazioni per un uso successivo, vedere la funzionalità di memorizzazione nella cache binaria
Se si usa un manifesto (file vcpkg.json) per gestire le dipendenze, è necessario aggiornare il file. Per informazioni dettagliate, vedere la documentazione di riferimento sul controllo delle versioni.
Se si usa vcpkg in modalità classica (esecuzione di comandi per gestire i pacchetti, nessun file manifesto), vedere la documentazione del vcpkg update
comando. Questo comando elenca tutti i pacchetti non sincronizzati con i file di porta correnti. Sarà quindi necessario eseguire il vcpkg upgrade
comando per confermare le modifiche.
L'elenco delle librerie viene enumerato dalla ports\
directory . Per impostazione predefinita, è possibile aggiungere e rimuovere librerie da questa directory in base alle proprie esigenze o all'azienda. Vedere gli esempi relativi alla creazione di file zipfile e repository GitHub.
È consigliabile clonare direttamente da GitHub e usare git pull
per aggiornare l'elenco dei file di porta.
Sì. Seguire l'esempio di creazione di pacchetti per creare una porta personalizzata e vedere la documentazione relativa alle porte e ai registri di sovrimpressione per informazioni su come gestire le porte private.
È possibile continuare pubblicando le librerie private in un Registro di sistema. Vedere l'articolo creazione di registri. Un registro è una raccolta di porte, simile a quella fornita con vcpkg che contiene librerie open source.
Sì. Per portfile.cmake
una libreria è fondamentalmente uno script che inserisce le intestazioni e i file binari nella disposizione corretta in ${CURRENT_PACKAGES_DIR}
, in modo da eseguire il pull di file binari predefiniti è possibile scrivere un file di porta che scarica e dispone direttamente i file.
Per un esempio di questo esempio, esaminare ports\opengl\portfile.cmake
che copia semplicemente i file da Windows SDK.
I tripletti predefiniti di integrazione continua testati sono i seguenti:
- Windows Desktop (x86, x64, x64-static, arm64)
- piattaforma UWP (Universal Windows Platform) (x64 e arm64)
- Mac OS X (x64-static)
- Linux (x64-static)
- Android (x64, arm64, arm-neon)
Queste destinazioni vengono testate in modo più rigoroso per garantire la compatibilità con ogni versione vcpkg. Tuttavia, è disponibile un numero molto maggiore di triplette della community con più piattaforme e architetture, tra cui per iOS, MinGW, WebAssembly, freeBSD e openBSD.
È anche possibile definire triplette personalizzate in base alle proprie esigenze. vcpkg è molto personalizzabile.
Per vcpkg help triplet
altri dettagli, vedere l'elenco corrente ed esaminare la documentazione relativa ai tripli.
Sì. Testiamo continuamente su OS X e Ubuntu 22.04, ma sappiamo che gli utenti hanno avuto successo con Arch, Fedora e FreeBSD. In caso di problemi con la distribuzione di Linux preferita, segnalarlo in un problema e saremmo lieti di aiutarti!
Eseguire git pull
per ottenere le origini più recenti, quindi eseguire bootstrap-vcpkg.bat
(Windows) o ./bootstrap-vcpkg.sh
(Unix) per aggiornare vcpkg. In alternativa, se si usa una copia di vcpkg fornita con Visual Studio, è sufficiente aggiornare la versione di Visual Studio dal Programma di installazione di Visual Studio.
È consigliabile usare i file manifesto per gestire le dipendenze per singoli progetti, che funziona anche se più progetti si trovano nello stesso computer e consentono di gestire facilmente le versioni dei pacchetti e da quali librerie di registri provengono.
Tuttavia, se si usa la modalità classica, all'interno di una singola istanza di vcpkg (ad esempio, un set di installed\
, packages\
ports\
e così via), è possibile avere una sola versione di una libreria installata (in caso contrario, le intestazioni verrebbero in conflitto tra loro!). Per coloro che hanno esperienza con gestioni pacchetti a livello di sistema, i pacchetti in vcpkg corrispondono ai X-dev
pacchetti o X-devel
. In questo caso, per usare versioni diverse di una libreria per progetti diversi, è consigliabile creare istanze separate di vcpkg e usare i meccanismi di integrazione per progetto. Le versioni di ogni libreria vengono specificate dai file in ports\
, in modo che vengano facilmente manipolate usando i comandi standard git
. In questo modo è molto semplice eseguire il rollback dell'intero set di librerie a un set coerente di versioni precedenti che funzionano tra loro. Se è necessario aggiungere una libreria specifica in avanti, è facile come controllare la versione appropriata di ports\<package>\
. Se l'applicazione è molto sensibile alle versioni delle librerie, è consigliabile controllare il set specifico di file di porta necessari nel controllo del codice sorgente insieme alle origini del progetto e usare l'opzione --vcpkg-root
per reindirizzare la directory di lavoro di vcpkg.exe
.
Per tutte le informazioni relative alla privacy, vedere il documento sulla privacy.
Sì. Se hai già un file toolchain CMake, dovrai includere il nostro file toolchain alla fine dei tuoi. Questo dovrebbe essere semplice come una include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake)
direttiva. In alternativa, è possibile copiare il contenuto di microsoft scripts\buildsystems\vcpkg.cmake
alla fine del file toolchain esistente.
Sì. Nella versione corrente non esiste ancora un modo globale standardizzato per modificarli, ma è possibile modificare singoli file di porta e modificare il processo di compilazione esatto, tuttavia si vuole.
Salvando le modifiche al file di porta (e archiviandole), si otterranno gli stessi risultati anche se si ricompila da zero in futuro e si dimenticano le impostazioni esatte usate.
Sì. Anche se vcpkg produrrà solo le configurazioni standard "Release" e "Debug" durante la compilazione di una libreria, è possibile ottenere il supporto di integrazione per le configurazioni personalizzate dei progetti, oltre alle configurazioni standard del progetto.
Prima di tutto, vcpkg presupporrà automaticamente qualsiasi configurazione personalizzata a partire da "Release" (resp. "Debug") come configurazione compatibile con la configurazione standard "Release" (resp. "Debug") e funzionerà di conseguenza.
Per altre configurazioni, è sufficiente eseguire l'override della macro MSBuild $(VcpkgConfiguration)
nel file di progetto (.vcxproj) per dichiarare la compatibilità tra la configurazione e la configurazione standard di destinazione. Sfortunatamente, a causa della natura sequenziale di MSBuild, è necessario aggiungere tali impostazioni molto più in alto in vcxproj in modo che venga dichiarata prima del caricamento dell'integrazione di vcpkg. È consigliabile aggiungere la $(VcpkgConfiguration)
macro al PropertyGroup "Globals".
Ad esempio, è possibile aggiungere il supporto per la configurazione "MyRelease" aggiungendo nel file di progetto:
<PropertyGroup Label="Globals">
...
<VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>
Naturalmente, questo produrrà solo file binari validi se la configurazione personalizzata è compatibile con la configurazione di destinazione (ad esempio, devono entrambi collegarsi alla stessa libreria di runtime).
Non è possibile usare l'integrazione a livello di utente. È possibile usare un'integrazione per progetto?
Sì. Un pacchetto NuGet adatto per l'uso per progetto può essere generato tramite il vcpkg integrate project
comando (collegamento leggero) o il vcpkg export --nuget
comando (shrinkwrapped).
Un meccanismo di livello inferiore per ottenere lo stesso risultato del vcpkg integrate project
pacchetto NuGet è tramite il <vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets
file . È sufficiente importarlo nel file .vcxproj, sostituendo <vcpkg_root>
con il percorso in cui è stato installato vcpkg:
<Import Project="<vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets" />
Se si è preoccupati solo dei pacchetti installati, è possibile eliminare le directory seguenti all'interno della cartella radice vcpkg:
packages
,buildtrees
,- e
downloads
È possibile usare il --clean-after-build
flag nel vcpkg install
comando per eliminare automaticamente i file temporanei dopo il completamento della compilazione.
vcpkg usa anche altri percorsi temporanei esterni alla cartella radice vcpkg. File di integrazione di Visual Studio, cache binaria predefinita e cache dei registri; si trovano tutti nel seguente percorso a seconda del sistema operativo:
In Windows:
%LocalAppData%/vcpkg
In Linux/macOS:
$XDG_CACHE_HOME/vcpkg
~/.cache/vcpkg
(solo seXDG_CACHE_HOME
non è definito)
Se sono state configurate cache binarie o asset locali, è consigliabile pulire periodicamente tali elementi in base alle esigenze.
vcpkg usa internamente CMake come linguaggio di scripting di compilazione. Questo perché CMake è già un sistema di compilazione estremamente comune per librerie open source multipiattaforma e sta diventando molto popolare per i progetti C++ in generale. È facile acquisire in Windows, non richiede l'installazione a livello di sistema e leggibile per gli utenti sconosciuti.
È consigliabile creare le librerie una sola volta con le configurazioni di compilazione preferite e usare la funzionalità di memorizzazione nella cache binaria per riutilizzare i file binari senza dover ripetere la compilazione ogni volta. Ciò è utile quando si lavora a un progetto team o quando si compilano sia localmente che in un ambiente di integrazione continua tra più computer, contenitori, macchine virtuali e così via.
Visual Studio 2015 Update 3 e versioni successive è supportato.
L'abilitazione dell'integrazione a livello di utente (vcpkg integrate install
) modifica l'impostazione predefinita per alcune proprietà del progetto. In particolare, "C/C++/General/Additional Include Directories" e "Linker/General/Additional Library Directories" sono in genere vuoti senza l'integrazione a livello di utente. Con l'integrazione, un valore vuoto indica che l'impostazione predefinita aumentata fornita da vcpkg viene sottoposta a override e le intestazioni/librerie non verranno trovate. Per ripristinare l'impostazione predefinita, impostare le proprietà da ereditare dall'elemento padre.
NuGet è una gestione pacchetti per le librerie .NET con una forte dipendenza da MSBuild. Non soddisfa le esigenze specifiche dei clienti C++ nativi in almeno tre modi.
Versioni di compilazione. Con così tante possibili combinazioni di opzioni di compilazione, l'attività di fornire un set di opzioni veramente completo è intrinsecamente impossibile. Inoltre, le dimensioni di download per pacchetti binari ragionevolmente completi diventano enormi. In questo modo è necessario suddividere i risultati in più pacchetti, ma la ricerca diventa molto difficile.
Binario e origine. Molto strettamente legato al primo punto, NuGet è progettato da zero per fornire file binari predefiniti relativamente piccoli. A causa della natura del codice nativo, gli sviluppatori devono avere accesso al codice sorgente per garantire la compatibilità ABI, le prestazioni, l'integrità e il debug.
Per dll e Per-application. NuGet è altamente incentrato sul progetto. Questo funziona bene in linguaggi gestiti con abIs naturalmente stabili, perché le librerie di base possono continuare a evolversi senza interrompere quelle più elevate. Tuttavia, nelle lingue native in cui l'ABI è molto più fragile, l'unica strategia affidabile consiste nel compilare in modo esplicito ogni libreria in base alle dipendenze esatte che verranno incluse nell'applicazione finale. Ciò è difficile da garantire in NuGet e porta a un ecosistema con controllo delle versioni altamente disconnesso e indipendente.
Conan.io è una gestione pacchetti C++ federata pubblicamente basata su progetti, multipiattaforma scritta in Python. Le differenze principali sono:
Federazione pubblica e federazione privata. Conan si basa su singoli utenti che pubblicano copie indipendenti di ogni pacchetto. Riteniamo che questo approccio incoraggia un numero elevato di pacchetti che sono tutti interrotti in modi diversi. Crediamo che sia uno spreco di tempo dell'utente per selezionare l'elenco di 20 pacchetti pubblici per Boost 1.56 per determinare la manciata che funzionerà per la loro particolare situazione. Al contrario, crediamo che ci dovrebbe essere una singola versione gestita in modo collaborativo che funziona per la maggior parte dei casi e consentire agli utenti di hackerare liberamente sulle loro versioni private. Crediamo che questo comporterà un set di pacchetti di alta qualità che sono pesantemente testati tra loro e formano una base fantastica per tutte le modifiche private necessarie.
Per dll e Per-application. Quando le dipendenze vengono sottoposte a controllo delle versioni indipendente a livello di libreria, incoraggia ogni ambiente di compilazione a essere un ambiente di compilazione completamente univoco, incapace di sfruttare o contribuire a un ecosistema solido e ben testato. Al contrario, con il controllo delle versioni di tutte le librerie come piattaforma (simile a una gestione pacchetti di sistema), speriamo di raggruppare i test e gli sforzi su set molto comuni di versioni di libreria per ottimizzare la qualità e la stabilità dell'ecosistema. In questo modo si progetta completamente la possibilità per una libreria di richiedere versioni in conflitto con le scelte dell'applicazione (voglio aprire z e aumentare X ma X solo attestazioni di lavorare con openssl Y).
Multipiattaforma e multipiattaforma. Sebbene sia ospitato su molte piattaforme è un'eccellente stella settentrionale, crediamo che il livello di integrazione e stabilità del sistema fornito da apt-get, yum e homebrew valga la pena di scambiare
apt-get install libboost-all-dev
conbrew install boost
negli script automatizzati. Abbiamo scelto di rendere il nostro sistema il più facile possibile per integrarsi in un mondo con questi manager di sistema di grande successo - una più linea pervcpkg install boost
- invece di tentare di sostituirli dove sono già così successo e ben amato.C++/CMake e Python. Anche se Python è un linguaggio eccellente amato da molti, crediamo che la trasparenza e la familiarità siano i fattori più importanti quando si sceglie uno strumento importante per il flusso di lavoro come gestione pacchetti. Di conseguenza, abbiamo scelto di rendere i linguaggi di implementazione il più universale possibile: C++ deve essere usato in una gestione pacchetti C++ per i programmatori C++. Non è necessario imparare un altro linguaggio di programmazione solo per comprendere la gestione pacchetti.
Chocolatey è un sistema eccellente per la gestione delle applicazioni. Tuttavia, non è attualmente progettato per acquisire asset di sviluppo ridistribuibili e facilitare il debug. vcpkg, in confronto, è progettato per ottenere le librerie necessarie per compilare l'applicazione e facilitare la distribuzione tramite qualsiasi piattaforma desiderata (incluso Chocolatey!).
Feedback su vcpkg
vcpkg è un progetto di open source. Selezionare un collegamento per fornire feedback: