Spec-Zone.ru › Qt 5.12

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

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

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 (в корневом каталоге проекта)
  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.

Спецификации пользовательских целей поддерживают следующие члены:

Член Описание
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

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API