高度な使い方

新しい設定機能の追加

qmake を使用すると、独自のfeatures を作成し、その名前をCONFIG変数で指定された値のリストに追加することで、プロジェクトファイルに組み込むことができます。機能とは、.prf ファイル内のカスタム関数や定義の集合であり、これらは多くの標準ディレクトリのいずれかに配置することができます。 これらのディレクトリの場所はいくつかの場所で定義されており、qmakeは.prf ファイルを検索する際、以下の順序でそれぞれを確認します：

1. QMAKEFEATURES 環境変数にリストされているディレクトリ。この変数には、プラットフォームのパスリスト区切り文字（Unixではコロン、Windowsではセミコロン）で区切られたディレクトリのリストが含まれています。
2. QMAKEFEATURES プロパティ変数にリストされているディレクトリ。このディレクトリには、プラットフォームのパス区切り文字（Unix ではコロン、Windows ではセミコロン）で区切られたディレクトリのリストが含まれています。
3. mkspecs ディレクトリ内に存在するfeaturesディレクトリ内。mkspecs ディレクトリは、プラットフォームのパスリスト区切り文字で区切られたディレクトリのリストを含むQMAKEPATH 環境変数に指定されたディレクトリのいずれかの下に配置できます。例：$QMAKEPATH/mkspecs/<features> 。
4. QMAKESPEC環境変数で指定されたディレクトリの下にある features ディレクトリ内。例：$QMAKESPEC/<features> 。
5. data_install/mkspecs ディレクトリ内に存在するfeaturesディレクトリ内。例：data_install/mkspecs/<features> 。
6. QMAKESPEC 環境変数で指定されたディレクトリと同階層にあるfeaturesディレクトリ内。例：$QMAKESPEC/../<features> 。

機能ファイルの検索対象となる features ディレクトリは以下の通りです：

1. features/unix使用中のプラットフォームに応じて、features/win32 またはfeatures/macx
2. features/

たとえば、プロジェクトファイル内の以下の指定を考えてみましょう:

CONFIG += myfeatures

CONFIG 変数にこの記述を追加すると、qmake はプロジェクトファイルの解析が完了した後、上記の場所からmyfeatures.prf ファイルを検索します。Unix システムでは、次のファイルを検索します:

1. $QMAKEFEATURES/myfeatures.prf (QMAKEFEATURES 環境変数に列挙された各ディレクトリについて)
2. $$QMAKEFEATURES/myfeatures.prf （QMAKEFEATURES プロパティ変数にリストされている各ディレクトリについて）
3. myfeatures.prf （プロジェクトのルートディレクトリ内）。プロジェクトのルートは、最上位の.pro ファイルによって決定されます。ただし、.qmake.cache ファイルをサブディレクトリやサブプロジェクトのディレクトリ内に配置した場合、プロジェクトのルートはそのサブディレクトリ自体になります。
4. $QMAKEPATH/mkspecs/features/unix/myfeatures.prf および$QMAKEPATH/mkspecs/features/myfeatures.prf （QMAKEPATH 環境変数に列挙された各ディレクトリごとに）
5. $QMAKESPEC/features/unix/myfeatures.prf および$QMAKESPEC/features/myfeatures.prf
6. data_install/mkspecs/features/unix/myfeatures.prf およびdata_install/mkspecs/features/myfeatures.prf
7. $QMAKESPEC/../features/unix/myfeatures.prf および$QMAKESPEC/../features/myfeatures.prf

ファイルのインストール

Unix では、ビルドツールを使用してアプリケーションやライブラリをインストールすることも一般的です。たとえば、make install を実行するなどです。このため、qmake には「install set 」という概念があり、これはプロジェクトの一部をどのようにインストールするかに関する指示を含むオブジェクトです。たとえば、ドキュメントファイルのコレクションは次のように記述できます。

