C++ のパッケージマネージャーの選択メモ( conan vs. vcpkg vs. Hunter on Windows and Ubuntu ): C++ 実装がサブプロジェクトとして内包されるクロスプラットフォームアプリのリポジトリーの場合

タイトルが少しややこしいので最初に整理します。

このメモは: C++ のパッケージマネージャーの選択のはなし
ただし:
- アプリはクロスプラットフォーム ( このメモでの具体例は Windows-10 & Ubuntu-19.04 )
- アプリ全体(=このメモでは「ソリューション」とします)はいくつかの構成部品(=このメモでは「プロジェクト」とします)に分けて作られる
- プロジェクトの1つ以上に C++ を採用したい
  - そのプロジェクト単位で C++ のライブラリーを管理できるパッケージマネージャーを導入したい → どうするのが楽そうかな

のメモです。

選択肢と大雑把な検討

conan https://conan.io/
- クロスプラットフォーム対応の C++ のパッケージマネージャーが欲しいの悩みに答えてくれる定番。 CMake でごにょごにょする
vcpkg https://github.com/microsoft/vcpkg
- Microsoft が Windows 向けの Visual Studio のために作ったパッケージマネージャー「だった」。今では GNU/Linux と OSX も対象プラットフォームという事になっている
Hunter https://github.com/cpp-pm/hunter
- conan よりキレイに CMake でごにょごにょしてくれるらしいクロスプラットフォーム対応の C++ パッケージマネージャー
(最終手段) ライブラリーごとに手書きの CMake 魔術を作りプロジェクトの CMakeLists.txt へ仕込む https://cmake.org/cmake/help/latest/
- これを選択すると保守の手間が増えるので 1, 2, 3 の何れかにしたい

対応パッケージの手広さ対決

登録パッケージ数を比べてもあんまり意味が無いので、実際に私がソフトウェア開発プロジェクトで触れる機会、可能性のあるライブラリーやフレームワークを適当に列挙して、実際にコマンドで search を叩く、最新のリストから grep しつつ、ついでにライセンスとオリジナルの入手情報も整理しました。パッケージ名に気を付けると良さそうな場合は有無の〇×の〇代わりにパッケージ名を記載しました。

要注意 この表は 2019年12月29日の調査結果です。

