Condividi tramite


Convenzioni di layout della directory di installazione

Questo articolo descrive le convenzioni di layout usate da vcpkg per la directory di installazione. La directory di installazione contiene i file installati da ogni pacchetto. Gli autori delle porte devono assicurarsi che i pacchetti seguano le convenzioni descritte in questo articolo.

In modalità classica, la directory di installazione si trova in $VCPKG_ROOT/installed (dove $VCPKG_ROOT è il percorso di installazione di vcpkg). In modalità manifesto ogni file manifesto ha una directory corrispondente vcpkg_installed . Il percorso della directory di installazione può essere modificato con l'opzione --x-install-root . Indipendentemente dalla modalità operativa, il layout della directory di installazione rimane invariato.

La directory di installazione viene creata la prima volta che viene installato un pacchetto, se non viene visualizzata una directory di installazione, provare prima a installare alcuni pacchetti.

Il livello radice della directory di installazione contiene:

  • Directory vcpkg che tiene traccia dei pacchetti e dei file installati
  • Directory per ogni tripletta. Ogni directory triplet contiene i file installati da ogni pacchetto.

Directory triplet

L'output di ogni installazione del pacchetto è contenuto in una directory specifica del triplet. Ad esempio, i pacchetti installati per il x64-windows triplet si trovano nella installed/x64-windows directory .

Il layout per le sottodirectory all'interno di ogni directory triplet è lo stesso:

Nota

Alcuni pacchetti possono produrre file che non corrispondono alle convenzioni descritte qui. Gli autori delle porte devono determinare il percorso finale dei file prodotti in base allo scopo usato da ogni file.

Sottodirectory Tipo di file
bin Rilascio .dll e .pdb file
debug/bin Eseguire il debug e .pdb i .dll file
debug/lib Eseguire il debug .libdi file , .so.dylib, e .a
debug/lib/manual-link Debug collegabile .libmanualmente, file , .dylib.so, e .a
debug/plugins/<group> File di debug di caricamento in fase di esecuzione .dll
debug/lib/pkgconfig Eseguire il debug di file pkgconfig (.pc)
include File di intestazione (.h, .hpp, .hxx)
lib Rilasciare .libfile , .so.dylib e .a
lib/manual-link Versione collegabile .libmanualmente, file , .dylib.so, e .a
lib/pkgconfig File Pkgconfig (.pc)
plugins/<group> File di versione .dll di caricamento in fase di esecuzione
share/<port> File aggiuntivi indipendenti dalla configurazione
share/<port>/copyright Testo della licenza per il pacchetto
share/<port>/usage File di istruzioni per l'integrazione del sistema di compilazione
share/<port>/vcpkg-port-config.cmake Funzioni e variabili CMake definite dalla porta
share/<lowercase-package>/<package>Config.cmake File di integrazione di CMake per find_package(package)
share/<cmakepackagename>/vcpkg-cmake-wrapper.cmake Override di CMake find_package(<cmakepackagename>)
share/pkgconfig File pkgconfig indipendenti dalla configurazione (.pc)
tools/<port> Strumenti eseguibili

bindirectory e debug/bin

In Windows queste directory contengono rispettivamente file DLL e PDB per la configurazione di rilascio e debug. Qualsiasi file eseguibile prodotto da una porta deve essere spostato in una tools/<port> directory.

include

Contiene i file di intestazione (.h, .hpp, .hxx). Il layout in questa directory deve riflettere l'utilizzo previsto dei file di intestazione del pacchetto. Ad esempio, una contoso libreria che intende usare #include <contoso/contoso.h> deve fornire il file include/contoso/contoso.hdi intestazione .

vcpkg impedisce l'installazione di alcuni nomi di file di intestazione riservati nella radice della include directory, ad esempio, err.h, user.htime.h, e altri. Le librerie che forniscono un nome file di intestazione non consentito devono inserire i file di intestazione all'interno di una include/<port> directory. Se la libreria intende sostituire un file di intestazione di sistema, deve impostare i VCPKG_POLICY_ALLOW_RESTRICTED_HEADERS criteri nel relativo portfile.cmake.

libdirectory e debug/lib

Contiene librerie statiche, importare librerie (in Windows) e librerie condivise (in non Windows).

Contiene librerie che devono essere collegate manualmente.

I file che possono causare problemi quando collegati devono essere inseriti automaticamente nelle lib/manual-link cartelle anziché nella lib directory. Ad esempio, se una libreria è destinata a definire la main() funzione per un programma.

lib/pkgconfig, debug/lib/pkgconfig e share/pkgconfig directory

Contiene file di integrazione pkgconfig (.pc). Una libreria non deve fornire file dipendenti dalla configurazione e indipendenti dalla configurazione contemporaneamente. Ad esempio: non installare lib/pkgconfig/contoso.pc e share/pkgconfig/contoso.pc.

plugins/<group> e debug/plugins/<group>

Contiene librerie condivise che devono essere caricate durante il runtime usando le applicazioni.

share/<port>

Contiene file esterni installati da ogni porta. Ad esempio, file SPDX, script e così via.

vcpkg prevede che le porte forniscano un copyright file contenente le informazioni sulla licenza del pacchetto installato. Per altre informazioni, vedere la guida del responsabile della manutenzione.

share/<port>/usage

File di testo con istruzioni per integrare una libreria all'interno di un progetto. Per altre informazioni, vedere la guida per fornire la documentazione sull'utilizzo dei pacchetti .

share/<lowercase-package>/<package>Config.cmake, share/<package>/<package>-config.cmake

I file di integrazione di CMake devono essere inseriti nella share cartella e rispettare le regole di CMake per find_package(package) in CONFIG modalità .

Ad esempio, se una porta prevede di fornire find_package(MyPackage REQUIRED), deve fornire share/mypackage/MyPackageConfig.cmake o share/mypackage/MyPackage-config.cmake.

Se un pacchetto fornisce file di integrazione CMake, vcpkg_cmake_config_fixup() La funzione helper deve essere richiamata per correggere eventuali percorsi non rilocabili e unire configurazioni di compilazione.

tools/<port>

Importante

vcpkg è prima di tutto un gestore delle dipendenze della libreria C++. Gli autori delle porte devono essere intenzionali quando si decide di includere gli strumenti nell'output dell'installazione. Si consideri ad esempio l'installazione di un eseguibile di versione solo quando lo strumento di debug non è necessario.

Contiene strumenti eseguibili prodotti da una porta. È consigliabile, ma non obbligatorio, che ogni eseguibile installato venga inserito in una sottodirectory corrispondente al nome della porta che lo ha prodotto. Ad esempio, una contoso porta potrebbe installare un ContosoGenerator.exe oggetto in tools/contoso/ContosoGenerator.exe.

Alcune porte richiedono che i file eseguibili vengano inseriti in una bin sottodirectory, nel qual caso il modello consigliato è tools/<port>/bin.