よく寄せられる質問

クラシック モードとマニフェスト モードとは

vcpkg を使用して依存関係を管理するには、次の 2 つの方法があります。

  1. マニフェスト モード を使用すると、直接の依存関係、バージョン制約、および使用されるレジストリを呼び出された vcpkg.jsonファイルで宣言できます。 このファイルはコード リポジトリに含める必要があり、ソース管理システムにチェックできます。 依存関係は、という名前 vcpkg_installedのサブフォルダーにインストールされます。 これにより、コード プロジェクトごとに独自の依存関係のセットを持つことができます。システム全体に何もインストールされていません。 vcpkg をマニフェスト モードで実行するには、(他の引数なしで) 実行vcpkg installするか、MSBuild および CMake プロジェクトとの自動統合を利用します。 ほとんどの場合、依存関係をより適切に制御するため、プロジェクトに対してマニフェストをクラシック モードで使用することをお勧めします。 詳細については、 マニフェスト モードに関する記事 を参照してください。
  2. クラシック モード は、依存関係を管理する従来の方法です。これには、インストール、変更、または削除する各直接依存関係を指定する vcpkg コマンドの実行が含まれます。 依存関係は vcpkg インストール ディレクトリ内に格納されるため、複数の使用しているプロジェクトが同じ依存関係のセットを参照できます。 詳細については、 クラシック モードに関する記事 を参照してください。

新しいライブラリを投稿できますか?

はい。 まず、コントリビューション ガイドラインを読んでくださいさらに詳しく説明するメンテナー ガイドもご覧ください。 開始するのに役立つ vcpkg にポートを追加するためのチュートリアルもあります

投稿したいが、特定のライブラリを念頭に置いていない場合は、新しいポート要求の 一覧を見てください。

vcpkg はビルド済みのバイナリ パッケージを作成できますか? vcpkg で使用されるバイナリ形式は何ですか?

はい。 他の export 環境にエクスポートするためのバイナリを生成する場合は、このコマンド を参照してください。

または、後で再利用するために操作によって vcpkg install 生成されたバイナリを保持することが目的の場合は、バイナリ キャッシュ機能を 参照してください。

ライブラリ操作方法更新しますか?

マニフェスト (vcpkg.json ファイル) を使用して依存関係を管理する場合は、そのファイルを更新する必要があります。 詳細については、 バージョン管理のリファレンス ドキュメント を参照してください。

クラシック モードで vcpkg を使用している場合 (パッケージを管理するためのコマンドを実行し、マニフェスト ファイルを使用しない場合)、コマンドのドキュメントを vcpkg update 参照してください。 このコマンドは、現在のポートファイルと同期していないすべてのパッケージを一覧表示します。 その後、コマンドを実行vcpkg upgradeして変更を確認する必要があります。

ライブラリ操作方法増えますか?

ライブラリの一覧は、ディレクトリから ports\ 列挙されます。 設計上、自分または会社に合わせて、このディレクトリのライブラリを追加および削除できます。zipfile と GitHub リポジトリのパッケージ化の例を参照してください。

GitHub から直接複製し、使用してgit pullポートファイルの一覧を更新することをお勧めします。

このツールを使用してプライベート ライブラリを構築できますか?

はい。 パッケージ化の例に従って独自のポートを作成し、オーバーレイ ポートレジストリのドキュメントを参照して、プライベート ポートを管理する方法を確認します。

これをさらに進めるために、プライベート ライブラリをレジストリに発行します。 レジストリの作成に関する記事を参照してください。 レジストリは、オープンソース ライブラリを含む vcpkg で提供されるのと同様に、ポートのカタログです。

このツールで事前構築済みのプライベート ライブラリを使用できますか?

はい。 ライブラリ用は portfile.cmake 基本的に、ヘッダーとバイナリを正しい配置 ${CURRENT_PACKAGES_DIR}に配置するスクリプトであるため、事前構築済みのバイナリをプルするために、ファイルを直接ダウンロードして配置するポートファイルを記述できます。

この例を確認するには、 ports\opengl\portfile.cmake Windows SDK からファイルをコピーする方法を確認します。

vcpkg でターゲットにできるプラットフォームはどれですか?

当社の組み込みの継続的インテグレーションテスト済みトリプレットは次のとおりです。

  • Windows デスクトップ (x86、x64、x64-static、arm64)
  • ユニバーサル Windows プラットフォーム (x64、arm64)
  • Mac OS X (x64-static)
  • Linux (x64-static)
  • Android (x64、arm64、arm-neon)

これらのターゲットは、各 vcpkg リリースとの互換性のためにより厳密にテストされます。 ただし、iOS、MinGW、WebAssembly、freeBSD、openBSD など、より多くのプラットフォームとアーキテクチャで利用できるコミュニティ トリプレットの数が大幅に増えています。