category	name	LICENSE	conan	vcpkg	Hunter	original
3D-data, Format	Assimp	BSD-3-Clause	×	〇	〇	https://github.com/assimp/assimp
All-purpose	Boost 1.0	Boost 1.0	〇	〇	〇	https://github.com/Boost 1.0org/Boost 1.0
Civil-engineering	OSGeo/PROJ	MIT	×	proj4	PROJ4	https://github.com/OSGeo/PROJ
Civil-engineering, Image, Format	OSGeo/libgeotiff	public domain	×	〇	×	https://github.com/OSGeo/libgeotiff
Compression	zlib	zlib/libpng	〇	〇	〇	https://www.zlib.net/
Compression	zstd	BSD \| GPLv2	〇	〇	×	https://facebook.github.io/zstd/
Compression	liblzma	public domain	〇	〇	lzma	https://tukaani.org/xz/
Compression	Snappy	Apache 2.0	〇	〇	〇	https://google.github.io/snappy/
Compression	LZ4	BSD-2-Clause	〇	〇	〇	https://github.com/lz4/lz4
Concurrency	OpenCL	Khronos OpenCL	〇	〇	〇	https://github.com/KhronosGroup/OpenCL-Headers
Concurrency	OpenCL-cpp	Khronos OpenCL	khronos-opencl-clhpp	×	〇	https://github.com/KhronosGroup/libclcxx
Concurrency	TBB	Apache 2.0	〇	〇	×	https://github.com/intel/tbb
Crypto	CryptoPP	Boost 1.0	〇	〇	〇	https://github.com/weidai11/cryptopp
Database	SQLite3	public domain	〇	〇	〇	https://sqlite.org/src/timeline
Database	sqlitecpp	MIT	〇	〇	×	https://github.com/SRombauts/SQLiteCpp
Image, Computer-visioning	OpenCV	BSD-3-Clause	〇	〇	〇	https://github.com/opencv/opencv
Image, Computer-visioning	OpenMVG	MPL 2.0	×	〇	×	https://github.com/openMVG/openMVG
Image, Computer-visioning	OpenMVS	AGPL	×	〇	×	https://github.com/cdcseacave/openMVS
Image, Font, Format(*)	stb	public domain	〇	〇	〇	https://github.com/nothings/stb
Image, Format	libtiff	BSD-like	〇	tiff	tiff	http://www.simplesystems.org/libtiff/
Image, Format, JPEG	libjpeg	BSD-like	〇	〇	jpeg	http://libjpeg.sourceforge.net/
Image, Format, PNG	libpng	zlib/libpng	〇	〇	png	https://libpng.sourceforge.io/
Image, Format, WebP	WebP	BSD	〇	〇	〇	https://developers.google.com/speed/webp/
Linear-algebra, Math	Eigen	MPL 2.0	〇	〇	〇	http://eigen.tuxfamily.org/
Networking	curl	MIT	〇	〇	〇	https://github.com/curl/curl
Networking	curlpp	MIT	×	〇	×	https://github.com/jpbarrette/curlpp
Networking	BoringSSL	OpenSSL	×	×	〇	https://boringssl.googlesource.com/boringssl/
Networking	OpenSSL	Apache-style	〇	〇	〇	https://www.openssl.org/
Networking	Crow	BSD-3-Clause	×	〇	×	https://github.com/ipkn/crow
Networking, RPC, gRPC	gRPC	Apache 2.0	×	〇	〇	https://github.com/grpc/grpc/tree/master/src/cpp
OpenGL	OpenGL Registry	Khronos OpenGL	×	opengl-registry	×	https://github.com/KhronosGroup/OpenGL-Registry
OpenGL	GLFW	zlib/libpng	〇	glfw3	〇	https://github.com/glfw/glfw
OpenGL, GUI	imgui	MIT	〇	〇	〇	https://github.com/ocornut/imgui
OpenGL, Math	glm	Happy Bunny	〇	〇	〇	https://glm.g-truc.net/
OpenGL, Windows	glew	BSD-3-Clause	〇	〇	〇	https://github.com/nigels-com/glew
OpenGL, Windows, Direct3D	ANGLE	BSD-3-Clause	×	〇	×	http://angleproject.org/
Script, Javascript	V8	BSD-3-Clause	×	×	〇	https://v8.dev/
Script, Lua	Lua	MIT	×	〇	〇	https://github.com/lua/lua
Serialization	cereal	BSD-3-Clause	〇	〇	〇	https://github.com/USCiLab/cereal
Serialization, CSV	csv-parser-plusplus	GPLv3	×	×	〇	https://github.com/headupinclouds/csv-parser-cplusplus
Serialization, CSV	fast-cpp-csv-parser	BSD-3-Clause	×	〇	×	https://github.com/ben-strasser/fast-cpp-csv-parser
Serialization, JSON	RapidJSON	BSD-3-Clause	〇	〇	〇	https://github.com/Tencent/rapidjson/
Serialization, JSON, BSON	json	MIT	nlohmann_json	nlohmann-json	nlohmann_json	https://github.com/nlohmann/json
Serialization, MessagePack	msgpack	Boost 1.0	〇	〇	〇	https://github.com/msgpack/msgpack-c
Serialization, XML	RapidXML	Boost 1.0	〇	〇	〇	http://rapidxml.sourceforge.net/
Serialization, XML	Xerces	Apache 2.0	〇	〇	×	http://xerces.apache.org/xerces-c/
Unit-test	Catch	Boost 1.0	〇	〇	〇	https://github.com/catchorg/Catch2
Image, Computer-visioning	pcl	BSD-3-Clause	×	〇	×	https://github.com/PointCloudLibrary/pcl
Image, Computer-visioning	OpenNI2	Apache 2.0	×	〇	×	https://github.com/occipital/openni2
Concurrency, GPGPU	CUDA	GPLv2 and etc.	×	〇	×	https://developer.nvidia.com/cuda-zone

