Konwencje układu katalogu instalacji

W tym artykule opisano konwencje układu używane przez program vcpkg dla katalogu instalacyjnego. Katalog instalacyjny zawiera pliki zainstalowane przez każdy pakiet. Autorzy portów powinni upewnić się, że ich pakiety są zgodne z konwencjami opisanymi w tym artykule.

W trybie klasycznym katalog instalacyjny znajduje się w $VCPKG_ROOT/installed lokalizacji (gdzie $VCPKG_ROOT znajduje się ścieżka instalacji programu vcpkg). W trybie manifestu każdy plik manifestu ma odpowiedni vcpkg_installed katalog. Lokalizację katalogu instalacyjnego można zmienić za --x-install-root pomocą opcji . Niezależnie od trybu operacji układ katalogu instalacyjnego pozostaje taki sam.

Katalog instalacyjny jest tworzony przy pierwszym zainstalowaniu pakietu, jeśli nie widzisz katalogu instalacyjnego, spróbuj najpierw zainstalować niektóre pakiety.

Poziom główny katalogu instalacyjnego zawiera:

• vcpkg Katalog, który śledzi zainstalowane pakiety i pliki
• Katalog dla każdej trójki. Każdy katalog potrójny zawiera pliki zainstalowane przez każdy pakiet.

Katalogi potrójne

Dane wyjściowe każdej instalacji pakietu znajdują się w katalogu specyficznym dla triplet. Na przykład pakiety zainstalowane dla x64-windows triplet znajdują się w installed/x64-windows katalogu.

Układ podkatalogów wewnątrz każdego katalogu potrójnego jest taki sam:

Uwaga

Niektóre pakiety mogą tworzyć pliki, które nie są zgodne z konwencjami opisanymi tutaj. Autorzy portów powinni określić ostateczną lokalizację utworzonych plików w oparciu o przeznaczenie, do których służy każdy plik.

Podkatalogu	Typ pliku
bin	Wydanie .dll i .pdb pliki
debug/bin	Debugowanie .dll i .pdb pliki
debug/lib	Debugowanie .libplików , .so, .dylibi .a
debug/lib/manual-link	Debugowanie .libz możliwością ręcznego łączenia , , .so.dylibi .a plików
debug/plugins/<group>	Pliki debugowania ładowania środowiska uruchomieniowego .dll
debug/lib/pkgconfig	Debugowanie plików pkgconfig (.pc)
include	Pliki nagłówkowe (.h, .hpp, .hxx)
lib	Wydawanie .libplików , .so.dylib i .a
lib/manual-link	Ręczne łączenie wersji .lib, , .so.dylibi .a plików
lib/pkgconfig	Pliki Pkgconfig (.pc)
plugins/<group>	Pliki wydania .dll ładowania środowiska uruchomieniowego
share/<port>	Dodatkowe pliki niezależne od konfiguracji
share/<port>/copyright	Tekst licencji pakietu
share/<port>/usage	Plik instrukcji integracji systemu kompilacji
share/<port>/vcpkg-port-config.cmake	Funkcje i zmienne CMake zdefiniowane przez port
share/<lowercase-package>/<package>Config.cmake	Pliki integracji narzędzia CMake dla programu find_package(package)
share/<cmakepackagename>/vcpkg-cmake-wrapper.cmake	Przesłonięcia narzędzia CMake find_package(<cmakepackagename>)
share/pkgconfig	Pliki pkgconfig niezależne od konfiguracji (.pc)
tools/<port>	Narzędzia wykonywalne

bin i debug/bin katalogi

W systemie Windows te katalogi zawierają odpowiednio pliki DLL i PDB na potrzeby konfiguracji wydania i debugowania. Każdy plik wykonywalny utworzony przez port powinien zostać przeniesiony tools/<port> do katalogu.

include

Zawiera pliki nagłówka (.h, .hpp, .hxx). Układ w tym katalogu powinien odzwierciedlać zamierzone użycie plików nagłówkowych pakietu. Na przykład biblioteka, która ma być używana#include <contoso/contoso.h>, contoso powinna podać plik include/contoso/contoso.hnagłówka .

