Golang tokyo #7 qtpm

Copyright © DeNA Co.,Ltd. All Rights Reserved.
C++ビルド支援ツール
qtpm
Golang.tokyo #7
2017/7/3
渋川よしき
DeNA Co., Ltd.

*
Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
社内GUIツール開発
● GUIのツール作りたくなることありますよね？
● マルチプラットフォーム（mac/win）の時に何を使うのか？
● C++: Qt / GTK
● C#: Xamarin, GTK#
● JavaScript: Electron
● Java: Swing
● ラッパー系はいろいろつらいので避けたい
● メンテされなくなることが多い
● 純正でも死屍累々（Qt JambiとかQt binding for QtScript Engineとか）
● デバッグが辛い（go-qmlも謎のsegvで辛かった）
● 結局下まわりを見ないといけないとか、ラッパーの品質問題とか
● 動的言語だと型が欲しくなる
● 以前、Qt/JSのJSX（DeNAの）ラッパーを作ったりしたけど、ある日無駄なことをして

*
Qtが安定している
● 歴史が長い（1990〜）し、安定している
● コード品質、後方互換性（4系から5系でもほとんど修正不要）
● OSネイティブのルック＆フィール
● メモリ消費量が今となっては激少ない（〜50MBとか）
● C++は型もあるし、C++11便利だし、内製ツールの規模ならビルドも早い
● WebKit/Chromiumベースのブラウザウィジェットもある
● QML / Qt Quick Controlは試したかったが、今回は学習の時間とか下調べの時間
とか、メリット、引き継ぎとか考えてやめた
● Qtは宣言型のJSONテンプレート+JSを使って開発するQt上の動的開発環境で
、モバイルを強く意識している
● 情報が少ない。QMLは旧ASCII MWで1冊。Qt Quick Controlは薄い本しかない
● 自分でやるにはいいけど・・・
● Qt Quick Control 2になってだいぶいろんなUI部品が増えたがテーブルとか、
ツリービューはなかった

*
C++でツールをさっと作るときの課題（1）
● 今時のパッケージマネージャ完備の言語と比べるといろいろつらい
● 良い感じの共通のパッケージマネージャ基盤がない
● OSを限定すれば各OSのもろもろに頼るのはできるが・・・
● そもそもライブラリごとにビルドシステムがばらばら
● configureスクリプトやらCMakeやらSconsやらNinjaやらXCodeやらVisual Studioの
ソリューションファイルやら何やら
● 前提となるフレームワークもばらばら
● ちょっぴりGlibとか使っているコードとかあったら、必要なライブラリも全部あつめ
て来ないといけない
● マルチプラットフォーム？なにそれ？なものも・・・
● 結局、必要なライブラリを全部内包しちゃっているプロジェクトが多い
● Googleプロダクツとかも・・・
● Go言語ならgo get一発なのに・・・

*
C++でツールをさっと作るときの課題（2）
● ビルドシステムがいろいろつらい
● QtでクロスプラットフォームだとQMakeかCMakeぐらいしかない
● QMakeはQt専用で、ライブラリがこの設定ファイルを内蔵している確率は
ゼロに近い
● CMakeが最近のデファクトだけど、文法とかいろいろ難しい
● Fizzbuzzとかズンドコきよしが書けるぐらい高度な言語
● やりたいこと→どう書けばいいか、の逆引きの分かりやすい解説が少ない

*
既存のパッケージ管理ソリューション（2014年〜）
● BiiCode
● 死んだ
● CPM
● CMakeベース
● clib
● C言語のパッケージマネージャ
● sbt
● ヘッダーファイルだけの過激なソリューション
● このツールを作り始めた後にできたもの
● conan.io
● このツールを作り始めた後にできたやつ
● JFrogという会社が買収して、今のところ今後期待できそう
● qpm
● Qt用。QMakeベース
● vcpkg
● MS製。全レシピ内蔵の富豪的なやつ（ただしWindows用）

*
GoっぽいパッケージマネージャをGoで作ろう (2014年〜)
● X getで必要なコードを持ってきて
● X buildで設定ファイルレスでアプリケーションをビルドして
● X testでユニットテストして
● X vetでコードの品質チェックして
● X fmtでフォーマットを修正して
● ついでにWebAssemblyとかやりたかった（まだ実現してない）