この調査結果からは、私の中では意外な事に vcpkg がとても有用そうな事がわかりました。少なくとも Windows で cl.exe 系のツールチェインを使う場合には vcpkg が期待動作しない事も少ないでしょうから、クロスプラットフォーム対応ではなく Windows だけを対象にする場合は vcpkg 一択で良さそうです。

vcpkg の懸念は Windows 以外でも期待動作してくれるのか…です。これは実際に試してみないと安心できません。

お試し

このメモでは...

Eigen http://eigen.tuxfamily.org/ と
- // header only
Message Pack (msgpack-c) https://github.com/msgpack/msgpack-c を
- // build required

conan, vcpkg, Hunter で取り込んでみます。

翻訳するソース my_something.cpp は...

#include <Eigen/Core>
#include <msgpack.hpp>
#include <fstream>

extern "C" double my_norm( double x, double y, double z )
{
  return ::Eigen::Vector3d{ x, y, z };
}

extern "C" void my_serialize( const std::string& path, double value )
{
  ::msgpack::sbuffer b;
  ::msgpack::pack( b, value );
  ::std::oftream( path, ::std::ios::binary ).write( b.data(), b.size() );
}

無事に build.cmake/lib/libmy_something.so を作れた場合は、 python と od (Ubuntuなどの場合) または Format-Hex (Windows/PowerShellの場合) で簡易動作確認します:

>>> from ctypes import *
>>> l = cdll.LoadLibrary( 'lib/libmy_something.so' )
>>> l.my_norm.restype = c_double
>>> l.my_norm( c_double( 1 ), c_double( 2 ), c_double( 3 ) )
3.7416573867739413
>>> l.my_serialize( c_char_p( 'out'.encode( 'utf-8' ) ), c_double( l.my_norm( c_double(1), c_double(2), c_double(3) ) ) )
0
(CTRL+D)

od -tx1z -Ax out または Format-Hex -Path out で out を確認

000000 cb 40 0d ee ea 11 68 3f 49                       >.@....h?I<
000009

Notes:

3次元ベクター { 1, 2, 3 } のノルムは 3.74165738677... くらいのスカラーです。 https://www.google.com/search?q=sqrt(1*1%2B2*2%2B3*3)
msgpack の double 値のシリアライズ結果は 0xcb で始まり IEEE754/Binary64 の Big-endian 形式になります。 https://github.com/msgpack/msgpack/blob/master/spec.md#float-format-family

conan

導入方法

python と pip を使える状態にする
pip install conan

プロジェクトへのパッケージ追加方法

パッケージを探す:
1. conan search "*eigen*" --remote=conan-center
2. conan search "*msgpack*" --remote=conan-center
3. コツ: 検索キーワードは小文字にし、ありそうな名称の前後に * を付けてワイルドカード付きで検索すると見つけやすいです
4. 動作はわりともっさりですが、数秒待っていれば動きます
パッケージを確認:
1. conan inspect eigen/3.3.7
2. conan inspect msgpack/3.2.0@bincrafters/stable
パッケージを使用可能な状態にする:
1. プロジェクト内のパッケージの定義ファイルを作る: conanfile.txt (†1)
2. パッケージのビルドディレクトリーを作って入る: mkdir build.conan && pushd build.conan
3. 導入: conan install .. && popd; .. は conanfile.txt のある場所
  - conanfile.txt へライブラリーを追加する事があれば conan install の再実行も必要
  - Windows, Ubuntu あたりの一般的なツールチェインはバイナリーが降ってくるのですぐ終わります
