アプリケーション、ライブラリおよびプラグイン：この章では、Qtの3つの共通のタイプに基づいてプロジェクトのqmakeのプロジェクトファイルを設定する方法について説明します。すべてのプロジェクトタイプは、同じ変数の多くを使用しますが、各特定のプロジェクトの種類は、変数のプロジェクトに出力ファイルをカスタマイズするために使用していますが。
ここでは、プラットフォーム固有の変数を導入しません。詳細については、Qt-のQtのWindowsの展開とMacOSのを。
構築するアプリケーション
アプリケーションテンプレートはqmakeのMakefileを生成するアプリケーションに指示します。このテンプレートを使用して、CONFIG変数定義で、次のいずれかのオプションを追加することによって、アプリケーションの種類を指定することができます。
| オプション | 説明 |
| ウィンドウズ | このアプリケーションは、WindowsのGUIアプリケーションです。 |
| コンソール | 唯一のアプリケーションテンプレート：このアプリケーションは、Windowsコンソールアプリケーションです。 |
| テストケース | アプリケーションがされてテストを自動化。 |
このテンプレートを使用すると、システムは以下のqmakeの変数を認識します。あなたのアプリケーションに関する情報を指定するために.PROファイルでそれらを使用する必要があります。他のプラットフォームに依存するシステム変数について、あなたは見ることができ、プラットフォームの説明を。
- HEADERS - アプリケーションのリストヘッダファイル。
- SOURCES - アプリケーションの一覧C ++ソースファイル。
- （のQt Designerで作成された）アプリケーションのファイルリストのUI - FORMS。
- アプリケーションのリストLexのソースファイル - LEXSOURCES。
- YACCSOURCES - アプリケーションのリストYaccのソースファイル。
- TARGET - アプリケーションの実行可能ファイルの名前。デフォルトでは、プロジェクトファイルの名前です。（拡張機能がある場合、自動的に追加）。
- DESTDIR - ターゲットの実行可能ファイルのディレクトリが配置されています。
- DEFINES - アプリケーションが必要とするその他のプリプロセッサ定義のリスト。
- インクルードパス - アプリケーションで必要とされる他のすべてのパスのリストが含まれています。
- DEPENDPATH - アプリケーションの依存関係の検索パス。
- VPATH - 検索パス提供されるファイルを検索します。
- DEF_FILE - Windowsのみ：アプリケーションリンクの.defファイル。
あなただけのそれらの値とシステム変数を使用する必要があります。あなたが任意の追加のインクルードパスを持っていない場合たとえば、あなたは、任意のパスを指定する必要はありません。qmakeは、必要なデフォルトを追加します。例えば以下のようにプロジェクトファイルが表示されることがあります。
TEMPLATES = app
DESTDIR = c:/helloapp
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
DEFINES += USE_MY_STUFF
CONFIG += 发布変数の単一の値（例えば、鋳型または標的ディレクトリ）のために、我々は、「=」を使用するが多値変数、我々はで使用されるタイプの既存の変数に追加する必要があり、「+ =」。「=」変数値が新しい値に置き換えられます使用してください。我々はDEFINES = USE_MY_STUFFを書いた場合、他のすべての定義が削除されます。
テストケースを確立
プロジェクトは、自動テストアプリケーションプロジェクトを実行するためのテストケースとして機能するように意図されます。CONFIG変数のテストケースに付加価値によって、任意のアプリケーションは、テストケースとしてマークすることができます。
試験項目について、qmakeのは、メイクファイルが生成された検査対象に挿入されます。目標は、アプリケーションを実行することになります。終了コードで終了し、テストが0に等しい場合、テストは合格とみなされます。
自動再帰SUBDIRS変数によってターゲットを確認してください。あなたはSUBDIRS変数からコマンドメイクチェックを発行することができ、この手段は、全体のテストスイートを実行します。
あなたは、いくつかのMakefileの変数のターゲットによって実行されるチェックをカスタマイズすることができます。これらの変数は以下のとおりです。
| 変数 | 説明 |
| テストランナー | コマンドまたはシェルの断片は、各コマンドの前にテストを持っています。典型的なユースケースは、スクリプト「タイムアウト」でスクリプトが指定された時間内に完了しない場合、テストは終了します。 |
| TESTARGS | 他のパラメータは、各テストコマンドに取り付けられています。例えば、（例えば-QTestLib -oファイル名、フォーマットオプションをサポートする）試験の出力ファイルと形式を設定するために追加のパラメータを渡すことは有用であり得ます。 |
注：メイクツールを呼び出すのではなく、.PROファイルを設定するときに変数を設定する必要があります。ほとんどのメイクツールは、直接コマンドライン上でMakefileの変数をサポートしています。
# Run tests through test-wrapper and use xunitxml 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,xunitxml" options are interpreted by QTestLib.
make check TESTRUNNER="test-wrapper --timeout 120" TESTARGS="-o result.xml,xunitxml"あなたは、さらにカスタマイズCONFIGテストプロジェクトには、次のオプションを使用することができます。
| オプション | 説明 |
| insignificant_test | 作るメイク検査中、検査は終了コードを無視します。 |
筆記試験一般QTestまたはテストケースが、代わりにCONFIG + =テストケース検査要求を使用します。唯一の主要な要件は、成功、失敗の場合はゼロ以外の終了コード終了時にゼロの終了コード出口とテストプログラムということです。
ライブラリーを作成します。
libのテンプレートは、ライブラリを構築するためのMakefileを生成するqmakeのを伝えます。このテンプレートを使用すると、アプリケーションテンプレートに加えて、システム変数をサポートし、またVERSION変数をサポートしています。.PROファイル変数を使用すると、ライブラリに関する情報を指定します。
あなたはLIBのテンプレートを使用するときは、構築したライブラリーのタイプを決定するためにCONFIG変数に以下のオプションを追加することができます。
| オプション | 説明 |
| DLL | ライブラリは共有ライブラリ（DLL）です。 |
| staticlib | ライブラリは、静的ライブラリです。 |
| プラグイン | ライブラリは、プラグインです。 |
また、図書館に関する追加情報を提供するために、以下のオプションを定義することができます。
VERSION - ターゲットライブラリのバージョン番号。例えば、2.3.1。
プラットフォームに依存するライブラリ先のファイル名。例えば、X11、MacOSのとiOS上で、ライブラリ名はlibにして付けられます。Windowsでは、接頭辞がファイル名に追加されませんがあります。
プラグインを作成します。
前のセクションとして、プラグLIBを構築するためのテンプレートを使用して。これは、プラグインを構築するために（通常はライブラリの形で）ファイルには、各プラットフォームに適した形態であろう、プロジェクトのためのMakefileを生成するqmakeのを伝えます。通常のライブラリと同じように、VERSION変数は、プラグインについての情報を指定するために使用されます。
VERSION - ターゲットライブラリのバージョン番号。例えば、2.3.1。
Qtのデザイナプラグインを作成します
Qtのデザイナープラグインは、Qtは、あなたのシステムに設定する方法に応じて、これらの構成設定を構築するために、構成設定の特定のセットを使用することです。便宜上、これらの設定は、QT変数にデザイナーを追加することで有効にすることができます。例えば：
QT += 小部件设计器プロジェクトベースのプラグインのより多くの例については、Qtのデザイナーの例を。
作成およびデバッグとリリースモードでインストール
時にはそれは、プロジェクトをビルドし、デバッグとリリースモードの両方で必要です。けれどもCONFIG変数が同時にデバッグとリリースオプションを含めることができますが、唯一の最後のアプリケーションは、オプションを指定しました。
2つのモードで構築
プロジェクトは2つのモードで構築することができる場合は、CONFIG変数にdebug_and_releaseオプションを追加する必要があります。
CONFIG += debug_and_release
CONFIG(debug, debug|release) {
TARGET = debug_binary
} else {
TARGET = release_binary
}各編集モードで上記のコードは、結果のターゲットが別の名前を持っていることを確認するために、ターゲットをビルドします。ターゲットは、別の目的でカバーされないことを保証するために、ターゲットに別の名前を提供します。
ときqmakeのプロジェクトファイルは、それは2つのモードでプロジェクトのビルドを可能にするためのMakefileのルールを生成します。これは、次の方法で呼び出すことができます。
make allあなたは、プロジェクトが、デフォルトでは2つのモードで構築されていることを確認するために、プロジェクトファイルのCONFIG変数にbuild_allオプションを追加することができます。
CONFIG += build_allあなたがMakefileを処理するデフォルトの規則を使用することができますので。
make2つのモードでマウントされました
build_allオプションは、インストールのルールを呼び出すときに、2つのバージョンが目標をインストールするようになります：
make installあなたは、ターゲットプラットフォームに基づいて構築され、ターゲットの名前をカスタマイズすることができます。例えば、ライブラリやプラグインに名前を付けるためのさまざまな規則上のWindowsおよびUnixプラットフォーム上：
CONFIG(debug, debug|release) {
mac: TARGET = $$join(TARGET,,,_debug)
win32: TARGET = $$join(TARGET,,d)
}上記のコードスニペットのデフォルトの動作では、ビルドのターゲットの名前を変更し、デバッグモードでビルドです。else節は、リリースモードで同じ操作を実行するために上記のコードに追加することができます。ターゲット名は変更されません。
