Qmake позволяет программисту создавать собственные features-файлы, которые можно включать в файлы проекта, добавляя их имена в список значений, заданных переменной CONFIG. Наборы пользовательских функций и определений, размещенные в feature-файлах (т. е. файлах с расширением *.prf) называются функциональными возможностями.

Примечание: таким образом, по-русски, features-файлы правильно было бы называть "файлами дополнительных возможностей".

Prf-файлы могут находиться в одном из многих каталогов, в которых происходит поиск feature-файлов. Стандартное расположение этих каталогов определено в нескольких местах, и qmake проверяет каждое такое место в следующем порядке :

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

Install set - это объект, который содержит инструкции о том, как должна быть установлена часть проекта.

Например, набор файлов документации может быть описан следующим образом:

documentation.files = docs/*

documentation.path = /usr/local/program/doc

Через свойство files указываюся файлы, которые должны быть скопированы в каталог установки. Через свойство path указывается, что файлы должны быть установлены в /usr/local/program/doc. Таким образом, все, что находится в каталоге docs (относительно *.pro/*prf файла?), будет скопировано в /usr/local/program/doc.

После того, как установочный набор будет полностью описан, вы можете добавить его в список установки с помощью строки, подобной этой:

INSTALLS += documentation

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

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

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

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

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

target.path = /usr/local/myprogram

INSTALLS += target

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

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

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

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

Другими словами, можно взять произвольное имя, этому имени прописать свойства target и прочие (причем, можно не все), и тогда будет автоматически создан объект, который описывает объект-цель.

Например:

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 build target. Для этого вам просто нужно включить ваш целевой Makefile в список PRE_TARGETDEPS.

Спецификация пользовательских объектов-целей поддерживает следующие свойства:

Свойство	Описание
commands	Команды для создания цели пользовательской сборки.
CONFIG	Конкретные параметры конфигурации для цели пользовательской сборки. Может быть установлено в recursive, чтобы указать, что в Makefile должны быть созданы правила для вызова соответствующей цели внутри определенного для подцели Makefile. Это свойство по умолчанию создает запись для каждой из подцелей.
depends	Существующие цели сборки, от которых зависит цель пользовательской сборки.
recurse	Указывает, какие подцелевые объекты следует использовать при создании правил в Makefile для вызова конкретного подцелевого файла Makefile. Этот элемент используется только тогда, когда recursive установлен в CONFIG. Типичными значениями являются "Debug" и "Release".
recurse_target	Указывает цель, которая должна быть создана с помощью подцелевого Makefile для правила в Makefile. Этот элемент добавляет что-то вроде $(MAKE) -f Makefile.[subtarget] [recurse_target]. Этот элемент используется только тогда, когда в CONFIG установлено recursive.
target	Имя цели пользовательской сборки.

Добавление компиляторов

Можно настроить 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 для создания информации о зависимостях, а также для размещения этой информации в проекте.

Пользовательская спецификация компилятора поддерживает следующие свойства:

Свойство	Описание
commands	Команды, используемые для генерации выходных данных из входных.
CONFIG	Конкретные параметры конфигурации для пользовательского компилятора. Смотрите ниже таблицу параметров CONFIG для получения подробной информации.
depend_command	Указывает команду, используемую для создания списка зависимостей для выходных данных.
dependency_type	Указывает тип выходного файла. Если это файл известного типа (например, TYPE_C, TYPE_UI, TYPE_QRC), он обрабатывается как один из файлов этого типа.
depends	Определяет зависимости выходного файла.
input	Переменная, указывающая файлы, которые должны быть обработаны пользовательским компилятором.
name	Описание того, что делает пользовательский компилятор. Это используется только в некоторых бэкендах.
output	Имя файла, созданное с помощью пользовательского компилятора.
output_function	Определяет пользовательскую функцию qmake, которая используется для указания создаваемого имени файла.
variables	Указывает, что указанные здесь переменные заменяются на $(QMAKE_COMP_VARNAME), когда они упоминаются в файле pro как $(VARNAME).
variable_out	Переменная, в которую следует добавлять файлы, созданные на основе выходных данных.

Элемент CONFIG поддерживает следующие параметры:

Опция	Описание
combine	Указывает, что все входные файлы объединены в один выходной файл.
target_predeps	Указывает, что выходные данные должны быть добавлены в список PRE_TARGETDEPS.
explicit_dependencies	Зависимости для выходных данных генерируются только из элемента depends и нигде больше.
dep_existing_only	Каждая зависимость, являющаяся результатом .depend_command , проверяется на наличие. Несуществующие зависимости игнорируются. Это значение было введено в Qt 5.13.2.
dep_lines	Выходные данные команды .depend_command интерпретируются как один файл на строку. По умолчанию используется разделение через пробелы, и оно поддерживается только из соображений обратной совместимости.
no_link	Указывает, что выходные данные не следует добавлять в список объектов, на которые нужно создавать ссылки.

Зависимости библиотек

Часто при создании ссылок на библиотеку 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 и не должны передаваться между операционными системами, поскольку они могут содержать информацию, зависящую от платформы.