Расширенное использование

Добавление новых функций конфигурации

qmake позволяет создавать собственные features , которые можно включать в файлы проекта, добавляя их имена в список значений, заданных переменной CONFIG. Функции представляют собой наборы пользовательских функций и определений в файлах .prf, которые могут находиться в одном из многих стандартных каталогов. Расположение этих каталогов определяется в нескольких местах, и qmake проверяет каждый из них в следующем порядке, когда ищет файлы .prf:

1. В каталоге, указанном в переменной среды QMAKEFEATURES, которая содержит список каталогов, разделенных разделителем списка путей платформы (двоеточие для Unix, точка с запятой для Windows).
2. В каталоге, указанном в переменной свойства QMAKEFEATURES, которая содержит список каталогов, разделенных разделителем списка путей платформы.
3. В каталоге features, находящемся внутри каталога mkspecs. Каталоги mkspecs могут находиться под любым из каталогов, указанных в переменной среды QMAKEPATH, которая содержит список каталогов, разделенных разделителем списка путей платформы. Например: $QMAKEPATH/mkspecs/<features>.
4. В каталоге features, расположенном под каталогом, указанным в переменной среды QMAKESPEC. Например: $QMAKESPEC/<features>.
5. В каталоге features, расположенном в каталоге data_install/mkspecs. Например: data_install/mkspecs/<features>.
6. В каталоге features, находящемся на том же уровне, что и каталог, указанный в переменной среды QMAKESPEC. Например: $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

Примечание: Файлы .prf должны иметь имена в нижнем регистре.

Установка файлов

В Unix часто используется инструмент сборки для установки приложений и библиотек, например, вызвав make install. По этой причине в qmake существует понятие install set, объект, содержащий инструкции о том, как устанавливать часть проекта. Например, набор файлов документации можно описать следующим образом:

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

Член path сообщает qmake, что файлы должны быть установлены в /usr/local/program/doc (член path), а член files указывает файлы, которые должны быть скопированы в каталог установки. В данном случае всё содержимое каталога docs будет скопировано в /usr/local/program/doc.

После полного описания набора установки вы можете добавить его в список установки, например, так:

INSTALLS += documentation

qmake обеспечит копирование указанных файлов в каталог установки. Если вам нужен больший контроль над этим процессом, вы также можете предоставить определение для члена extra объекта. Например, следующая строка сообщает qmake выполнить серию команд для этого набора установки:

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

Область unix scope гарантирует, что эти конкретные команды выполняются только в системах Unix. Соответствующие команды для других платформ могут быть определены с помощью других правил области.

Команды, указанные в члене extra, выполняются перед выполнением инструкций в других членах объекта.

Если вы добавляете встроенный набор установки в переменную INSTALLS и не указываете члены files или extra, qmake определит, что нужно скопировать. В настоящее время поддерживаются наборы установки target и dlltarget. Например:

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

В приведенных выше строках qmake знает, что нужно скопировать, и автоматически выполнит процесс установки.

Добавление пользовательских целей

qmake пытается выполнить все, что ожидается от кроссплатформенного инструмента сборки. Это часто недостаточно хорошо, когда вам действительно нужно выполнить специальные зависящие от платформы команды. Этого можно достичь с помощью специфических инструкций для разных бэкэндов qmake.

Настройка вывода Makefile выполняется с помощью API в стиле объекта, как и в других местах в qmake. Объекты определяются автоматически путем задания их *членов*. Например:

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

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

Вышеприведённые определения определяют цель qmake под названием mytarget, содержащую цель Makefile под названием .buildfile, которая, в свою очередь, генерируется командой 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 в путь установки.

Второй шаг в этом процессе - включение возможности чтения этой метаинформации в приложениях, которые используют статическую библиотеку:

CONFIG += link_prl

При включении этого параметра qmake обработает все библиотеки, к которым ссылается приложение, и найдет их метаинформацию. qmake будет использовать это для определения соответствующей линковки, в частности, добавляя значения в список DEFINES и LIBS файла проекта приложения. После обработки этого файла qmake просмотрит недавно добавленные библиотеки в переменной LIBS, найдет их зависимые файлы .prl, продолжая до тех пор, пока все библиотеки не будут разрешены. В этот момент Makefile создается как обычно, и библиотеки явно линкованы с приложением.

Файлы .prl должны создаваться только qmake и не должны передаваться между операционными системами, так как они могут содержать зависимую от платформы информацию.