Расширенное использование
Добавление новых функций конфигурации
qmake позволяет создавать собственные features , которые могут быть включены в файлы проекта, добавив их имена в список значений, указанных переменной CONFIG. Функции представляют собой коллекции пользовательских функций и определений в файлах .prf , которые могут находиться в одном из нескольких стандартных каталогов. Расположение этих каталогов определено в нескольких местах, и qmake проверяет каждый из них в следующем порядке, когда ищет файлы .prf:
- В каталоге, указанном в переменной среды
QMAKEFEATURES, содержащей список каталогов, разделённых разделителем пути платформы (двоеточие для Unix, точка с запятой для Windows). - В каталоге, указанном в переменной свойства
QMAKEFEATURES, содержащей список каталогов, разделённых разделителем пути платформы. - В каталоге features, находящемся внутри каталога
mkspecs. Каталогиmkspecsмогут находиться под любыми из каталогов, перечисленных в переменной средыQMAKEPATH, содержащей список каталогов, разделённых разделителем пути платформы. Например:$QMAKEPATH/mkspecs/<features>. - В каталоге features, находящемся под каталогом, указанным в переменной среды QMAKESPEC. Например:
$QMAKESPEC/<features>. - В каталоге features, находящемся в каталоге
data_install/mkspecs. Например:data_install/mkspecs/<features>. - В каталоге features, находящемся рядом с каталогом, указанным в переменной среды
QMAKESPEC. Например:$QMAKESPEC/../<features>.
Следующие каталоги features проверяются на наличие файлов функций:
-
features/unix,features/win32, илиfeatures/macx, в зависимости от используемой платформы features/
Например, рассмотрим следующее присваивание в файле проекта:
CONFIG += myfeatures
С этим дополнением к переменной CONFIG, qmake будет искать указанные выше расположения для файла myfeatures.prf после завершения разбора файла проекта. В системах Unix он будет искать следующий файл:
-
$QMAKEFEATURES/myfeatures.prf(для каждого каталога, перечисленного в переменной средыQMAKEFEATURES) -
$$QMAKEFEATURES/myfeatures.prf(для каждого каталога, перечисленного в переменной свойстваQMAKEFEATURES) -
myfeatures.prf(в корневом каталоге проекта) -
$QMAKEPATH/mkspecs/features/unix/myfeatures.prfи$QMAKEPATH/mkspecs/features/myfeatures.prf(для каждого каталога, перечисленного в переменной средыQMAKEPATH) -
$QMAKESPEC/features/unix/myfeatures.prfи$QMAKESPEC/features/myfeatures.prf -
data_install/mkspecs/features/unix/myfeatures.prfиdata_install/mkspecs/features/myfeatures.prf -
$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.
Спецификации пользовательских целей поддерживают следующие члены:
| Член | Описание |
|---|---|
| commands | Команды для генерации пользовательской цели сборки. |
| CONFIG | Конкретные параметры конфигурации для пользовательской цели сборки. Может быть установлено в recursive , чтобы указать, что правила должны создаваться в Makefile для вызова соответствующей цели внутри Makefile, специфичной для подцелей. Этот член по умолчанию создаёт запись для каждой из подцелей. |
| depends | Существующие цели сборки, от которых зависит пользовательская цель сборки. |
| recurse | Указывает, какие подцели следует использовать при создании правил в Makefile для вызова в Makefile, специфичном для подцелей. Этот член используется только при установке recursive в CONFIG. Типичные значения — "Debug" и "Release". |
| recurse_target | Указывает цель, которая должна быть собрана через Makefile подцели для правила в Makefile. Этот член добавляет что-то вроде $(MAKE) -f Makefile.[subtarget] [recurse_target]. Этот член используется только при установке recursive в CONFIG. |
| 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_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 и не должны передаваться между операционными системами, поскольку они могут содержать платформозависимую информацию.
© The Qt Company Ltd
Licensed under the GNU Free Documentation License, Version 1.3.
https://doc.qt.io/qt-5.12/qmake-advanced-usage.html