こんにちは、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ライブラリが選び放題になったら争ってダウンロードしそうです。
社内の声
関連記事
- error: reference to ‘random_access_iterator_tag’ is ambiguous
- Qt Quick2でMouseAreaの外のイベントもハンドリング
- BPSスタッフインタビュー#1：田島誠也（2016卒新卒アプリエンジニア）