VS Code + qmake = Qtアプリ | Qt 勉強会 @ Tokyo #60 参加報告

Qt logo

前回に引き続いて,今月も参加したので参加報告を記す。

概要

イベント情報
項目 内容
イベント名 Qt 勉強会 @ Tokyo #60
URL https://qt-users.connpass.com/event/90458/
ハッシュタグ #qtjp
開催地 株式会社PTP 9F会議室
東京都新宿区新宿1-23-1 新宿マルネビル9F
開催日時 2018-06-16 13:00-18:00
参加人数 11

初参加の人が3人いた。

その他,当日の自分のSNS上の投稿は以下から確認できる。

作業内容

モバイルディスプレイ

作業内容の報告の前に書いておきたいことがある。

今回は2018-04-28に初めて参加したときに思っていたモバイルディスプレイを持参した。

モバイルディスプレイ (自宅で撮影)

これを持参したのがとても良かった。基本的に調べながらの作業であり,エディターとブラウザーを見比べることが多いので,画面を切り替えずに,目線を動かすだけで済んだため作業が捗った。

他の人も持ってきたほうがいいのではないかと思った。

VS Code + qmake によるQtアプリのビルド

本日の作業の目標は,Visual Studio Code (VS Code) を使ったQtアプリのビルド方法の確立だった。

前回の勉強会の参加報告に書いたとおり,Qtと長く付き合っていくためにはできるだけQtに依存しない開発環境でQtの開発をしたほうがよいと判断した。そこで,世の中の主なプログラミング言語をカバーしており,利用者も多く,勢いのある開発環境であるVS Codeで今後はQtの開発やその他の開発もやっていきたいと考えている。

しかし,VS CodeはQtの開発ではあまり利用されておらず,VS CodeでQtの開発に必要な情報はあまりない。具体的には,VS Code上で以下2点ができる必要がある。

  1. Qtアプリのビルド・起動
  2. 補完候補にQtライブラリーの対応

そのため,本日は主にVS Codeの使い方の調査が主な実作業となった。

VS Codeでのビルド手順

結論としては成功した。こちらのリポジトリーに最小限のQtのアプリとVS Codeの設定を格納している。

このディレクトリーをVS Codeで開いて, [Tasks]>[Run Build Task…] (C-B)を実行すれば,ビルドされて実行される。

VS Codeは毎月更新されていて,変更が多いのでバージョンも明記しておく。

  • Ubuntu 16.04
  • VS Code v1.24.0
  • ms-vscode.cpptools v0.17.4

VS Codeでの設定を簡単に説明する。

1. まず,VS CodeはデフォルトではC/C++に対応していないので,ms-vscode.cpptoolsというMicrosoftが公式で提供しているC/C++の拡張機能をインストールしておく。

2. ms-vscode.cpptoolsでC/C++のインテリセンスが有効になる。

Qtのインストール先をカスタマイズしている場合,環境変数CPATHにincludeファイルのパス (例: /home/senooken/.local/opt/Qt/Qt5.10.0/5.10.0/gcc_64/include/QtWidgets) を追加する。または,.vscode/c_cpp_properties.json内の”includePath”プロパティにインクルードパスを追加する。

            "includePath": [
                "${workspaceFolder}",
                "/home/senooken/.local/opt/Qt/Qt5.10.0/5.10.0/gcc_64/include/QtWidgets"
 ],

3. VS Code上からビルドするには,Tasksという機能を使う。具体的には,.vscode/tasks.jsonにビルド手順を記入する。

今回は以下の手順を行うようにした。

