一般的なプロジェクトタイプのビルド

この章では、Qt に基づく 3 つの一般的なプロジェクトタイプ（アプリケーション、ライブラリ、プラグイン）について、qmake プロジェクトファイルの設定方法を説明します。すべてのプロジェクトタイプで多くの共通変数が使用されますが、それぞれがプロジェクト固有の変数を使用して出力ファイルをカスタマイズします。

プラットフォーム固有の変数については、ここでは説明しません。詳細については、『Qt for Windows - デプロイ』および『Qt for macOS』を参照してください。

アプリケーションのビルド

app テンプレートは、アプリケーションをビルドするためのMakefileを生成するようqmakeに指示します。このテンプレートでは、CONFIG変数の定義に以下のオプションのいずれかを追加することで、アプリケーションの種類を指定できます。

このテンプレートを使用する場合、以下の 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 がない場合は、何も指定する必要はありません。qmake が必要なデフォルト値を追加します。プロジェクトファイルの例は次のようになります。

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 プロジェクトです。任意のapp は、CONFIG 変数にtestcase という値を追加することで、テストケースとしてマークすることができます。

テストケースプロジェクトの場合、qmakeは生成されたMakefileにcheck ターゲットを挿入します。このターゲットはアプリケーションを実行します。終了コードが0で終了した場合、テストは成功したとみなされます。

check ターゲットは、SUBDIRSプロジェクト内を自動的に再帰的に処理します。つまり、SUBDIRSプロジェクト内からmake check コマンドを実行することで、テストスイート全体を実行することが可能です。

check ターゲットの実行は、特定の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 オプションを使用してさらにカスタマイズできます：

テストケースは、多くの場合 `QTest ` または `TestCase` を使用して記述されますが、`CONFIG+=testcase ` および `make check` を使用することが必須というわけではありません。唯一の主要な要件は、テストプログラムが成功した場合は終了コード 0 で、失敗した場合は 0 以外の終了コードで終了することです。

ライブラリのビルド

lib テンプレートは、ライブラリをビルドするためのMakefileを生成するようqmakeに指示します。このテンプレートを使用する場合、app テンプレートがサポートするシステム変数に加え、VERSION変数もサポートされます。.proファイル内でこれらの変数を使用して、ライブラリに関する情報を指定してください。

lib テンプレートを使用する場合、CONFIG変数に以下のオプションを追加することで、ビルドするライブラリのタイプを指定できます：

ライブラリに関する追加情報を提供するために、以下のオプションも定義できます。

• 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 ` 句を追加することができます。そのままにしておくと、ターゲット名は変更されません。