documentation.path = /usr/local/program/doc
documentation.files = docs/*

path メンバーは、ファイルを/usr/local/program/doc （path メンバー）にインストールすべきであることを qmake に通知し、files メンバーは、インストールディレクトリにコピーすべきファイルを指定します。この場合、docs ディレクトリ内のすべてのファイルが/usr/local/program/doc にコピーされます。

インストールセットの記述が完了したら、次のような行を使用して、それをインストールリストに追加できます。

INSTALLS += documentation

qmake は、指定されたファイルがインストールディレクトリに確実にコピーされるようにします。このプロセスをさらに細かく制御したい場合は、オブジェクトのextra メンバーに定義を指定することもできます。たとえば、次の行は、このインストールセットに対して一連のコマンドを実行するよう qmake に指示します：

unix:documentation.extra = create_docs; mv master.doc toc.doc

unix スコープにより、これらの特定のコマンドがUnixプラットフォームでのみ実行されることが保証されます。他のプラットフォーム向けの適切なコマンドは、他のスコープ規則を使用して定義できます。

extra メンバーで指定されたコマンドは、オブジェクトの他のメンバー内の指示が実行される前に実行されます。

INSTALLS 変数に組み込みのインストールセットを追加し、files やextra メンバーを指定しない場合、qmakeがコピーすべき内容を自動的に判断します。現在、target およびdlltarget のインストールセットがサポートされています。例えば：

target.path = /usr/local/myprogram
INSTALLS += target

上記の行では、qmake はコピーが必要なものを認識しており、インストール処理を自動的に処理します。

カスタムターゲットの追加

qmakeは、クロスプラットフォームビルドツールとして期待されるあらゆる機能を網羅するよう努めています。しかし、プラットフォーム固有の特別なコマンドを実際に実行する必要がある場合、これだけでは不十分なことがよくあります。このような場合は、さまざまなqmakeバックエンドに対して具体的な指示を与えることで実現できます。

Makefile 出力のカスタマイズは、qmake の他の部分と同様に、オブジェクトスタイルの API を通じて行われます。オブジェクトは、そのメンバを指定することで自動的に定義されます。例：

mytarget.target = .buildfile
mytarget.commands = touch $$mytarget.target
mytarget.depends = mytarget2

mytarget2.commands = @echo Building $$mytarget.target

上記の定義は、mytarget というqmakeターゲットを定義しています。このターゲットには.buildfile というMakefileターゲットが含まれており、これはtouch コマンドによって生成されます。最後に、.depends メンバーは、mytarget が、後に定義される別のターゲットであるmytarget2 に依存していることを指定しています。mytarget2 はダミーターゲットです。これは、コンソールにテキストを出力するためだけに定義されています。

最後のステップは、QMAKE_EXTRA_TARGETS 変数を使用して、このオブジェクトがビルドすべきターゲットであることをqmakeに指示することです：

QMAKE_EXTRA_TARGETS += mytarget mytarget2

カスタムターゲットを実際にビルドするには、これだけで十分です。もちろん、これらのターゲットのいずれかをqmake のビルドターゲットに関連付けたい場合もあるでしょう。その場合は、Makefile ターゲットをPRE_TARGETDEPS のリストに含めるだけで済みます。

カスタムターゲットの仕様では、以下のメンバーがサポートされています：

コンパイラの追加

qmake をカスタマイズして、新しいコンパイラやプリプロセッサに対応させることは可能です:

new_moc.output  = moc_${QMAKE_FILE_BASE}.cpp
new_moc.commands = moc ${QMAKE_FILE_NAME} -o ${QMAKE_FILE_OUT}
new_moc.depend_command = g++ -E -M ${QMAKE_FILE_NAME} | sed "s,^.*: ,,"
new_moc.input = NEW_HEADERS
QMAKE_EXTRA_COMPILERS += new_moc

上記の定義があれば、利用可能な場合、mocのドロップイン置換を使用できます。このコマンドは、NEW_HEADERS 変数（input メンバーから）に指定されたすべての引数に対して実行され、その結果はoutput メンバーで定義されたファイルに書き込まれます。このファイルは、プロジェクト内の他のソースファイルに追加されます。 さらに、qmakeはdepend_command を実行して依存関係情報を生成し、この情報もプロジェクトに追加します。

カスタムコンパイラ仕様では、以下のメンバーがサポートされています：

CONFIG メンバは、以下のオプションをサポートしています。

ライブラリの依存関係

ライブラリに対してリンクを行う際、qmake は多くの場合、このライブラリがどの他のライブラリにリンクしているかを把握するために基盤となるプラットフォームに依存し、プラットフォームにそれらのライブラリを取り込ませます。しかし、多くの場合、これだけでは不十分です。例えば、ライブラリを静的にリンクする場合、他のライブラリにはリンクされないため、それらのライブラリに対する依存関係は作成されません。 しかし、後でこのライブラリに対してリンクを行うアプリケーションは、静的ライブラリが必要とするシンボルがどこにあるかを知る必要があります。qmakeでは、追跡を明示的に有効にしておけば、適切な場合にライブラリの依存関係を追跡しようとします。

まず、ライブラリ自体で依存関係追跡を有効にする必要があります。これを行うには、qmake にライブラリに関する情報を保存するよう指示する必要があります。

CONFIG += create_prl

これは `lib ` テンプレートにのみ関連し、それ以外のテンプレートでは無視されます。このオプションを有効にすると、qmake はライブラリに関するメタ情報を保存する、拡張子が `.prl` のファイルを作成します。このメタファイルは通常のプロジェクトファイルと似ていますが、内部変数の宣言のみを含んでいます。 このライブラリをインストールする際、INSTALLS宣言でターゲットとして指定すると、qmakeは自動的に.prlファイルをインストールパスにコピーします。

このプロセスの 2 番目のステップは、静的ライブラリを使用するアプリケーションでこのメタ情報の読み取りを有効にすることです。

CONFIG += link_prl

これが有効になると、qmakeはアプリケーションによってリンクされているすべてのライブラリを処理し、それらのメタ情報を検出します。qmakeはこれを利用して関連するリンク情報を決定し、具体的にはアプリケーションのプロジェクトファイルのDEFINESおよびLIBSのリストに値を追加します。 qmakeがこのファイルを処理し終えると、LIBS 変数に新たに追加されたライブラリを調べ、それらに依存する.prlファイルを見つけ出し、すべてのライブラリが解決されるまでこの処理を続けます。この時点で、通常通りMakefileが生成され、ライブラリはアプリケーションに対して明示的にリンクされます。

.prl ファイルは qmake によってのみ作成されるべきであり、プラットフォーム依存の情報を含む可能性があるため、オペレーティングシステム間で転送してはなりません。