また、ニーズに応じて独自のトリプレットを定義することもできます。 vcpkg は非常にカスタマイズ可能です。

詳細については、現在の一覧を参照 vcpkg help triplet し、 トリプレットのドキュメント を確認してください。

vcpkg は Linux/OS X で実行されますか?

はい。 OS X と Ubuntu 22.04 で継続的にテストを行っていますが、ユーザーが Arch、Fedora、FreeBSD で成功したことはわかっています。 お気に入りの Linux ディストリビューションで問題が発生した場合は、問題をお知らせください。

vcpkg 操作方法更新しますか?

git pull実行して最新のソースを取得し、(Windows) または ./bootstrap-vcpkg.sh (Unix) を実行bootstrap-vcpkg.batして vcpkg を更新します。 または、Visual Studio に付属する vcpkg のコピーを使用している場合は、Visual Studio インストーラーから Visual Studio のバージョンを更新するだけです。

1 台のコンピューターで異なるバージョンのライブラリを使用操作方法。

マニフェスト ファイルを使用して個々のプロジェクトの依存関係を管理することをお勧めします。これは、複数のプロジェクトが同じコンピューター上にある場合でも機能し、パッケージ バージョンと、どのレジストリ ライブラリのソースを簡単に管理できます。

ただし、代わりにクラシック モードを使用している場合は、vcpkg の 1 つのインスタンス内 (たとえば、1 セットinstalled\などpackages\ports\) にライブラリのバージョンを 1 つだけインストールできます (それ以外の場合、ヘッダーは互いに競合します)。 システム全体のパッケージ マネージャーの経験がある場合、vcpkg 内のパッケージは、パッケージX-develX-dev対応します。 この場合、プロジェクトごとに異なるバージョンのライブラリを使用するには、vcpkg の個別のインスタンスを作成し、プロジェクトごとの統合メカニズムを使用することをお勧めします。 各ライブラリのバージョンはファイルによって ports\指定されるため、標準 git コマンドを使用して簡単に操作できます。 これにより、ライブラリのセット全体を、互いに連携する一貫した古いバージョンのセットにロールバックすることが非常に簡単になります。 その後、特定のライブラリを前方にピン留めする必要がある場合は、適切なバージョンをチェックするのports\<package>\と同じくらい簡単です。 アプリケーションがライブラリのバージョンに非常に敏感な場合は、必要なポートファイルのセットをプロジェクト ソースと共にソース管理にチェックし、作業ディレクトリvcpkg.exeをリダイレクトするオプションを使用--vcpkg-rootすることをお勧めします。

vcpkg はどのようにしてプライバシーを保護しますか?

プライバシーに 関するすべての情報については、プライバシーに関するドキュメント を参照してください。

vcpkg のツールチェーン ファイルで独自の CMake ツールチェーン ファイルを使用できますか?

はい。 既に CMake ツールチェーン ファイルがある場合は、ツールチェーン ファイルを最後に含める必要があります。 これはディレクティブと同じくらい単純である include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake) 必要があります。 または、既存のツールチェーン ファイルの末尾に内容 scripts\buildsystems\vcpkg.cmake をコピーすることもできます。

ライブラリの再構築に独自のフラグまたは特定のフラグを使用できますか?

はい。 現在のバージョンでは、それらを変更するための標準化されたグローバルな方法はまだありませんが、個々のポートファイルを編集し、必要に応じて正確なビルドプロセスを調整することができます。

ポートファイルへの変更を保存してチェックすることで、将来最初からリビルドし、使用した正確な設定を忘れた場合でも、同じ結果が得られます。

カスタム構成の vcpkg 統合を取得できますか?

はい。 vcpkg ではライブラリのビルド時にのみ標準の "リリース" 構成と "デバッグ" 構成が生成されますが、プロジェクトの標準構成に加えて、プロジェクトのカスタム構成の統合サポートを受けることができます。

まず、vcpkg は、標準の "Release" (resp. "Debug") 構成と互換性のある構成として、"Release" (resp. "Debug") で始まるカスタム構成を自動的に想定し、それに応じて動作します。

その他の構成では、プロジェクト ファイル (.vcxproj) 内の MSBuild $(VcpkgConfiguration) マクロをオーバーライドして、構成とターゲットの標準構成の間の互換性を宣言するだけで済みます。 残念ながら、MSBuild のシーケンシャルな性質により、vcpkg 統合が読み込まれる前に宣言されるように、vcxproj でこれらの設定をはるかに高く追加する必要があります。 マクロを "Globals" PropertyGroup に追加することをお勧めします $(VcpkgConfiguration)

たとえば、プロジェクト ファイルに追加することで、"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 のみ)

ローカル バイナリキャッシュまたはアセットキャッシュを構成している場合は、必要に応じて定期的にクリーンすることもできます。