*
つくった（github.com/qtpm）
● qtpmという名前のツール
● ファイル名のルールに従って集めてきてCMakeの設定ファイルを自動生成
● ライブラリモードと、アプリケーションモード
● テストコードやリソースファイル、アイコンなども
● _windows.cpp、_darwin.cppみたいなやつも入れた
● 最低限の設定ファイル
● Toml形式
● バージョンとか、必要な依存Qtモジュールとか、依存パッケージとか
● とりあえずQt用のC++コードがビルドできるような機能が組込で
● moc、ui、qrcといったQt用のプリプロセッサも実行
● Qt使わないコードも使える
● インストーラも自動生成
● WindowsはWiX経由で.msi、macは.dmgファイル
● 諸事情により（セキュリティソフトが殺してくるので）.zipファイルを作る機能も

*
ツールの使い方の流れ
● qtpm init appでアプリケーションの雛形作成
● qtpm getで必要なライブラリを収集
● qtpm buildでアプリケーションをビルド
● macは標準のxcode command line toolsと、バイナリ配布のQtを利用
● WindowsはVC++ Express 2013/2015 or MinGWと、バイナリ配布のQtを利用
● インストール場所は自動探索
● qtpm fmtでフォーマットを整える
● clang-formatを利用。なるべくQt標準っぽい設定ファイルをデフォルトで利
用するが・・・たまにフォーマット後にビルド通らなくなることが・・・
● qtpm vetで文法チェック
● clang-tidyを利用
● qtpm testでテスト
● CTest（ランナー）とQTest（フレームワーク）を利用
● qtpm packでインストーラ作成

*
仕事はだいぶ楽になった
● CMakeファイルベースの開発は徒手空拳でCMakeLists.txtと戦う必要がある
● IDEはこのファイルを読み込んで初めてファイルをリストに出してくれる
● Qt CreatorとCLionがサポートしている
● コマンド一発でCMakeLists.txtが最新化されるのでファイル追加が楽
● ビルドスクリプトの試行錯誤が激減
● インストーラまで一括作成
● Goで作ったので、各種タスク実行がWindows（MinGW, コマンドプロンプト
）、macOS環境でもすべて同じように動く
● パッケージは自分で追加しないといけない・・・
● 今のところそこまでガンガン作っているわけではないので困ってない
● モジュール化は進むので、コードは分かりやすくなっているはず・・・

*
補助ツールを作る時の退路を用意
● 補助ツールのメンテがコストになってしまっては元も子もない
● SPOFになってしまってもいけない
● それが依存している何かがEOLになって使用不可能になるとか
● 中間生成物として完動するCMakeLists.txtを生成する
● 最悪、qtpmがなくても、このファイルさえあれば後工程が正しく動くよう
にしてある
qtpm pack
設定ファイル
を読む
CMakeLists.txt
生成
CMake実行
macdeployqt
windeployqt CPack実行

*
もしこれから作り直すならこうしたい
● C/C++は主に超定番ライブラリと、それを使うユーザーライブラリで大きく2つ
に分けられる
● zlibとかlibpngとか
● 超定番ライブラリは高確率でOSにも入っていたり
● 超定番ライブラリだけは特別扱いしてあげても良かったのでは
● Microsoftのvcpkgはそうなっている。このコードをまるごと頂いてもよさそう
● https://github.com/Microsoft/vcpkg
● ユーザーパッケージとフラットに扱う仕組みじゃなくてもいい
● クロスコンパイル
● いろんな処理系全部入りのDockerイメージが最近ある

*
WebAssembly対応
● WebAssemblyが今後普及するならパッケージマネージャが必要とされるはず！
● ・・・と3年前に考えた
● QtとともにWebAsmもサポートしたら面白そうだなと思っていた
● 進捗
● 処理系のダウンロード
● Emscriptenの処理系を自動でダウンロードしてくる機能が入っていたりもするが、
長らくEmscriptenのビルド済みバイナリが古いままだったので放置してた
● 最近WebAsm対応のビルド済みバイナリがダウンロードできるようになったらしい
● ビルド
● 趣味で使おうと思ったぐらいでほとんどテストしてない・・・
● そのうちまた興味が湧いたらやってみようかと

*
まとめ
● C++は今時の言語と比べるともろもろ頑張る必要がある
● ビルドツールいろいろ
● パッケージマネージャのデファクトはなかった
● Goを使ってGoっぽくC++ができるビルドツール兼パッケージマネージャ作った
● CMakeベース
● とりあえず便利に使ってます
● 退路もきちんと用意してる
● 作ってみての課題も見えた
● 定番ライブラリのサポートをまるっとやりたかった
● クロスコンパイルもやりたいよね・・・
● WebAssembly対応も一応考えていた
● Emscriptenの安定版がなかなか出ないのですっかり忘れてた

Golang tokyo #7 qtpm

More Related Content

What's hot

Similar to Golang tokyo #7 qtpm

More from Yoshiki Shibukawa

Recently uploaded

Golang tokyo #7 qtpm