次の方法で共有

よく寄せられる質問

  • [アーティクル]

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

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

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

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

はい。 まず、コントリビューション ガイドラインを読んでください。 詳細については、 Maintainer ガイド もご覧ください。 vcpkg にポートを追加するための tutorial も用意されています 作業を開始するのに役立ちます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この例を確認するには、Windows SDK からファイルをコピーする ports\opengl\portfile.cmake を参照してください。

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

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

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

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

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

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

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 でこれらの設定をはるかに高く追加する必要があります。 $(VcpkgConfiguration) マクロを "Globals" PropertyGroup に追加することをお勧めします。

たとえば、プロジェクト ファイルに追加することで、"MyRelease" 構成のサポートを追加できます。

<PropertyGroup Label="Globals">
  ...
  <VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>

もちろん、これは、カスタム構成がターゲット構成と互換性がある場合にのみ実行可能なバイナリを生成します (たとえば、両方とも同じランタイム ライブラリにリンクする必要があります)。

ユーザー全体の統合を使用できません。 プロジェクトごとの統合を使用できますか?

はい。 プロジェクトごとの使用に適した NuGet パッケージは、 vcpkg integrate project コマンド (ライトウェイト リンク) または vcpkg export --nuget コマンド (shrinkwrapped) を使用して生成できます。

vcpkg integrate project NuGet パッケージと同じを実現するための下位レベルのメカニズムは、<vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets ファイルを介して行われます。 必要なのは、.vcxproj ファイルにインポートするだけで、 <vcpkg_root> を vcpkg をインストールしたパスに置き換えます。

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

サポートされている 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 のためのもう1つのライン)と世界に統合することを可能な限り簡単にすることを選択しました。

  • C++/CMake と python。 Python は多くの人に愛されている優れた言語ですが、パッケージ マネージャーとしてワークフローにとって重要なツールを選択する際には、透明性と知識が最も重要な要素であると考えています。 そのため、実装言語を可能な限り広く受け入れるようにすることを選択しました。C++ は C++ プログラマ向けの C++ パッケージ マネージャーで使用する必要があります。 パッケージ マネージャーを理解するためだけに、別のプログラミング言語を学習する必要はありません。

なぜチョコレートではないのですか?

Chocolatey は、アプリケーションを管理するための優れたシステムです。 ただし、現時点では、再頒布可能な開発者資産を取得し、デバッグを支援するようには設計されていません。 これに対して vcpkg は、アプリケーションをビルドするために必要なライブラリを取得し、必要なプラットフォーム (Chocolatey を含む) を通じて提供できるように設計されています。