질문과 대답
vcpkg를 사용하여 종속성을 관리하는 방법에는 두 가지가 있습니다.
- 매니페스트 모드 를 사용하면 직접 종속성, 버전 제약 조건 및 사용된 레지스트리를 호출
vcpkg.json
된 파일에서 선언할 수 있습니다. 이 파일은 코드 리포지토리에 포함되어야 하며 소스 제어 시스템에 체크 인할 수 있습니다. 종속성은 라는vcpkg_installed
하위 폴더에 설치됩니다. 이렇게 하면 각 코드 프로젝트에 고유한 종속성 집합이 있을 수 있습니다. 아무것도 시스템 전체에 설치되지 않습니다. 다른 인수 없이 실행vcpkg install
하거나 MSBuild 및 CMake 프로젝트와의 자동 통합을 활용하여 매니페스트 모드에서 vcpkg를 실행할 수 있습니다. 종속성을 더 잘 제어할 수 있으므로 대부분의 경우 클래식 모드를 통해 프로젝트에 매니페스트를 사용하는 것이 좋습니다. 자세한 내용은 매니페스트 모드 문서를 참조하세요. - 클래식 모드 는 종속성을 관리하는 보다 전통적인 방법입니다. 여기에는 설치, 수정 또는 제거할 각 직접 종속성을 지정하는 vcpkg 명령 실행이 포함됩니다. 종속성은 vcpkg 설치 디렉터리 내에 저장되므로 여러 사용 프로젝트가 동일한 종속성 집합을 참조할 수 있습니다. 자세한 내용은 클래식 모드 문서를 참조하세요.
예! 먼저 기여 지침 읽습니다. 또한 자세한 내용은 유지 관리 가이드를 살펴보세요. vcpkg에 포트를 추가하여 시작하는 데 도움이 되는 자습서도 있습니다.
기여하고 싶지만 특정 라이브러리를 염두에 두지 않는 경우 새 포트 요청 목록을 살펴보세요.
예! export
다른 환경으로 내보내기 위한 이진 파일을 생성하려면 명령을 참조하세요.
또는 나중에 다시 사용하기 위해 작업에서 생성된 vcpkg install
이진 파일을 보존하는 것이 목표인 경우 이진 캐싱 기능을 참조 하세요.
매니페스트(vcpkg.json 파일)를 사용하여 종속성을 관리하는 경우 해당 파일을 업데이트해야 합니다. 자세한 내용은 버전 관리 참조 설명서를 참조하세요.
클래식 모드에서 vcpkg를 사용하는 경우(명령을 실행하여 패키지 관리, 매니페스트 파일 없음) 명령 설명서를 참조 vcpkg update
하세요. 이 명령은 현재 포트파일과 동기화되지 않은 모든 패키지를 나열합니다. 그런 다음, 명령을 실행 vcpkg upgrade
하여 변경 내용을 확인해야 합니다.
라이브러리 목록은 디렉터리에서 ports\
열거됩니다. 디자인상 본인 또는 회사에 적합한 것으로 확인되면 이 디렉터리에서 라이브러리를 추가하고 제거할 수 있습니다. zipfile 및 GitHub 리포지토리 패키징에 대한 예제를 참조하세요.
GitHub에서 직접 복제하고 포트 파일 목록을 업데이트하는 데 사용하는 git pull
것이 좋습니다.
예. 패키징 예제에 따라 고유한 포트를 만들고 오버레이 포트 및 레지스트리 설명서를 참조하여 프라이빗 포트를 관리하는 방법을 알아봅니다.
레지스트리에 프라이빗 라이브러리를 게시하여 이 작업을 추가로 수행할 수 있습니다. 레지스트리 만들기에 대한 문서를 참조하세요. 레지스트리는 오픈 소스 라이브러리가 포함된 vcpkg와 유사한 포트 컬렉션입니다.
예. 라이브러리의 경우 기본적으로 헤더와 이진 파일을 올바른 정렬${CURRENT_PACKAGES_DIR}
에 배치하는 스크립트이므로 미리 빌드된 이 portfile.cmake
진 파일을 끌어오려면 파일을 직접 다운로드하고 정렬하는 포트파일을 작성할 수 있습니다.
이 예제를 보려면 Windows SDK에서 ports\opengl\portfile.cmake
파일을 복사하기만 하면 됩니다.
테스트된 기본 제공 연속 통합 세 가지는 다음과 같습니다.
- Windows Desktop(x86, x64, x64-static, arm64)
- 유니버설 Windows 플랫폼(x64 및 arm64)
- Mac OS X(x64 정적)
- Linux(x64 정적)
- 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
하여 최신 원본을 구한 다음(Windows) 또는 ./bootstrap-vcpkg.sh
(Unix)를 실행 bootstrap-vcpkg.bat
하여 vcpkg를 업데이트합니다. 또는 Visual Studio와 함께 제공되는 vcpkg 복사본을 사용하는 경우 Visual Studio 설치 관리자 Visual Studio 버전을 업데이트하기만 하면 됩니다.
매니페스트 파일을 사용하여 개별 프로젝트에 대한 종속성을 관리하는 것이 좋습니다. 이는 여러 프로젝트가 동일한 컴퓨터에 있고 패키지 버전과 어떤 레지스트리 라이브러리에서 들어오는지 쉽게 관리할 수 있는 경우에도 작동합니다.
그러나 클래식 모드를 대신 사용하는 경우 vcpkg의 단일 인스턴스(예: 하나의 집합 installed\
packages\
ports\
등)에서 라이브러리 버전을 하나만 설치할 수 있습니다(그렇지 않으면 헤더가 서로 충돌함). 시스템 전체 패키지 관리자 경험이 있는 경우 vcpkg의 패키지는 또는 X-devel
패키지에 X-dev
해당합니다. 이 경우 다른 프로젝트에 서로 다른 버전의 라이브러리를 사용하려면 vcpkg의 별도 인스턴스를 만들고 프로젝트별 통합 메커니즘을 사용하는 것이 좋습니다. 각 라이브러리의 버전은 파일에서 ports\
지정되므로 표준 git
명령을 사용하여 쉽게 조작할 수 있습니다. 이렇게 하면 라이브러리의 전체 집합을 모두 서로 작동하는 일관된 이전 버전 집합으로 롤백하는 것이 매우 쉽습니다. 그런 다음 특정 라이브러리를 앞으로 고정해야 하는 경우 적절한 버전의 ports\<package>\
. 애플리케이션이 라이브러리 버전에 매우 중요한 경우 프로젝트 원본과 함께 소스 제어에 필요한 특정 포트파일 집합을 확인하고 작업 디렉터리를 vcpkg.exe
리디렉션하는 옵션을 사용하는 --vcpkg-root
것이 좋습니다.
개인 정보 보호와 관련된 모든 정보는 개인 정보 문서를 참조하세요.
예. CMake 도구 체인 파일이 이미 있는 경우 도구 체인 파일을 끝 부분에 포함해야 합니다. 지시문만큼 include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake)
간단해야 합니다. 또는 기존 도구 체인 파일의 끝에 콘텐츠를 scripts\buildsystems\vcpkg.cmake
복사할 수 있습니다.
예. 현재 버전에서는 이를 변경하는 표준화된 전역 방법이 아직 없지만 개별 포트파일을 편집하고 원하는 대로 정확한 빌드 프로세스를 조정할 수 있습니다.
변경 내용을 포트파일에 저장하고 체크 인하면 나중에 처음부터 다시 빌드하고 사용한 정확한 설정을 잊어버린 경우에도 동일한 결과를 얻을 수 있습니다.
예. vcpkg는 라이브러리를 빌드할 때 표준 "릴리스" 및 "디버그" 구성만 생성하지만 프로젝트의 표준 구성 외에도 프로젝트의 사용자 지정 구성에 대한 통합 지원을 받을 수 있습니다.
우선 vcpkg는 "릴리스"(resp. "Debug")로 시작하는 모든 사용자 지정 구성을 표준 "릴리스"(resp. "Debug") 구성과 호환되는 구성으로 자동으로 가정하고 그에 따라 작동합니다.
다른 구성의 경우 프로젝트 파일(.vcxproj)에서 MSBuild $(VcpkgConfiguration)
매크로를 재정의하여 구성과 대상 표준 구성 간의 호환성을 선언하기만 하면 됩니다. 안타깝게도 MSBuild의 순차적 특성으로 인해 vcxproj에서 해당 설정을 훨씬 더 높게 추가해야 vcpkg 통합이 로드되기 전에 선언됩니다. 매크로를 $(VcpkgConfiguration)
"Globals" PropertyGroup에 추가하는 것이 좋습니다.
예를 들어 프로젝트 파일에 추가하여 "MyRelease" 구성에 대한 지원을 추가할 수 있습니다.
<PropertyGroup Label="Globals">
...
<VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>
물론 사용자 지정 구성이 대상 구성과 호환되는 경우에만 실행 가능한 이진 파일을 생성합니다(예: 둘 다 동일한 런타임 라이브러리와 연결해야 함).
예. 프로젝트별 사용에 적합한 NuGet 패키지는 명령(경량 연결) 또는 vcpkg export --nuget
명령(shrinkwrapped)을 통해 vcpkg integrate project
생성할 수 있습니다.
NuGet 패키지와 vcpkg integrate project
동일한 수준을 달성하기 위한 하위 수준 메커니즘은 파일을 통해 이루어집니다 <vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets
. vcpkg를 설치한 경로로 대체 <vcpkg_root>
하여 .vcxproj 파일에서 가져오기만 하면 됩니다.
<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 업데이트 3 이상을 지원합니다.
사용자 전체 통합(vcpkg integrate install
)을 사용하도록 설정하면 일부 프로젝트 속성의 기본값이 변경됩니다. 특히 "C/C++/일반/추가 포함 디렉터리" 및 "링커/일반/추가 라이브러리 디렉터리"는 일반적으로 사용자 전체 통합 없이 비어 있습니다. 통합 시 빈 값은 vcpkg에서 제공하는 보강된 기본값이 재정의되고 헤더/라이브러리를 찾을 수 없음을 의미합니다. 기본값을 복원하려면 부모로부터 상속할 속성을 설정합니다.
NuGet은 MSBuild에 대한 강력한 종속성을 가진 .NET 라이브러리의 패키지 관리자입니다. 적어도 세 가지 방법으로 네이티브 C++ 고객의 특정 요구 사항을 충족하지 않습니다.
컴파일 버전입니다. 컴파일 옵션의 가능한 조합이 너무 많기 때문에 진정으로 완전한 옵션 집합을 제공하는 작업은 본질적으로 불가능합니다. 또한 합리적으로 완성된 이진 패키지의 다운로드 크기는 엄청나게 깁니다. 따라서 결과를 여러 패키지로 분할해야 하지만 검색이 매우 어려워집니다.
이진 및 원본. 첫 번째 지점에 매우 밀접하게 연결된 NuGet은 비교적 작고 미리 빌드된 이진 파일을 제공하기 위해 처음부터 설계되었습니다. 네이티브 코드의 특성으로 인해 개발자는 ABI 호환성, 성능, 무결성 및 디버깅 기능을 보장하기 위해 소스 코드에 액세스할 수 있어야 합니다.
dll 및 애플리케이션별. NuGet은 프로젝트 중심입니다. 이는 기본 라이브러리가 더 높은 API를 중단하지 않고 계속 발전할 수 있기 때문에 자연스럽게 안정적인 API를 사용하는 관리되는 언어에서 잘 작동합니다. 그러나 ABI가 훨씬 더 취약한 네이티브 언어에서 유일한 강력한 전략은 최종 애플리케이션에 포함될 정확한 종속성에 대해 각 라이브러리를 명시적으로 빌드하는 것입니다. NuGet에서는 이를 보장하기가 어렵고, 연결이 끊어지고 독립적으로 버전이 지정된 에코시스템으로 이어집니다.
Conan.io python으로 작성된 공개적으로 페더레이션된 프로젝트 중심 플랫폼 간 C++ 패키지 관리자입니다. 주요 차이점은 다음과 같습니다.
공용 페더레이션 및 프라이빗 페더레이션. Conan은 각 패키지의 독립 복사본을 게시하는 개인에 의존합니다. 이 방법은 다양한 방식으로 모두 손상되는 많은 패키지를 권장한다고 생각합니다. Boost 1.56에 대한 20개 이상의 공개 패키지 목록을 선택하여 특정 상황에 적합한 소수를 결정하는 것은 사용자의 시간 낭비라고 생각합니다. 대조적으로, 우리는 대부분의 경우에 작동하고 사용자가 자신의 개인 버전에서 자유롭게 해킹 할 수 있도록 단일, 공동으로 유지 관리 버전이 있어야한다고 생각합니다. 우리는 이것이 서로 심하게 테스트되고 필요한 개인 수정을위한 환상적인 기반을 형성하는 고품질 패키지 세트를 초래할 것이라고 믿습니다.
dll 및 애플리케이션별. 종속성이 라이브러리 수준에서 독립적으로 버전 관리되는 경우 모든 빌드 환경이 완전히 독특하고, 견고하고 잘 테스트된 에코시스템을 활용하거나 기여할 수 없는 것이 좋습니다. 반면, 모든 라이브러리를 플랫폼으로 함께 버전 관리함으로써(시스템 패키지 관리자와 유사) 에코시스템의 품질과 안정성을 최대화하기 위해 매우 일반적인 라이브러리 버전 집합에 대한 테스트 및 노력을 모으기를 희망합니다. 또한 라이브러리가 애플리케이션의 선택과 충돌하는 버전을 요청하는 기능을 완전히 디자인합니다(openssl Z 및 boost X를 원하지만 X는 openssl Y에서 작동하도록 클레임만 표시).
플랫폼 간 및 단일 플랫폼. 많은 플랫폼에서 호스팅되는 것은 훌륭한 노스 스타이지만, 우리는 apt-get, yum 및 homebrew에서 제공하는 시스템 통합 및 안정성 수준이 자동화 된 스크립트에서
brew install boost
교환apt-get install libboost-all-dev
하는 데 필요한 가치가 있다고 믿습니다. 우리는 이미 성공적이고 사랑받는 곳에서 시스템을 교체하는 대신 매우 성공적인 시스템 관리자vcpkg install boost
와 가능한 한 쉽게 통합할 수 있도록 하기로 결정했습니다.C++/CMake 및 python Python은 많은 사람들에게 사랑받는 훌륭한 언어이지만, 패키지 관리자로서 워크플로에 중요한 도구를 선택할 때 투명성과 친숙함이 가장 중요한 요소라고 생각합니다. 따라서 구현 언어를 가능한 한 보편적으로 허용하도록 선택했습니다. C++는 C++ 프로그래머용 C++ 패키지 관리자에서 사용해야 합니다. 패키지 관리자를 이해하기 위해 다른 프로그래밍 언어를 학습할 필요가 없습니다.
Chocolatey는 애플리케이션을 관리하기 위한 훌륭한 시스템입니다. 그러나 현재는 재배포 가능한 개발자 자산을 확보하고 디버깅에 도움이 되도록 설계되지 않았습니다. vcpkg는 애플리케이션을 빌드하는 데 필요한 라이브러리를 제공하고 원하는 플랫폼(Chocolatey 포함)을 통해 제공하는 데 도움이 되도록 설계되었습니다.
vcpkg 피드백
vcpkg은(는) 오픈 소스 프로젝트입니다. 다음 링크를 선택하여 피드백을 제공해 주세요.