C++ Advent Calendar 2025 12日目の記事です。
C++ のプロジェクトでライブラリを導入するのは、 Rust や Python などのエコシステムに比べて、やはり面倒だし煩雑なものです。
本稿では、 Microsoft 発のライブラリマネージャーである vcpkg を紹介します。
先日試しに使ってみて、実際に手間を減らしてくれました。
実行環境
今回のビルド・実行環境は以下です。
- Windows 11
- Visual Studio 2026 Insiders コンパイラ
- CMake 4.2.0
なお、 vcpkg は Mac および Linux でも動作するようです。
やってみること
OpenCV を導入してサンプル画像を読み込み、ウィンドウに表示する。
ただし、 vcpkg のマニフェストモードを使用する。
vcpkg には2種類の動作、
マニフェストモード(プロジェクト個別にライブラリを導入する)と
クラシックモード (プロジェクトの境目なくライブラリを導入する)があります。
Microsoft によって、マニフェストモードが推奨されています。
https://learn.microsoft.com/ja-jp/vcpkg/consume/classic-mode
手順と実行記録
vcpkg の準備
チュートリアル: CMake でパッケージをインストールして使用する を参照して行います。
セットアップスクリプトを実行します。
$ git clone https://github.com/microsoft/vcpkg.git
$ cd vcpkg
$ .\bootstrap-vcpkg.bat
Downloading https://github.com/microsoft/vcpkg-tool/releases/download/2025-11-19/vcpkg.exe -> D:\files\repo\vcpkg\vcpkg.exe... done.
Validating signature... done.
vcpkg package management program version 2025-11-19-da1f056dc0775ac651bea7e3fbbf4066146a55f3
実行バイナリが配置されました。
環境変数(VCPKG_ROOT, PATH)を編集します。
シェルを再起動することで、 vcpkg コマンドが使えるようになります。
プロジェクトとマニフェストの準備
空の git リポジトリで、ソースファイルを記述します。
#include <opencv2/opencv.hpp>
int main() {
const auto image = cv::imread("image.jpg");
cv::imshow("window", image);
cv::waitKey(0);
return 0;
}
次に、 vcpkg マニフェストファイルを生成します。
$ vcpkg new --application
これらのファイルはともに、バージョン管理・共有することが推奨され ます。
依存ライブラリとして OpenCV を追加します。
$ vcpkg add port opencv
Succeeded in adding ports to vcpkg.json file.
なお、使用可能なライブラリは vcpkg search opencv のように検索したり、 vcpkg のリポジトリの ports ディレクトリ を見ることでも探せます。
CMake でのビルド
CMake でのビルドに vcpkg のライブラリを反映させるために、
vcpkg が提供する toolchain ファイルを使用します。
CMake 3.19 以降、 configure 時の変数などをファイルから読み込める cmake-presets という機能があるので、これを使って toolchain ファイルを指定します。
{
"version": 10,
"configurePresets": [
{
"name": "vcpkg",
"generator": "Visual Studio 18 2026",
"binaryDir": "${sourceDir}/build",
"cacheVariables": {
"CMAKE_TOOLCHAIN_FILE": "$env{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake"
}
}
]
}
Microsoft のチュートリアルでは generator に Ninja を指定していますが、暗黙に使ってしまっている依存先なので、ここでは Visual Studio 18 2026 としました。
また Microsoft のチュートリアルでは CMakeUserPresets.json も作成していますが、 VCPKG_ROOT 環境変数はすでに設定されているため、不要です。
ビルド関連ファイルの準備ができたので、実際に configure します。 JSON ファイルに書いたプリセットの name を指定します。
$ cmake --preset vcpkg
-- Running vcpkg install
Fetching registry information from https://github.com/microsoft/vcpkg (HEAD)...
(省略)
All requested installations completed successfully in: 478 ms
-- Running vcpkg install - done
初回にこれを行うと、ライブラリのソース取得・ビルドが次々と行われ、 CPU 使用率が高い状態で 10 分程度待たされました。
2回目以降はキャッシュが効くので、早めに一度実行しておくのがよいでしょう。
このコマンドを打ち込む代わりに、 Visual Studio Code の CMake Tools 拡張機能を使うのも便利です。 プリセット名が認識されます:
configure が完了したので、ビルドします。
$ cmake --build build
MSBuild のバージョン 18.1.1-preview-25556-03+4e139ce80 (.NET Framework)
1>Checking Build System
Building Custom Rule D:/files/repo/show_image/CMakeLists.txt
show_image.cpp
show_image.vcxproj -> D:\files\repo\show_image\build\Debug\show_image.exe
Building Custom Rule D:/files/repo/show_image/CMakeLists.txt
実行します。
$ ./build/Debug/show_image.exe
無事に画像が表示されました。
観察
CMake のビルドディレクトリの中には、 vcpkg によってヘッダやライブラリが
include や lib にまとめられていました。
ライブラリごとに個別のインクルードディレクトリがあるわけではないので、 target_include_directories を使って指定する必要がなかったのです。
vcpkg_installed は vcpkg が保管しているキャッシュのコピーでしかなく、
2回目以降使う際はダウンロードやビルドが不要になり、 configure はすぐに完了します。
ところで packages の中では、ディレクトリにバージョン名がついていませんが、プロジェクトによって異なるバージョンが要求されたらどうなるのでしょうね...?
使っていきたい
git submodule でライブラリを置いてビルドは独自に行うとか、バイナリをシステムに入れるといった
C++ でのライブラリ導入の煩わしさをまったく感じず、あっという間に OpenCV を利用することができました。
マニフェストファイルというのも Python の pyproject.toml のように、状態の不整合が起きにくい思想で好ましいと思います。
また、 CMake を使っていない場合でも vcpkg install をすると vcpkg_installed 以下に include, lib, ... が配置され、
そこを指定することで、どのビルドシステムでも対応できるような ので、
vcpkg の導入が後の負債になる可能性も低いでしょう。
ただ、ライブラリのビルドが直列で大変時間がかかるので、並列化されることを望みます(コントリビューションチャンス?)。
おまけ: Linux
WSL Ubuntu-24.04 で同じものを実行してみます。
必要だったパッケージは以下です。
$ sudo apt install build-essential git pkg-config ninja-build cmake
CMakePresets の generator を "Unix Makefiles" や "Ninja" に変更します。
Ubuntu-24.04 の apt で入る CMake のバージョンは 3.28 なのですが、
vcpkg を実行すると自動的に 3.30.1 を取得して代わりに使っているようでした。ここは良い設計ですね。
Linux の場合はすべての依存ライブラリたちが vcpkg によって満たされるわけではなく、
途中ビルドエラーが起きて 「 bison を入れてね」 「 autoconf も入れて」 などと次々言われることがありました。
ひとつひとつ躓くので、トライアルアンドエラーが必要な面はだいぶ不便です。 5回以上やりなおしました。
Linux にも環境を共有する場合は、これら後から必要になったライブラリを README.md などに書いておく運用を合わせるか、 devcontainer の Dockerfile でのセットアップが必須になるでしょう。
無事(無事ではない)にビルド・実行できました。