プロジェクトに CMake プロジェクトファイルを用意して conan のパッケージを使用してビルド:
1. CMakeLists.txt を用意して conan 用の追記...
  1. include(${PROJECT_SOURCE_DIR}/conan.build/conanbuildinfo.cmake)
  2. conan_basic_setup()
  3. target_link_libraries( my_project ${CONAN_LIBS} )
2. mkdir build.cmake && pushd build.cmake
3. cmake ..
4. cmake --build .

(†1) ↓ conanfile.txt; パッケージ名は大文字小文字に敏感です

[requires]
eigen/3.3.7
msgpack/3.2.0@bincrafters/stable

[generators]
cmake

パッケージの実体

~/.conan ディレクトリー内にパッケージごとに実体が conan install .. で必要になる度に導入が確認され格納される
- プロジェクト内にはパッケージはソース、バイナリー何れも配置されず、 cmake から↑が参照される
- パッケージの管理単位にバージョン情報なども内包しているので、複数プロジェクトでパッケージが混乱する事は無さそう(たぶん)

vcpkg

導入方法

git clone https://github.com/Microsoft/vcpkg.git
- または git subtree, git submodule で取り込む
pushd vcpkg
vcpkg の実行ファイルをビルド; 数分程度かかるかもしれません
- GNU/Linux っぽい環境: ./bootstrap-vcpkg.sh
- Windows っぽい環境: ./bootstrap-vcpkg.bat
ビルドツールへの仕込み; しなくてもいいけど、すると便利かもしれないし、厄介事の原因になるかもしれないのでプロジェクトにあわせてどうぞ
- CMake: cmake 叩く段階で -D すればいいのでこの段階では何もしなくてOK
- Visual Studio: ./vcpkg integrate project または ./vcpkg integrate install https://docs.microsoft.com/en-us/cpp/build/vcpkg?view=vs-2019#integrate-with-visual-studio-windows
- その他: 必要に応じて vcpkg 導入先の installed, packages あたりを眺めれば手インテグレートできそう
popd

プロジェクトへのパッケージ追加方法

Note: vcpkg をどこに置くかによらずパスを通したり alias を張ったりする場合は vcpkg/vcpkg とパス付きで呼ぶ必要はないのですが、今回はプロジェクト単位でライブラリー管理時にしか使わないので、パス付きで呼んで済ませます。

