MyTetra Share
Делитесь знаниями!
Добавление нового функционала для настройки Qt-проектов
Время создания: 30.05.2024 09:53
Текстовые метки: qt, qmake, проект, цель, tagret, таргет, QMAKE_EXTRA_TARGETS
Раздел: Компьютер - Программирование - Язык C++ (Си++) - Библиотека Qt - Инсталляция Qt и сборка проектов
Запись: xintrea/mytetra_syncro/master/base/17170519864z1t4jrjc5/text.html на raw.github.com

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


Так же в этом разделе:
 
MyTetra Share v.0.60
Яндекс индекс цитирования