CMake は vcpkg によって内部的にどのように使用されますか?

vcpkg は、ビルド スクリプト言語として内部的に CMake を使用します。 これは、CMake はクロスプラットフォーム オープンソース ライブラリ用の非常に一般的なビルド システムであり、C++ プロジェクト全般で非常に人気が高まっているためです。 Windows で簡単に入手でき、システム全体のインストールを必要とせず、なじみのないユーザーには判読できます。

vcpkg は、パブリック サーバーまたはプライベート サーバーからのコンパイル済みバイナリのダウンロードをサポートしていますか?

好みのビルド構成でライブラリを 1 回ビルドし、バイナリ キャッシュ機能を使用して、毎回ビルドし直すことなくバイナリを再利用することをお勧めします。 これは、チーム プロジェクトで作業する場合、または複数のマシン、コンテナー、仮想マシンなどの継続的インテグレーション環境でローカルに構築する場合に便利です。

サポートされている MSVC ツールセット

Visual Studio 2015 Update 3 以降がサポートされています。

Visual Studio でユーザー全体の統合が有効になっているライブラリが使用されないのはなぜですか?

ユーザー全体の統合 (vcpkg integrate install) を有効にすると、一部のプロジェクト プロパティの既定値が変更されます。 特に、"C/C++/General/Additional Include Directory" と "Linker/General/Additional Library Directories" は通常、ユーザー全体の統合なしで空白になります。 統合では 、空白の値は、vcpkg によって提供される拡張既定値がオーバーライドされ、ヘッダー/ライブラリが見つからないことを意味します。 既定値を元に戻すには、親から継承するプロパティを設定します。

NuGet ではないのはなぜですか?

NuGet は、MSBuild に強い依存関係を持つ .NET ライブラリのパッケージ マネージャーです。 少なくとも 3 つの方法で、ネイティブ C++ のお客様の特定のニーズを満たしていません。

  • コンパイル フレーバー。 コンパイル オプションの可能な組み合わせが非常に多いので、完全なオプション セットを提供するタスクは本質的に不可能です。 さらに、合理的に完全なバイナリパッケージのダウンロードサイズは膨大になります。 これにより、結果を複数のパッケージに分割する必要がありますが、検索が非常に困難になります。

  • バイナリとソース。 最初の点に非常に密接に結びついている NuGet は、比較的小さい事前構築済みバイナリを提供するように一から設計されています。 ネイティブ コードの性質上、開発者は ABI の互換性、パフォーマンス、整合性、デバッグ可能性を確保するために、ソース コードにアクセスできる必要があります。

  • dll ごととアプリケーションごと。 NuGet はプロジェクト中心です。 これは、自然に安定した AVI を持つマネージド言語で適切に機能します。これは、基本ライブラリが上位のライブラリを壊すことなく進化し続けることができるためです。 ただし、ABI がはるかに脆弱なネイティブ言語では、唯一の堅牢な戦略は、最終的なアプリケーションに含まれる正確な依存関係に対して各ライブラリを明示的に構築することです。 これは NuGet で確実に行うのが難しく、高度に切断され、独立してバージョン管理されたエコシステムにつながります。

なぜコナンではないのですか?

Conan.io は、Python で記述された、パブリックにフェデレーションされたプロジェクト中心のクロスプラットフォーム C++ パッケージ マネージャーです。 主な違いは次のとおりです。

  • パブリック フェデレーションとプライベート フェデレーション。 Conan は、各パッケージの独立したコピーを公開する個人に依存しています。 このアプローチは、さまざまな方法で壊れている多数のパッケージを奨励していると考えています。 Boost 1.56 の 20 以上のパブリック パッケージの一覧を選択して、特定の状況で動作する少数のパッケージを特定するのは、ユーザーの時間の無駄であると考えています。 対照的に、私たちは、多くの場合に機能し、ユーザーが自分のプライベートバージョンで自由にハッキングできるようにする、単一の、共同でメイン包含バージョンが存在する必要があると考えています。 これは、お互いに頻繁にテストされ、必要なプライベートな変更のための素晴らしい基盤を形成する高品質のパッケージのセットになると信じています。

  • dll ごととアプリケーションごと。 依存関係がライブラリ レベルで個別にバージョン管理されている場合は、すべてのビルド環境が完全に一意であり、堅牢でテストされたエコシステムを利用したり、貢献したりすることができないことが推奨されます。 これに対し、すべてのライブラリをプラットフォーム (システム パッケージ マネージャーと同様) として一緒にバージョン管理することで、エコシステムの品質と安定性を最大化するために、非常に一般的なライブラリ バージョンのセットに対するテストと作業をまとめたいと考えています。 これはまた、ライブラリがアプリケーションの選択肢と競合するバージョンを要求する機能を完全に設計しています(openssl Zとブースト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 を含む) を通じて提供できるように設計されています。