パッケージを探す:
1. vcpkg/vcpkg search eigen -> eigen3 3.3.7-3 C++ template library for linear algebra: matrices, vectors, numerical solvers,...
2. vcpkg/vcpkg search msgpack -> msgpack 3.2.0-1 MessagePack is an efficient binary serialization format, which lets you exchan...
バージョンの固定が必要なら ports ディレクトリーの中身を適当に編集して対処します
- 不要な場合は何もせず↓へ
パッケージを導入:
1. vcpkg/vcpkg install eigen3 終了時に CMake 用の情報を教えてくれます(†1)
2. vcpkg/vcpkg install msgpack 終了時に CMake 用の情報を教えてくれます(†2)
CMakeLists.txt にライブラリーを追加; ↑で教えてくれる例をもとにプロジェクト名を main から実際の my_something へ変えて追加
1. find_package( Eigen3 CONFIG REQUIRED )
2. find_package( msgpack CONFIG REQUIRED )
3. target_link_libraries( my_something PRIVATE Eigen3::Eigen msgpackc msgpackc-cxx msgpackc-static)
ビルド:
1. mkdir build
2. cd build
3. cmake .. -DCMAKE_TOOLCHAIN_FILE=../vcpkg/scripts/buildsystems/vcpkg.cmake
  - CMake Error ... "msgpackc-static" is imported but not globally visible とか出たら
    - vcpkg/installed/ { x64-linux などのプラットフォーム名 } /share/msgpack/msgpack-targets.cmake の
    - add_library(msgpackc-static ... に GLOBAL を追記する修正が一時的に必要かもしれません
    - https://github.com/microsoft/vcpkg/issues/7205
4. cmake --build .

(†1): ↓ ./vcpkg install eigen3 の終わりに表示される CMake ではこうしてね情報:

    find_package(Eigen3 CONFIG REQUIRED)
    target_link_libraries(main PRIVATE Eigen3::Eigen)

(†2): ↓ ./vcpkg install msgpack の終わりに表示される CMake ではこうしてね情報:

    find_package(msgpack CONFIG REQUIRED)
    target_link_libraries(main PRIVATE msgpackc msgpackc-cxx msgpackc-static)

パッケージの実体

vcpkg 導入先の buildtrees, installed, packages にそれぞれソースやビルドされたライブラリーが放り込まれます
- 良くも悪くも強引ですが、場所を変更する手段はいまのところは実質的に存在しないので、必要な場合は vcpkg の導入自体を単位として扱います https://docs.microsoft.com/en-us/cpp/build/vcpkg?view=vs-2019#per-project

Hunter

導入方法

Hunter をプロジェクト単位で使うための HUNTER_ROOT 用のディレクトリーを作成:
- mkdir hunter_root (†2)
HunterGate をプロジェクトへ仕込む https://cpp-pm-hunter.readthedocs.io/en/latest/quick-start.html
1. mkdir cmake
2. HunterGate.cmake をダウンロードして配置
  - wget を使う場合: wget https://raw.githubusercontent.com/hunter-packages/gate/master/cmake/HunterGate.cmake -O cmake/HunterGate.cmake
  - PowerShell を使う場合: Invoke-WebRequest -Uri https://raw.githubusercontent.com/hunter-packages/gate/master/cmake/HunterGate.cmake -OutFile cmake/HunterGate.cmake
CMakeLists.txt の project よりも前に Hunter を仕込む... (†1)
1. set( ENV{HUNTER_ROOT} "${CMAKE_CURRENT_SOURCE_DIR}/hunter_root" ) (†2)
2. include( "cmake/HunterGate.cmake" )
3. HunterGate( URL "https://github.com/cpp-pm/hunter/archive/v0.23.240.tar.gz" SHA1 "ca19f3769e6c80cfdd19d8b12ba5102c27b074e0" )
  - 基本的に最新リリースを確認して設定するといいはず: https://github.com/cpp-pm/hunter/releases

(†1): この仕様のため、 Hunter は add_subdirectory されるサブプロジェクト単位で使用したい場合に少し厄介です。サブディレクトリー単位で独立した CMake を呼ぶトリックを仕込むか、諦めてルートになるプロジェクトの project よりも前に Hunter を仕込むか、状況によっては悩ましい対応が必要になるかもしれません。

(†2): ~/.hunter_root や %HOMEPATH%/.hunter_root を用意して、 .bashrc や Windows の環境変数設定で HUNTER_ROOT をその場所へ設定しておくと conan のように合理的なパッケージ実体の管理方法になります。このメモの方法はプロジェクト単位の中へ Hunter のパッケージ管理と本体も押し込めたい場合の簡単なトリックの例です。

プロジェクトへのパッケージ追加方法

パッケージを探す... https://cpp-pm-hunter.readthedocs.io/en/latest/packages.html
1. Eigen https://cpp-pm-hunter.readthedocs.io/en/latest/packages/pkg/Eigen.html
2. msgpack https://cpp-pm-hunter.readthedocs.io/en/latest/packages/pkg/msgpack.html
CMakeLists.txt にライブラリーを追加
1. hunter_add_package( Eigen )
2. hunter_add_package( msgpack )
3. find_package( Eigen3 CONFIG REQUIRED )
4. find_package( msgpack CONFIG REQUIRED )
ビルド
1. mkdir build.cmake && pushd build.cmake
2. cmake ..
  - Hunter のパッケージビルドがここで行われるので容赦なくかなりながい時間がここでかかります
    - 妙に長いので🍵ブレイク後に見たら Eigen, msgpack のほか OpenSSL, ZLIB もフルビルドされていました...
3. cmake --build .

パッケージの実体

CMake から HunterGate が実行された際の HUNTER_ROOT 環境変数のディレクトリー内へ、ダウンロード、ビルドされる
- メタ情報の管理も細かくされていて、パッケージバージョンが混乱したりする心配は無さそう
conan のようにパッケージの実体はプロジェクトを超えて合理的に共有したい場合は適当な共有用のディレクトリーを設け、 HUNTER_ROOT 環境変数をプロジェクトの外で設定すればOK

現時点での感想

Windows と Ubuntu 程度の軽いクロスプラットフォーム対応性
- 現時点では conan, vcpkg, Hunter どれでも問題になる事の方が少なさそう
  - vcpkg の msgpack では手修正が必要な問題が発生しましたが、エラーメッセージを読めば対応できる程度なのでまあ…どうだろう…プロジェクトの開発者が初心者だらけだったら…厳しいかもしれませんね…
ライブラリーの対応の幅広さ、抜け目の無さ
1. 現時点での一般論としては vcpkg が他に比べて少し有能そう; OSGeo/PROJ, OpenMVG, curppp など
2. conan, Hunter も一般性の高いパッケージに困る事はおおよそない; zlib, libjpeg, boost など
パッケージ検索のし易さ
1. vcpkg が理想的かもしれません。
  - vcpkg search の動作がわりと軽快
  - 導入先の ports ディレクトリーを眺めるだけでも探せる
2. conan search は pip のようなもっさり感はあるものの(中身はpythonだしね...)、実用十分には探せる＆耐えられる
3. Hunter はコマンド式のインターフェースは無く、"読み物"から探すのは地味にだるいです...
プロジェクト単位での使いやすさ
1. conan がとても合理的; 実体はバージョンごと共有管理するけれど使用はプロジェクト単位で特定バージョンを引っ張れる
  - しばしば conan は CMake の使い方が邪悪と言われるけれど、そもそも CMake のパッケージ管理のゆるふわ感を考えるとどうでもいいかな、むしろこういうまとめ方もユーザーには便利でいいかもーくらいにゆるっと思う程度です
2. vcpkg はプロジェクト単位での使用方法が極めて強引ですが、プロジェクトで採用する補助ツールを git subtree / git submodule などで取り込みやすい場合には寧ろ好都合かもしれません
  - 強引なものの、結果的には、パッケージの実体と vcpkg そのものを完全にプロジェクト単位の中だけで固有に管理しやすいので、ポータビリティーを考えると悪くないかもしれません
3. Hunter は CMake 的に複雑なソリューションの中のサブプロジェクトとしては工夫しないと採用できない点が地味にめんどくさいかも; add_subdirectory の先に配置したい場合に少し厄介
  - しばしば conan との比較で CMake が綺麗と言われているように、実際、キレイです。キレイです…が、 conan を使った後だと CMake の記述量が少しですが多い点をだるく感じてしまうかもしれません
  - このメモに残したちょっとしたトリック程度で比較的簡単にパッケージの実体と Hunter の本体をまるごとプロジェクト単位の中に埋められるので、ポータビリティー的には vcpkg と同等の強さがあります
時間
1. conan はビルド済みのバイナリーも提供してくれるので一般的な用途では便利
2. vcpkg, Hunter は基本的にソースからビルドなので重いライブラリーを引っ張るとビルドに時間がかかります

C++ ときどきごはん、わりとてぃーぶれいく☆

USAGI.NETWORKのなかのひとのブログ。主にC++。

C++ のパッケージマネージャーの選択メモ( conan vs. vcpkg vs. Hunter on Windows and Ubuntu ): C++ 実装がサブプロジェクトとして内包されるクロスプラットフォームアプリのリポジトリーの場合

選択肢と大雑把な検討

対応パッケージの手広さ対決

お試し

conan

導入方法

プロジェクトへのパッケージ追加方法

パッケージの実体

vcpkg

導入方法

プロジェクトへのパッケージ追加方法

パッケージの実体

Hunter

導入方法

プロジェクトへのパッケージ追加方法

パッケージの実体

現時点での感想