Program vcpkg zabrania instalowania niektórych zastrzeżonych nazw plików nagłówka include w katalogu głównym, na przykład: err.h, user.h, time.hi innych. Biblioteki, które udostępniają niedozwoloną nazwę pliku nagłówka, powinny umieszczać swoje pliki nagłówkowe include/<port> w katalogu. Jeśli biblioteka zamierza zastąpić plik nagłówka systemu, powinna ustawić VCPKG_POLICY_ALLOW_RESTRICTED_HEADERS zasady w pliku portfile.cmake.

lib i debug/lib katalogi

Zawiera biblioteki statyczne, biblioteki importu (w systemie Windows) i biblioteki udostępnione (w systemie innym niż Windows).

lib/manual-link i debug/lib/manual-link katalogi

Zawiera biblioteki, które muszą być połączone ręcznie.

Pliki, które mogą powodować problemy, gdy połączone automatycznie muszą zostać umieszczone w lib/manual-link folderach zamiast katalogu lib . Jeśli na przykład biblioteka ma na celu zdefiniowanie main() funkcji dla programu.

lib/pkgconfigi debug/lib/pkgconfig share/pkgconfig katalogi

Zawiera pliki integracji pkgconfig (.pc). Biblioteka nie powinna jednocześnie udostępniać plików zależnych od konfiguracji i niezależnych od konfiguracji. Na przykład: nie instaluj lib/pkgconfig/contoso.pc i share/pkgconfig/contoso.pc.

plugins/<group> i debug/plugins/<group>

Zawiera biblioteki udostępnione, które mają być ładowane podczas wykonywania przez korzystanie z aplikacji.

share/<port>

Zawiera różne pliki zainstalowane przez każdy port. Na przykład pliki SPDX, skrypty itp.

share/<port>/copyright

Program vcpkg oczekuje, że porty będą dostarczać copyright plik zawierający informacje o licencji zainstalowanego pakietu. Aby uzyskać więcej informacji, zobacz przewodnik obsługi.

share/<port>/usage

Plik tekstowy z instrukcjami integrowania biblioteki w projekcie. Aby uzyskać więcej informacji, zobacz przewodnik dotyczący udostępniania dokumentacji użycia pakietów.

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

Pliki integracji narzędzia CMake należy umieścić w folderze share i przestrzegać reguł narzędzia CMake dla find_package(package) w CONFIG trybie.

Jeśli na przykład port oczekuje podania find_package(MyPackage REQUIRED)parametru , musi podać wartość share/mypackage/MyPackageConfig.cmake lub share/mypackage/MyPackage-config.cmake.

Jeśli pakiet udostępnia pliki integracji narzędzia CMake, vcpkg_cmake_config_fixup() Funkcja pomocnika powinna być wywoływana w celu naprawienia wszelkich ścieżek nieprzydzielonych i scalania konfiguracji kompilacji.

tools/<port>

Ważne

Narzędzie vcpkg jest przede wszystkim menedżerem zależności biblioteki języka C++. Autorzy portów powinni być celowi podczas podejmowania decyzji o dołączeniu narzędzi do danych wyjściowych instalacji. Na przykład: rozważ zainstalowanie tylko pliku wykonywalnego wydania, gdy narzędzie debugowania nie jest potrzebne.

Pliki wykonywalne wydania i debugowania powinny być udostępniane, gdy pliki wykonywalne są przeznaczone do użytku w czasie wykonywania.

Zawiera narzędzia wykonywalne utworzone przez port. Zdecydowanie zaleca się, ale nie jest to wymagane, że każdy zainstalowany plik wykonywalny przechodzi do podkatalogu zgodnego z nazwą portu, który go wygenerował. Na przykład contoso port może zainstalować ContosoGenerator.exe element na .tools/contoso/ContosoGenerator.exe

Niektóre porty wymagają, aby ich pliki wykonywalne przechodziły do podkatalogu. W takim przypadku zalecanym wzorcem bin jest tools/<port>/bin.