【速報】Vcpkg: Windowsの公式C++ライブラリ管理ツール

こんにちは、hachi8833です。

昨日のVisual C++ Team Blogで、Vcpkgというライブラリ管理ツールが公開されました。

Linuxのapt-get、yumやMacのHomebrewなどのパッケージ管理ツールを強く意識していますが、マイクロソフトが公式に運営する点が大きいと思います。

GitHubリポジトリも合わせて公開されていますので、そこにあるFAQの概要をご紹介します。いずれ公式のドキュメントが日本語化されると思いますので、詳しくはそちらをどうぞ。私が翻訳してよければやりますがw

VcpkgのFAQより抜粋

Vcpkgとは、C++で書かれたオープンソースライブラリをWindows上で入手・リビルドするツールです。

誰でも貢献できる

ガイドライン(英語)に従って、誰でも自分のライブラリをアップするなどして貢献できるとのことです。たぶん貢献をすっごく期待していると思うので、何かすれば大歓迎してもらえるのかも。

つかここでマイクロソフトがリクエストに対してどれだけいい感じに応答できるかでエコシステムの成長が決まるんではないかと。

バイナリパッケージの配付は?

プレビューリリースの時点では、バイナリパッケージの配付はサポートせず、公式の安定版バイナリフォーマットの指定もまだないようです。このあたりは今後に期待ですね。

ローカルでのライブラリ更新方法

vcpkg updateコマンドで、portfileと同期していないパッケージを確認できます。GitHubのvcpkgディレクトリをcloneしgit pullでportfileのリストを更新するのがおすすめです。

自分のプライベートライブラリのビルド

非公開のライブラリもビルドできるようです。

こちらの例に沿って準備したうえで、作成したプライベートソースのzipファイルを downloads\ フォルダに置いてpre-seedするか、通常の vcpkg_download_distfilevcpkg_extract_source_archiveを自分のソース コードをunpackする関数で置き換えればよいとのこと。

プライベートライブラリは事前ビルドも可能です。その場合は、必要なヘッダファイルやバイナリファイルをダウンロードして ${CURRENT_PACKAGES_DIR}に配置するスクリプトをportfile.cmakeに書きます。

事前ビルド済みバイナリを企業内で配布するのであれば、ライブラリをビルドしてから、Vcpkgのルートディレクトリを社内のプロジェクトメンバー全員に配付または共有するのがおすすめです。

対象プラットフォーム

現時点では、Universal Windows Platform(x86、x64、ARM)と、Windowsデスクトップ(x86、x64)が 対象です。 vcpkg help tripletコマンドで最新のリストをいつでも確認できます。

LinuxやMac OS Xなどでもvcpkg.exeを使ってみたいという要望があればGithubのIssuesで知らせて欲しいとあります。Issueを見てみると、早くもFFMPEGやOGREなどライブラリの追加リクエストが集まっているようです。

サポートされるツールセットはVisual Studio 2015以降のみです。

異なるバージョンのライブラリの共存について

Vcpkgのシングルインスタンス(installed\packages\ports\などのいずれか)内に配置できるライブラリのバージョンは1つだけだそうです。

異なるバージョンのライブラリを共存させるには、Vcpkgの別インスタンスを作成してプロジェクトごとの統合メカニズムを利用するのがおすすめです。ports\内のファイルで各ライブラリのバージョンを指定できるので、Gitなどのバージョンコントロールシステムでバージョンを指定でき、ロールバックも簡単にできるようになります。

ライブラリのバージョン指定が厳しいアプリでは、必要なportfileセットをバージョン管理下に置いて、--vcpkg-rootでvcpkg.exeのワーキングディレクトリにリダイレクトするのがおすすめです。

CMake toolchainファイルとの共存

Vcpkgのtoolchainファイルと、既存のCMake toolchainファイルは共存できます。include(\scripts\buildsystems\vcpkg.cmake)ディレクティブを使うか、既存のCMake toolchainファイルにscripts\buildsystems\vcpkg.cmakeの内容をコピーします。

VcpkgではCMakeをビルドのスクリプト用言語として採用しています。開発者が新しい言語を覚えずに済むよう、C++開発者におなじみのCMakeにしたとのことです。「Go言語のテストはGo言語で書く」というポリシーを連想しますね。

NuGetにしなかった理由

NuGetは.NETライブラリ向けのパッケージマネージャで、MSBuildに強く依存しています。また、コンパイルオプションが複雑になる、小規模のビルド済みライブラリの配付向けに設計されている、マネージドでない言語ではABIが不安定になるといった理由から、NuGetは採用されなかったようです。

Conan.ioにしなかった理由

Conan.ioはPythonベースの新しいC++パッケージマネージャです。運営がオープンである代わりに同じようなライブラリがいくつもアップされていてライブラリの選定に時間がかかりすぎるという理由で、運営がプライベートである分テストやメンテナンスが一元化されていて品質を担保しやすく、ライブラリが競合した場合などのリクエストもしやすいVcpkgの優位性を強調しています。

ただし、Vcpkgは決してオープンソースに敵対するものではなく、aptやhomebrewと並ぶ「もう一つの選択肢」を目指すことも強調されています。

最後に

PowerShellのオープンソース化など、近年オープンソースへの貢献にかなり熱心になってきているマイクロソフトですが、今回のVcpkgも参加への障壁をできるだけ下げたりオープンソース陣営から反感を買わないよう配慮するなど、マイクロソフトの本気度を感じさせる動きであると思えました。エコシステムが成長するかどうかは文字どおり水ものなので先のことはわかりませんが、今後の動向を見守りたいと思います。

個人的には、VBAコードについてもこうしたパッケージ管理のエコシステムを公式にサポートすれば、むしろそっちの方がすごくウケるのではないかと思いますが、いかがでしょうかw オープンソースだと責任取らされるのが怖くてパッケージ取ってこれない官公庁大企業の方とか、公式の消毒済みVBAライブラリが選び放題になったら争ってダウンロードしそうです。

社内の声

160920_1757_7yheas

関連記事

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833

コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。
これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。
かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。
実は最近Go言語が好き。
仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

BigBinary記事より

ActiveSupport探訪シリーズ