一般的なプロジェクトタイプのビルド
この章では、Qt をベースとしたアプリケーション、ライブラリ、プラグインという 3 つの一般的なプロジェクトタイプの qmake プロジェクトファイルの設定方法について説明します。すべてのプロジェクトタイプは同じ変数の多くを使用しますが、それぞれプロジェクト固有の変数を使用して出力ファイルをカスタマイズします。
プラットフォーム固有の変数については、ここでは説明しません。詳細はQt for Windows - DeploymentとQt for macOS を参照してください。
アプリケーションのビルド
app
テンプレートは qmake にアプリケーションをビルドする Makefile を生成するように指示します。このテンプレートでは、CONFIG変数定義に以下のオプションのいずれかを追加することで、アプリケーションの種類を指定できます:
オプション | 説明 |
---|---|
ウィンドウズ | アプリケーションはWindows GUIアプリケーションです。 |
コンソール | app テンプレートのみ:アプリケーションはWindowsコンソール・アプリケーションです。 |
テストケース | アプリケーションは自動テストです。 |
このテンプレートを使用する場合、以下の qmake システム変数が認識されます。これらを .pro ファイルで使用して、アプリケーションに関する情報を指定する必要があります。その他のプラットフォーム依存のシステム変数については、プラットフォームノートを参照してください。
- HEADERS- アプリケーションのヘッダーファイルのリスト。
- SOURCES- アプリケーションの C++ ソース・ファイルのリスト。
- FORMS- アプリケーションの UI ファイルのリスト(Qt Widgets Designer を使用して作成)。
- LEXSOURCES- アプリケーションの Lex ソース・ファイルのリスト。
- YACCSOURCES- アプリケーションの Yacc ソース・ファイルのリスト。
- TARGET- アプリケーションの実行ファイル名。デフォルトはプロジェクト・ファイル名です。(拡張子がある場合は自動的に追加されます)。
- DESTDIR- ターゲットの実行ファイルが置かれるディレクトリ。
- DEFINES- アプリケーションに必要な追加のプリ・プロセッサ定義のリスト。
- INCLUDEPATH- アプリケーションに必要な追加のインクルード・パスのリスト。
- DEPENDPATH- アプリケーションの依存関係検索パス。
- VPATH- 供給されるファイルを見つけるための検索パス。
- DEF_FILE- Windows のみ:アプリケーションに対してリンクされる .def ファイル。
値があるシステム変数のみを使用する必要があります。例えば、特別なINCLUDEPATHがない場合は、指定する必要はありません。プロジェクトファイルの例は次のようになります:
TEMPLATE = app DESTDIR = c:/helloapp HEADERS += hello.h SOURCES += hello.cpp SOURCES += main.cpp DEFINES += USE_MY_STUFF CONFIG += release
テンプレートや保存先ディレクトリのような単一値の項目には"="を使いますが、多値の項目には "+="を使って既存の項目に追加します。=」を使うと、変数の値が新しい値に置き換わる。例えば、DEFINES=USE_MY_STUFF
と書くと、他の定義はすべて削除されます。
テストケースの構築
テストケースプロジェクトとは、自動テストとして実行することを目的としたapp
プロジェクトのことです。CONFIG
という変数にtestcase
という値を追加することで、どのapp
もテストケースとしてマークすることができます。
テストケースプロジェクトの場合、qmake は生成される Makefile にcheck
ターゲットを挿入します。このターゲットがアプリケーションを実行します。このターゲットがアプリケーションを実行し、終了コードが0であればテストはパスしたとみなされます。
check
ターゲットは自動的にSUBDIRSプロジェクトを再帰します。つまり、SUBDIRS プロジェクト内からmake check
コマンドを発行し、テストスイート全体を実行することが可能である。
check
ターゲットの実行は、特定の Makefile 変数によってカスタマイズすることができる。これらの変数は以下の通りです:
変数 | 説明 |
---|---|
TESTRUNNER | 各テストコマンドの前に付加されるコマンドまたはシェルの断片。使用例としては、指定した時間内にテストが完了しない場合にテストを終了させる「タイムアウト」スクリプトがあります。 |
TESTARGS | 各テストコマンドに追加する引数。たとえば、テストからの出力ファイルや形式を設定するための追加引数を渡すと便利です(QTestLib でサポートされている-o filename,format オプションなど)。 |
注: 変数は、.pro ファイルではなく、make
ツールの起動時に設定する必要があります。ほとんどのmake
ツールでは、コマンドラインで Makefile 変数を直接設定できます:
# Run tests through test-wrapper and use JUnit XML output format. # In this example, test-wrapper is a fictional wrapper script which terminates # a test if it does not complete within the amount of seconds set by "--timeout". # The "-o result.xml,junitxml" options are interpreted by QTestLib. make check TESTRUNNER="test-wrapper --timeout 120" TESTARGS="-o result.xml,junitxml"
テストケースプロジェクトは、以下のCONFIG
オプションでさらにカスタマイズすることができます:
オプション | オプション 説明 |
---|---|
insignificant_test | make check の間、テストの終了コードは無視されます。 |
テストケースはQTest やTestCase
で記述されることが多いですが、CONFIG+=testcase
やmake check
を使用することは必須ではありません。唯一の主な要件は、テスト・プログラムが成功した場合は終了コードが 0 で終了し、失敗した場合は 0 以外の終了コードで終了することです。
ライブラリのビルド
lib
テンプレートは qmake にライブラリをビルドする Makefile を生成するように指示します。このテンプレートを使用する場合、app
テンプレートがサポートするシステム変数に加えて、VERSION変数がサポートされます。ライブラリに関する情報を指定するには、.pro ファイルで変数を使用します。
lib
テンプレートを使用する場合、以下のオプションをCONFIG変数に追加して、ビルドされるライブラリのタイプを決定することができます:
オプション | 説明 |
---|---|
dll | ライブラリーは共有ライブラリー(dll)です。 |
staticlib | ライブラリはスタティック・ライブラリです。 |
プラグイン | ライブラリはプラグインです。 |
ライブラリに関する追加情報を提供するために、以下のオプションを定義することもできます。
- VERSION - ターゲット・ライブラリのバージョン番号。例えば、2.3.1。
ライブラリのターゲット・ファイル名はプラットフォームに依存します。例えば、X11、macOS、iOSでは、ライブラリ名の先頭にlib
が付きます。Windowsでは、ファイル名に接頭辞は付きません。
プラグインのビルド
プラグインは、前のセクションで説明したように、lib
テンプレートを使ってビルドします。これは qmake に、各プラットフォームに適した形で、通常はライブラリの形でプラグインをビルドするプロジェクトの Makefile を生成するように指示します。通常のライブラリと同様に、VERSION変数を使用してプラグインに関する情報を指定します。
- VERSION - ターゲット・ライブラリのバージョン番号。例えば、2.3.1。
Qt Widgets Designerプラグインのビルド
Qt Widgets Designerプラグインは、Qtがシステム用に構成された方法に依存する特定の構成設定のセットを使用して構築されます。便宜上、これらの設定はQT変数にdesigner
を追加することで有効にできます。例えば
QT += widgets designer
プラグインベースのプロジェクトの例については、Qt Widgets Designer Examplesを参照してください。
デバッグモードとリリースモードでのビルドとインストール
デバッグモードとリリースモードの両方でプロジェクトをビルドする必要がある場合があります。CONFIG変数にはdebug
とrelease
の両方のオプションを指定できますが、最後に指定されたオプションのみが適用されます。
両方のモードでビルドする
プロジェクトを両方のモードでビルドできるようにするには、CONFIG
変数にdebug_and_release
オプションを追加する必要があります:
CONFIG += debug_and_release CONFIG(debug, debug|release) { TARGET = debug_binary } else { TARGET = release_binary }
上のスニペットのスコープは、各モードでビルドターゲットを変更し、結果のターゲットが異なる名前になるようにします。ターゲットに異なる名前を指定することで、一方が他方を上書きすることがなくなります。
qmakeがプロジェクトファイルを処理するとき、両方のモードでプロジェクトをビルドできるようにMakefileルールを生成します。これは以下の方法で呼び出すことができます:
make all
プロジェクトファイルのCONFIG
変数にbuild_all
オプションを追加すると、デフォルトで両方のモードでビルドされるようになります:
CONFIG += build_all
これにより、Makefile はデフォルトのルールで処理されます:
make
両方のモードでインストールする
build_all
オプションは、インストール・ルールが呼び出されたときに、両方のバージョンのターゲットがインストールされるようにします:
make install
ターゲットプラットフォームに応じて、ビルドターゲットの名前をカスタマイズできます。例えば、ライブラリやプラグインは、Windows上ではUnixプラットフォームで使用されるものとは異なる慣習で命名されるかもしれません:
CONFIG(debug, debug|release) { mac: TARGET = $$join(TARGET,,,_debug) win32: TARGET = $$join(TARGET,,d) }
上記のスニペットのデフォルトの動作は、デバッグモードでビルドするときにビルドターゲットに使用される名前を変更することです。else
節をスコープに追加することで、リリースモードでも同じことができます。そのままでは、ターゲット名は変更されません。
本ドキュメントに含まれる文書の著作権は、それぞれの所有者に帰属します。 本書で提供されるドキュメントは、Free Software Foundation が発行したGNU Free Documentation License version 1.3に基づいてライセンスされています。 Qtおよびそれぞれのロゴは、フィンランドおよびその他の国におけるThe Qt Company Ltd.の 商標です。その他すべての商標は、それぞれの所有者に帰属します。