qmake main.pro && make && ./main.exe
tasks.json
{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Build Hello",
            "type": "shell",
            "command": "qmake",
            "args": [
                "main.pro", "&&", "make", "&&", "${workspaceFolder}/main.exe"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

tasks.jsonを用意できたら,VS Code上でC-Bの短絡キーを押下するか,メニューから [Tasks]>[Run Build Task…] を選択すれば実行される。

qmake vs. CMake

元々は,VS Code + CMakeでQtのアプリをビルドするつもりでいた。しかし,当日会場で相談したところ,Makefileを作るだけだからqmakeでも可能との助言をいただき,qmakeでのビルドを行った。

CMakeにしてもqmakeにしても,最終的にMakefileを作成することが目的となる。アプリケーションにリンクするわけでもなく,Makefileを作るだけだから,本体のライセンスと干渉もなく問題なく利用できる。

なお,CMakeとqmakeでのビルド手順は似ていて,以下のとおりとなる。

  1. .pro (qmake) またはCMakeLists.txt (CMake) を自分で用意
  2. qmakeまたはcmakeを実行してMakefileを生成
  3. makeを実行

それでは,qmakeとCMakeの違いは何なのか?どちらがいいのか疑問に思った。会場に質問したところ,親切に回答いただけた。qmakeとCMakeとではそれぞれ利点と欠点があるとのこと。利点と欠点を一覧にまとめた。

CMakeとqmakeの利点・欠点
CMake qmake
利点
  • CTestとCPackも利用可能
  • .proファイルを書くのが簡単
欠点
  • 学習コストが高い
  • Testとパッケージングは自分でやる必要がある

最大の違いは,CMakeを使えばCTestとCPackが使えるところだ。

CMakeはただのビルドツールだが,これと付随するコマンドにテストを実行してくれるCTestと,パッケージングをしてくれるCPackがある。CMakeの設定ファイルであるCMakeLists.txtを一度用意すれば,CTestとCPackも同じように流用できるとのこと。特に,CPackはWindows, Mac, Linux (.deb, rpm) 用のインストーラーをコマンド一発で生成できるので,これはかなり便利そうだ。

qmakeを使う場合,.proファイルを用意すれば,Makefileを生成できる。.proは比較的短くて簡単な構文なので,Makefileを作成してひとまずビルドするにはこちらが手っ取り早い。しかし,その他のテストやパッケージングは自分でやる必要がある。Qt Installer Frameworkというのもあるにはあるが,こちらはWindows環境を念頭においたものとなっており,学習コストもそれなりにある。

パッケージングやテストは,ある程度ソフトウェア開発に慣れて,実際のリリースを行うくらいになったときに問題となる。まだ,Qtでの開発は始めたばかりであるので,実際の開発を進めるために,今はqmakeを使うことにする。

しかし,中長期的に考えるとCMakeを使えたほうがよいのは間違いないので,実際のリリースの段階まで辿りつけたらそのタイミングでCMakeの勉強をしようかと思う。

勉強会ではこうした意見交換ができるのが,とてもためになる。実際に顔を合わせて,議論できる場があることをありがたく思う。

まとめ

今回の勉強会では,VS Code + qmakeでQtのアプリケーションのビルドに成功し,当初の目標を果たすことができた。

まだまだ,VS Codeの使い方もわからないことだらけだ。今回はビルドはできたが,ではCleanはどうしたらいいのか,DebugとRelease用のビルドコマンドの切り分けはどうやってするのかなど,課題は山積みだ。

しかし,最低限VS CodeでQtの開発を行える環境を用意できた。中長期的にQtと付き合う上で,これは個人的には大きな成果だ。

Qtの開発は,QtCreatorでやるのが一般的であり,大半の人がそうしているだろう。そんな中,VS Codeで開発するというのはあきらかにイレギュラーだ。しかし,やはり中長期的に考えるとこうしたほうがいいと思う。QtCreatorにもプラグインで他の言語への対応はできる機構は用意されているが,書き手はほとんどいないのでほぼQt専用IDEとなっている。

エディター戦争にもなるが,ある程度開発環境の多様性があることは,お互いに刺激になってよいと思う。

ひとまず,Qtの開発環境を用意するという課題が解決できたので,次回からはもともと開発していたGUIExecの開発を再開していこうと思う。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です