Pro file qt: qmake Project Files | Qt 4.8

Сборка подпроектов в Qt с помощью SUBDIRS

Внимание! Эта статья от 2013 года. В настоящий момент в Qt работают «подключаемые» подпроекты *. pri. Однако по ним, кроме сухой документации, информации мало.

Сборка группы проектов в qmake с помощью SUBDIRS

Представьте себе программу, имеющую плагинную архитектуру. Qt Creator тому хороший пример. Исходники таких программ должны состоять из нескольких отдельно компилируемых проектов: собственно программы и динамических библиотек плагинов. Прибавьте к этому тест-кейсы, и вполне можем получить пару десятков взаимосвязанных проектов.

Конечно, можно компилировать их по отдельности, но это неправильно. И дело здесь не только в том, что нужно нажать 5-10-20 раз на кнопку «build» вместо одного. Проекты может быть нужно строить в определенном порядке, да и банально можно пропустить какой проект. Ошибки в билде никому не нужны.

Поэтому, например, в Visual Studio для автоматизации построения группы проектов ввели понятие solution (решение), которое может содержать в себе проекты. Аналогом этого механизма в qmake является переменная SUBDIRS.

Базовый функционал SUBDIRS

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

# проект типа subdirs

TEMPLATE = subdirs

# список каталогов проектов

# в каждом каталоге должен существовать

# одноименный .pro файл: prj1/prj1.pro, prj2/prg2.pro и т.п.

SUBDIRS = prj1 prj2 prj3

# Кроме этих двух переменных толком больше писать смысла нет.

# Разве что QMAKE_EXTRA_TARGETS, о чем ниже.

Вид subdirs проекта в Qt Creator

qmake при обработке этого файла обработает — независимо друг от друга, но с одними и теми же настройками qmake — дочерние проекты в подкаталогах, после чего в каталоге программы создаст Makefile, который будет вызывать make для дочерних проектов. К примеру, make all в корневом каталоге вызовет make all во всех дочерних каталогах.

Qt Creator отлично поддерживает проекты типа subdirs. В интерфейсе Projects все наглядно отображается, можно добавлять новые проекты в контекстном меню subdirs-проекта (New Subproject…), но самое главное — это поддержка shadow builds. Весь проект типа subdirs вместе со своими дочерними проектами билдится в один shadow каталог — с повторением структуры каталогов исходников. Очень удобно.

Структура каталогов

Если дочерние проекты хочется организовать в иерархию, можно поступить двумя способами. Во-первых, можно дочерний проект сделать subdirs проектом, все будет работать. Во-вторых, можно просто указать в переменной SUBDIRS путь к подкаталогу подкаталога, например.

SUBDIRS = prj1 prj2 prj3 dir/subdir1 dir/subdir2

Но на этом история не заканчивается. Значения, перечисленные в переменной SUBDIRS, можно использовать как имена составных переменных. Если значения содержат символы, отличные от [a-zA-Z0-9_], они заменяются на -, например для dir/subdir1 имя переменной будет dir-subdir1. Странный выбор, т.к. переменные с — в имени не везде проходят мимо парсера без ошибки. Так что лучше вложенные пути не использовать напрямую, а задавать для них алиасы:

SUBDIRS += prj1

prj1.subdir = dir/prj1

# Фактически, это то же самое, что

# SUBDIRS += dir/prj1

# только вместо составной переменной dir-prj1

# теперь используется составная переменная prj1

Вместо переменной . subdir (не одновременно с ней) можно использовать переменную .file, которая позволяет явно указать путь к .pro файлу дочернего проекта, и в этом случае его имя не должно совпадать с именем каталога проекта.

SUBDIRS += prj1

prj1.file = dir/prj1/project.pro

Зависимости между проектами

Есть два способа задать порядок билда проектов (их, при желании, можно использовать одновременно). Первый — это указать настойку в переменной CONFIG, которая означает, что проекты должны компилироваться в том порядке, в котором они указаны в переменной SUBDIRS:

CONFIG += ordered

Второй способ — это явно указать зависимости между проектами.

SUBDIRS = prj1 prj2 prj3 prj4

# prj1 будет скомпилирован после prj2 и prj3

prj1.depends = prj2 prj3

В .depends имена проектов должны указываться в том же виде, в каком они указаны в переменной SUBDIRS.

Makefile и subdirs

Для проекта можно указать нестандартное имя для Makefile файла.

prj1.makefile = MyMakefile

При этом по неведомой мне причине стандартный файл с именем Makefile тоже формируется.

В корневом Makefile (который получается из .pro файла subdir-проекта) все дочерние проекты оформляются как набор отдельных целей. Префикс для этих целей имеет вид sub-имя_переменной_проекта. Например, для проекта prg1 цели будет иметь вид в духе sub-prg1-sub_Debug. Префикс для целей можно поменять:

# цели будут иметь вид customtarget-sub_Debug

prj1.target = customtarget

И последнее. В корневой Makefile можно добавлять свои цели с помощью рассмотренного ранее механизма QMAKE_EXTRA_TARGETS. Просто цель не представляет собой интересна, но в режиме recursive этот механизм может быть полезен.

customtarget.target = check

customtarget.CONFIG = recursive

customtarget.commands = @echo Check is completed.

QMAKE_EXTRA_TARGETS += customtarget

Чтобы это работало, в дочерних проектах должны быть определены цели check. После этого вызов make check в корневом каталоге выполнит make check для всех дочерних проектов. Можно в Qt Creator для этого отдельный конфиг настроить, например.

Небольшая автоматизация

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

# addSubdirs(subdirs,deps): добавляет subdirs (может быть маской) вместе с зависимостями

# пути могут быть как с прямыми, так и с обратными слэшами

defineReplace(addSubdirs) {

  for(subdirs, 1) {

    entries = $$files($$subdirs)

    for(entry, entries) {

      name = $$replace(entry, [/\\\\], _)

      SUBDIRS += $$name

      eval ($${name}.subdir = $$entry)

      for(dep, 2):eval ($${name}.depends += $$replace(dep, [/\\\\], _))

      export ($${name}.subdir)

      export ($${name}.depends)

    }

  }

  export(SUBDIRS)

  return(1)

}

# добавляет все проекты из каталога dir, и делает их зависимыми от проекта lib

$$addSubdirs(dir/*, lib)

Примечание: В посте есть неточность, цитирую:

«qmake при обработке этого файла обработает – независимо друг от друга, но с одними и теми же настройками qmake – дочерние проекты в подкаталогах, после чего в каталоге программы создаст Makefile, который будет вызывать make для дочерних проектов. »

На самом деле qmake не бегает по подкаталогам, а тупо из списка SUBDIRS накидает цели в корневой Makefile и каждая цель содержит 1 команду – запуск qmake в конкретном подкаталоге. То есть pro-файлы в подкаталогах обработаются потом – во время запуска make из корневого каталога, а не во время работы “корневого” qmake. Иначе говоря, Makefile в каталоге программы будет вызывать qmake, а не make, для дочерних проектов.

По крайней мере проверено на Windows 7 x64, Qt 5.3.2, MS VC++ 2013.

Создание файлов проекта | qmake Руководство

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

Элементы файла проекта

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

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

Переменные

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

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

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

В следующем фрагменте показано, как списки значений присваиваются переменным:

 ЗАГОЛОВКИ = главное окно.h paintwidget.h 

Список значений переменной расширяется следующим образом:

 ИСТОЧНИКИ = main.cpp mainwindow.cpp \
          paintwidget.cpp
КОНФИГУРАЦИЯ + = консоль 

Примечание: Первое присвоение включает только значения, которые указаны в той же строке, что и переменная HEADERS . Второе присвоение разбивает значения в переменной SOURCES по строкам с помощью обратной косой черты (\).

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

В следующей таблице перечислены некоторые часто используемые переменные и описано их содержимое. Полный список переменных и их описания см. В разделе «Переменные».

Переменная	Содержание
КОНФИГУРАЦИЯ	Общие параметры конфигурации проекта.
DESTDIR	Каталог, в который будет помещен исполняемый или двоичный файл.
ФОРМЫ	Список файлов пользовательского интерфейса, которые будут обрабатываться компилятором пользовательского интерфейса (uic).
ЗАГОЛОВКИ	Список имён файлов заголовков (.h), используемых при построении проекта.
QT	Список модулей Qt, используемых в проекте.
РЕСУРСЫ	Список файлов ресурсов (.qrc), которые будут включены в окончательный проект. Дополнительную информацию об этих файлах смотрите в системе ресурсов Qt.
ИСТОЧНИКИ	Список файлов исходного кода, которые будут использоваться при сборке проекта.
TEMPLATE	Шаблон для использования в проекте. Это определяет, будет ли результатом процесса сборки приложение, библиотека или плагин.

Содержимое переменной можно прочитать, добавив к имени переменной $$ . Это можно использовать для присвоения содержимого одной переменной другой:

Оператор $$ широко используется со встроенными функциями, которые работают со строками и списками значений.Для получения дополнительной информации см. Qmake Language.

Пробел

Обычно при присвоении переменных значения разделяются пробелами. Чтобы указать значения, содержащие пробелы, вы должны заключить значения в двойные кавычки:

Цитируемый текст рассматривается как отдельный элемент в списке значений, содержащихся в переменной. Аналогичный подход используется для работы с путями, содержащими пробелы, особенно при определении переменных INCLUDEPATH и LIBS для платформы Windows:

 win32: INCLUDEPATH + = "C: / mylibs / extra headers"
unix: INCLUDEPATH + = "/ home / user / extra headers" 

Вы можете добавлять комментарии к файлам проекта. Комментарии начинаются с символа # и продолжаются до конца той же строки. Например:

 # Комментарии обычно начинаются в начале строки, но они
# также может следовать за другим контентом в той же строке. 

Чтобы включить символ # в присвоение переменных, необходимо использовать содержимое встроенной переменной LITERAL_HASH.

Встроенные функции и поток управления

qmake предоставляет ряд встроенных функций, позволяющих обрабатывать содержимое переменных.Наиболее часто используемой функцией в простых файлах проекта является функция include (), которая принимает имя файла в качестве аргумента. Содержимое данного файла включается в файл проекта в том месте, где используется функция include . Функция include чаще всего используется для включения других файлов проекта:

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

 win32 {
    ИСТОЧНИКИ + = paintwidget_win. cpp
} 

Назначения внутри фигурных скобок выполняются, только если условие истинно. В этом случае должна быть установлена ​​опция win32 CONFIG. В Windows это происходит автоматически. Открывающая скобка должна стоять на той же линии, что и условие.

Более сложные операции с переменными, которые обычно требуют циклов, предоставляются встроенными функциями, такими как find (), unique () и count (). Эти и многие другие функции предназначены для управления строками и путями, поддержки ввода данных пользователем и вызова внешних инструментов.Для получения дополнительной информации об использовании функций см. Qmake Language. Список всех функций и их описания см. В разделах «Функции замены» и «Функции тестирования».

Шаблоны проектов

Переменная TEMPLATE используется для определения типа проекта, который будет построен. Если это не объявлено в файле проекта, qmake предполагает, что приложение должно быть построено, и сгенерирует соответствующий Makefile (или эквивалентный файл) для этой цели.

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

Шаблон	Выход qmake
приложение (по умолчанию)	Makefile для создания приложения.
lib	Makefile для сборки библиотеки.
aux	Makefile, который ничего не строит. Используйте это, если не нужно вызывать компилятор для создания цели, например, потому что ваш проект написан на интерпретируемом языке. Примечание: Этот тип шаблона доступен только для генераторов на основе Makefile. В частности, он не будет работать с генераторами vcxproj и Xcode.
подкаталоги	Makefile, содержащий правила для подкаталогов, указанных с помощью переменной SUBDIRS.Каждый подкаталог должен содержать собственный файл проекта.
vcapp	Visual Studio Файл проекта для создания приложения.
vclib	Файл проекта Visual Studio для создания библиотеки.
vcsubdirs	Файл решения Visual Studio для создания проектов в подкаталогах.

См. Раздел Создание общих типов проектов для получения советов по написанию файлов проекта для проектов, использующих шаблоны app и lib .

Когда используется шаблон подкаталогов , qmake генерирует Makefile для проверки каждого указанного подкаталога, обработки любого файла проекта, который он там находит, и запуска инструмента make платформы на вновь созданном Makefile. SUBDIRS Переменная используется для хранения списка всех подкаталогов для обработки.

Общая конфигурация

Переменная CONFIG определяет параметры и функции, с которыми должен быть настроен проект.

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

Добавление параметра build_all к переменной CONFIG делает это правило по умолчанию при построении проекта.

Примечание: Каждая из опций, указанных в переменной CONFIG , также может использоваться в качестве условия области. Вы можете проверить наличие определенных параметров конфигурации, используя встроенную функцию CONFIG (). Например, следующие строки показывают функцию как условие в области видимости, чтобы проверить, используется ли только опция opengl :

 CONFIG (opengl) {
    сообщение (Сборка с поддержкой OpenGL.)
} еще {
    сообщение (поддержка OpenGL недоступна.)
} 

Это позволяет определять различные конфигурации для сборок выпуска и отладки . Для получения дополнительной информации см. Использование областей.

Следующие параметры определяют тип строящегося проекта.

Примечание: Некоторые из этих параметров действуют только при использовании на соответствующей платформе.

Шаблоны проектов приложений и библиотек предоставляют более специализированные параметры конфигурации для точной настройки процесса сборки. Параметры подробно описаны в разделе Создание общих типов проектов.

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

Примечание: Вы должны использовать «+ =», а не «=», иначе qmake не сможет использовать конфигурацию Qt для определения настроек, необходимых для вашего проекта.

Объявление библиотек Qt

Если переменная CONFIG содержит значение qt , qmake поддерживает приложения Qt.Это позволяет точно настроить, какие из модулей Qt используются вашим приложением. Это достигается с помощью переменной QT, которую можно использовать для объявления необходимых модулей расширения. Например, мы можем включить XML и сетевые модули следующим образом:

Примечание: QT по умолчанию включает модули ядра и gui , поэтому приведенное выше объявление добавляет сетевых и XML-модулей в этот список по умолчанию. Следующее назначение пропускает модулей по умолчанию и приведет к ошибкам при компиляции исходного кода приложения:

 QT = network xml # При этом будут опущены модули core и gui.

Если вы хотите собрать проект без модуля gui , вам необходимо исключить его с помощью оператора «- =». По умолчанию QT содержит как core , так и gui , поэтому следующая строка приведет к созданию минимального проекта Qt:

 QT - = gui # Используется только основной модуль. 

Список модулей Qt, которые вы можете добавить к переменной QT , смотрите в QT.

Особенности конфигурации

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

Например, qmake может настроить процесс сборки для использования преимуществ внешних библиотек, поддерживаемых pkg-config, таких как библиотеки D-Bus и ogg, с помощью следующих строк:

 КОНФИГУРАЦИЯ + = link_pkgconfig
PKGCONFIG + = ogg dbus-1 

Для получения дополнительной информации о добавлении функций см. Добавление новых функций конфигурации.

Объявление других библиотек

Если вы используете в своем проекте другие библиотеки в дополнение к тем, которые поставляются с Qt, вам необходимо указать их в файле проекта.

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

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

 LIBS + = -L / usr / локальный / lib -lmath 

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

Например, чтобы добавить несколько путей для поиска файлов заголовков:

 INCLUDEPATH = c: / msdev / include d: / stl / include 

файлов проекта qmake | Qt 4.8

Файлы проекта

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

Элементы файла проекта

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

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

Переменные

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

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

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

Следующие строки показывают, как списки значений присваиваются переменным:

 ЗАГОЛОВКИ = mainwindow. h paintwidget.h 

Обратите внимание, что первое присвоение включает только значения, которые указаны в той же строке, что и переменная SOURCES . Второе присвоение разбивает элементы по строкам с помощью символа \ .

Список значений переменной расширяется следующим образом:

 ИСТОЧНИКИ = main.cpp mainwindow.cpp \
          paintwidget.cpp
КОНФИГУРАЦИЯ + = qt 

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

В следующей таблице перечислены переменные, которые распознает qmake , и описано, что они должны содержать.

Переменная	Содержание
КОНФИГУРАЦИЯ	Общие параметры конфигурации проекта.
DESTDIR	Каталог, в который будет помещен исполняемый или двоичный файл.
ФОРМЫ	Список файлов пользовательского интерфейса, которые будут обрабатываться uic .
ЗАГОЛОВКИ	Список имён файлов заголовков (.h), используемых при построении проекта.
QT	Параметры конфигурации, специфичные для Qt.
РЕСУРСЫ	Список файлов ресурсов (.rc), которые будут включены в окончательный проект. Дополнительную информацию об этих файлах смотрите в системе ресурсов Qt.
ИСТОЧНИКИ	Список файлов исходного кода, которые будут использоваться при сборке проекта.
TEMPLATE	Шаблон для использования в проекте. Это определяет, будет ли результатом процесса сборки приложение, библиотека или плагин.

Содержимое переменной можно прочитать, добавив к имени переменной $$ .Это можно использовать для присвоения содержимого одной переменной другой:

Оператор $$ широко используется со встроенными функциями, которые работают со строками и списками значений. Они описаны в главе о расширенном использовании qmake.

Пробел

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

Цитируемый текст рассматривается как отдельный элемент в списке значений, содержащихся в переменной.Аналогичный подход используется для работы с путями, содержащими пробелы, особенно при определении переменных INCLUDEPATH и LIBS для платформы Windows:

 win32: INCLUDEPATH + = "C: / mylibs / extra headers"
unix: INCLUDEPATH + = "/ home / user / extra headers" 

Комментарии

Вы можете добавлять комментарии к файлам проекта. Комментарии начинаются с символа # и продолжаются до конца той же строки. Например:

 # Комментарии обычно начинаются в начале строки, но они
# также может следовать за другим контентом в той же строке.

Чтобы включить символ # в присвоение переменных, необходимо использовать содержимое встроенной переменной LITERAL_HASH . См. Ссылку на переменную для получения дополнительной информации.

Встроенные функции и поток управления

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

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

 win32 {
    ИСТОЧНИКИ + = paintwidget_win. cpp
} 

Назначения внутри фигурных скобок выполняются, только если условие истинно.В этом случае должна быть установлена ​​специальная переменная win32 ; это происходит автоматически в Windows, но это также можно указать на других платформах, запустив qmake с опцией командной строки -win32 (дополнительную информацию см. в разделе Запуск qmake). Открывающая скобка должна стоять на той же линии, что и условие.

Простые циклы создаются путем перебора списков значений с использованием встроенной функции для . Следующий код добавляет каталоги в переменную SUBDIRS, но только если они существуют:

 EXTRAS = обработчики, тесты, документы
for (dir, EXTRAS) {
    существует ($$ dir) {
        SUBDIRS + = $$ dir
    }
} 

Более сложные операции с переменными, которые обычно требуют циклов, выполняются встроенными функциями, такими как find , unique и count .Эти и многие другие функции предназначены для управления строками и путями, поддержки ввода данных пользователем и вызова внешних инструментов. Список доступных функций можно найти в главе «Расширенное использование qmake» этого руководства.

Шаблоны проектов

Переменная TEMPLATE используется для определения типа проекта, который будет построен. Если это не объявлено в файле проекта, qmake предполагает, что приложение должно быть построено, и сгенерирует соответствующий Makefile (или эквивалентный файл) для этой цели.

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

Шаблон	Описание qmake output
app (по умолчанию)	Создает Makefile для сборки приложения.
lib	Создает Makefile для сборки библиотеки.
subdirs	Создает Makefile, содержащий правила для подкаталогов, указанных с помощью переменной SUBDIRS. Каждый подкаталог должен содержать собственный файл проекта.
vcapp	Создает файл проекта Visual Studio для сборки приложения.
vclib	Создает файл проекта Visual Studio для сборки библиотеки.
vcsubdirs	Создает файл решения Visual Studio для сборки проектов в подкаталогах.

См. Руководство по qmake для советов по написанию файлов проектов для проектов, использующих шаблоны app и lib .

Когда используется шаблон subdirs , qmake генерирует Makefile для проверки каждого указанного подкаталога, обработки любого файла проекта, который он там находит, и запуска инструмента make платформы на вновь созданном Makefile. Переменная SUBDIRS используется для хранения списка всех подкаталогов для обработки.

Общая конфигурация

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

Следующие параметры управляют флагами компилятора, которые используются для сборки проекта:

Опция	Описание
релиз	Проект должен быть построен в режиме релиза. Это игнорируется, если также указан debug .
отладка	Проект должен быть построен в режиме отладки.
debug_and_release	Проект построен в в обоих режимах отладки и выпуска .
debug_and_release_target	Проект построен в в обоих режимах отладки и выпуска . TARGET встроен в каталоги и отладки и выпуска.
build_all	Если указано debug_and_release , проект по умолчанию создается как в режиме отладки, так и в режиме выпуска.
autogen_precompile_source	Автоматически создает .cpp , который включает предварительно скомпилированный файл заголовка, указанный в файле .pro.
заказано	При использовании шаблона subdirs эта опция указывает, что перечисленные каталоги должны обрабатываться в том порядке, в котором они указаны.
warn_on	Компилятор должен выводить как можно больше предупреждений. Это игнорируется, если указано warn_off .
warn_off	Компилятор должен выводить как можно меньше предупреждений.
copy_dir_files	Разрешает правилу установки также копировать каталоги, а не только файлы.

Параметр debug_and_release является особенным, поскольку он позволяет создавать как отладочную, так и выпускную версии проекта. В таком случае Makefile, который генерирует qmake , включает правило, которое строит обе версии, и его можно вызвать следующим образом:

Добавление параметра build_all к переменной CONFIG делает это правило используемым по умолчанию при сборке проекта, и цели установки будут созданы как для отладочной, так и для выпускной сборок.

Обратите внимание, что каждая из опций, указанных в переменной CONFIG , также может использоваться как условие области. Вы можете проверить наличие определенных параметров конфигурации, используя встроенную функцию CONFIG (). Например, следующие строки показывают функцию как условие в области видимости, чтобы проверить, используется ли только опция opengl :

 CONFIG (opengl) {
    сообщение (Сборка с поддержкой OpenGL.)
} еще {
    сообщение (поддержка OpenGL недоступна.)
} 

Это позволяет определять различные конфигурации для сборок выпуска и отладки , что более подробно описано в разделе «Области действия» главы «Расширенное использование» данного руководства.

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

При использовании шаблонов проектов приложений или библиотек можно использовать более специализированные параметры конфигурации для точной настройки процесса сборки. Они подробно описаны в главе «Общие проекты» данного руководства.

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

 КОНФИГУРАЦИЯ + = отладка потока qt 

Обратите внимание, что вы должны использовать «+ =», а не «=», иначе qmake не сможет использовать конфигурацию Qt для определения настроек, необходимых для вашего проекта. Более подробную информацию об операторах можно найти в разделе «Операторы» главы «Расширенное использование» qmake.

Объявление библиотек Qt

Если переменная CONFIG содержит значение qt , qmake поддерживает приложения Qt. Это позволяет точно настроить, какие из модулей Qt используются вашим приложением. Это достигается с помощью переменной QT , которую можно использовать для объявления необходимых модулей расширения. Например, мы можем включить XML и сетевые модули следующим образом:

 КОНФИГУРАЦИЯ + = qt
QT + = сеть xml 

Обратите внимание, что QT по умолчанию включает модули ядра и gui , поэтому приведенное выше объявление добавляет сетевых и XML-модулей в этот список по умолчанию. Следующее назначение пропускает модулей по умолчанию и приведет к ошибкам при компиляции исходного кода приложения:

 QT = network xml # При этом будут опущены модули core и gui. 

Если вы хотите собрать проект без модуля gui , вам необходимо исключить его с помощью оператора «- =». По умолчанию QT содержит как core , так и gui , поэтому следующая строка приведет к созданию минимального проекта Qt:

 QT - = gui # Используется только основной модуль.

Дополнительную информацию об операторах можно найти в разделе «Операторы» главы «Расширенное использование qmake».

В таблице ниже показаны параметры, которые можно использовать с переменной QT , и функции, связанные с каждой из них:

Обратите внимание, что добавление опции opengl к переменной QT автоматически вызывает добавление эквивалентной опции к переменной CONFIG . Следовательно, для приложений Qt нет необходимости добавлять опцию opengl как в CONFIG , так и в QT .

Особенности конфигурации

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

Например, qmake может настроить процесс сборки для использования преимуществ внешних библиотек, поддерживаемых pkg-config, таких как библиотеки D-Bus и ogg, с помощью следующих строк:

 КОНФИГУРАЦИЯ + = link_pkgconfig
PKGCONFIG + = ogg dbus-1 

Дополнительную информацию о функциях можно найти в разделе «Добавление новых функций конфигурации» главы «Расширенное использование qmake».

Объявление других библиотек

Если вы используете в своем проекте другие библиотеки в дополнение к тем, которые поставляются с Qt, вам необходимо указать их в файле проекта.

Пути, по которым qmake ищет библиотеки и конкретные библиотеки для компоновки, могут быть добавлены в список значений в переменной LIBS. Можно указать пути к самим библиотекам или при желании можно использовать знакомую нотацию в стиле Unix для указания библиотек и путей.

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

 LIBS + = -L / usr / локальный / lib -lmath 

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

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

 INCLUDEPATH = c: / msdev / include d: / stl / include 

10-минутное руководство по использованию qmake

10-минутное руководство по использованию qmake

[Предыдущая: Установка qmake] [На главную] [Следующая: Учебное пособие по qmake]

10-минутное руководство по использованию qmake

Создание файла проекта

qmake использует информацию, хранящуюся в файле проекта (. pro), чтобы определить, что должно быть в создаваемых make-файлах.

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

Вот простой пример файла проекта:

    ИСТОЧНИКИ = hello.cpp
    ЗАГОЛОВКИ = hello.h
    CONFIG + = qt warn_on release
 

Мы дадим краткое построчное объяснение, откладывая детали на более поздний срок в руководстве.

    ИСТОЧНИКИ = hello.cpp
 

В этой строке указываются исходные файлы, реализующие приложение. В этом случае есть только один файл, hello.cpp . Большинству приложений требуется несколько файлов; эта ситуация решается путем перечисления всех файлов на одной строке, разделенных пробелом, например:

    ИСТОЧНИКИ = hello.cpp main.cpp
 

В качестве альтернативы каждый файл может быть указан в отдельной строке, экранируя символы новой строки, например:

    ИСТОЧНИКИ = привет. cpp \
                main.cpp
 

Более подробный подход — перечислить каждый файл отдельно, например:

    ИСТОЧНИКИ + = hello.cpp
    ИСТОЧНИКИ + = main.cpp
 

В этом подходе используется «+ =», а не «=», что более безопасно, потому что он всегда добавляет новый файл в существующий список, а не заменяет список.

Строка HEADERS используется для указания файлов заголовков, созданных для использования приложением, например

    ЗАГОЛОВКИ + = hello.h
 

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

Строка CONFIG используется для предоставления qmake информации о конфигурации приложения.

    CONFIG + = qt warn_on release
 

Здесь используется «+ =», потому что мы добавляем наши параметры конфигурации к уже имеющимся. Это безопаснее, чем использование «=», которое заменяет все параметры только указанными.

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

Часть warn_on строки CONFIG сообщает qmake , что он должен установить флаги компилятора, чтобы выводились предупреждения.

Часть выпуска в строке CONFIG сообщает qmake , что приложение должно быть создано как приложение выпуска. Во время разработки программисты могут предпочесть заменить выпуск на отладочный , который обсуждается позже.

Файлы проекта представляют собой обычный текст (т. Е. Используйте редактор, например блокнот, vim или xemacs) и должны сохраняться с расширением ‘.pro ‘расширение. Имя исполняемого файла приложения будет таким же, как имя файла проекта, но с расширением, соответствующим платформе. Например, файл проекта с именем hello.pro создаст hello.exe в Windows и hello в Unix.

Создание файла сборки

Когда вы создали свой файл проекта, очень легко создать make-файл, все, что вам нужно сделать, это перейти туда, где вы создали файл проекта, и ввести:

Makefile генерируются из файлов ‘. pro ‘файлы вроде этого:

    qmake -o Makefile hello.pro
 

Для пользователей Visual Studio qmake также может создавать файлы .dsp, например:

    qmake -t vcapp -o hello.dsp hello.pro
 

[Предыдущая: Установка qmake] [На главную] [Следующая: Учебное пособие по qmake]

Переменные | qmake Руководство

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

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

ANDROID_ABI

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает целевой ABI Android. Допустимые значения: armeabi-v7a, arm64-v8a, x86, x86_64.

ANDROID_ABIS

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает список целевых ABI Android. Допустимые значения: armeabi-v7a, arm64-v8a, x86, x86_64.

Вы можете указать ABI в качестве аргумента qmake:

 qmake ANDROID_ABIS = "armeabi-v7a arm64-v8a" 

Примечание: Эту переменную можно использовать внутри *.pro, однако, это не рекомендуется, поскольку он переопределит любые ABI, указанные в командной строке qmake .

ANDROID_API_VERSION

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает номер уровня Android API. Для получения дополнительной информации см. Номера сборки Android.

ANDROID_BUNDLED_JAR_DEPENDENCIES

Примечание: Эта переменная применяется только к модулям Android.

Это полезно при написании модуля Qt.Он определяет список предварительно связанных зависимостей, используемых модулем, в формате .jar , например:

 ANDROID_BUNDLED_JAR_DEPENDENCIES + = jar / QtAndroid.jar 

ANDROID_DEPLOYMENT_DEPENDENCIES

Примечание. Эта переменная применяется только к целевым объектам Android.

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

Примечание: Включаются только файлы Qt, указанные с помощью этой переменной. Отсутствие всех правильных файлов может привести к сбоям. Также важно убедиться, что файлы указаны в правильном порядке загрузки. Эта переменная позволяет полностью переопределить автоматическое обнаружение, поэтому, если библиотека указана перед ее зависимостями, она не сможет загрузиться на некоторых устройствах.

ANDROID_DEPLOYMENT_SETTINGS_FILE

Примечание. Эта переменная применяется только к целевым объектам Android.

Указывает путь к файлу android-deployment-settings.json , необходимому для androiddeployqt и androidtestrunner . Это переопределяет путь к файлу настроек, сгенерированному qmake, поэтому вы должны убедиться, что предоставили действительный файл настроек.

ANDROID_EXTRA_LIBS

Примечание. Эта переменная применяется только к целевым объектам Android.

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

Чтобы включить внешние библиотеки для нескольких ABI, где каждый ABI имеет свой собственный каталог, используйте следующее:

 для (abi, ANDROID_ABIS): ANDROID_EXTRA_LIBS + = $$ PWD / $$ {abi} /library_name.so 

В противном случае, если ABI включен в имя библиотеки, используйте следующее:

 для (abi, ANDROID_ABIS): ANDROID_EXTRA_LIBS + = $$ PWD / имя_библиотеки _ $$ {abi}.так 

ANDROID_EXTRA_PLUGINS

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает путь к подключаемым модулям C ++ или ресурсам, которые ваше приложение должно объединить, но которые не могут быть доставлены через систему ресурсов, например подключаемые модули QML. С помощью этой переменной androiddeployqt будет следить за тем, чтобы все было правильно упаковано и развернуто.

ANDROID_EXTRA_PLUGINS должен указывать на каталог, в котором созданы дополнительные подключаемые модули.Кроме того, структура каталога сборки должна соответствовать соглашению об именах, аналогичному подключаемым модулям Qt, то есть подключаемых модулей / <имя подключаемого модуля> .

Библиотеки плагинов должны иметь формат имени libplugins_ _ _ .so . Для этого файл плагина pro может быть определен следующим образом:

 ШАБЛОН = lib
CONFIG + = плагин

PLUGIN_TYPE = форматы изображений
DESTDIR = $$ top_builddir / plugins / myplugin
TARGET = $$ qt5LibraryTarget (myplugin, "плагины / $$ PLUGIN_TYPE /") 

с top_builddir, определенным в.qmake.conf как:

 top_builddir = $$ shadowed ($$ PWD) 

Это гарантирует, что к библиотеке подключаемых модулей применяется правильное изменение имени ( plugins / myplugin / libplugins_imageformats_myplugin_armeabi-v7a.so ).

Затем, предполагая, что дополнительный модуль формата изображения myplugin построен как $$ DESTDIR / plugins / myplugin / , следующее гарантирует, что он упакован правильно:

 ANDROID_EXTRA_PLUGINS + = $$ top_builddir / плагины 

ANDROID_FEATURES

Примечание: Эта переменная применяется только к модулям Android.

Определяет список функций модуля:

 ANDROID_FEATURES + = android.hardware.location.gps 

Для получения дополнительной информации см. Документы Android .

ANDROID_LIB_DEPENDENCIES

Примечание: Эта переменная применяется только к модулям Android.

Это полезно при написании модуля Qt. Он определяет список предварительно созданных зависимостей, используемых модулем, например:

 ANDROID_LIB_DEPENDENCIES + = \
    плагины / libplugins_platforms_qtforandroid.так 

ANDROID_MIN_SDK_VERSION

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает минимальный уровень Android API для проекта. По умолчанию для этой переменной установлен уровень API 21.

ANDROID_PACKAGE_SOURCE_DIR

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает путь для настраиваемого шаблона пакета Android. Шаблон пакета Android содержит:

• AndroidManifest.xml файл
• файл build.gradle и другие скрипты Gradle
• файл res / values ​​/ libs.xml

Путь, указанный в этой переменной, может содержать пользовательские классы Java в каталоге src . По умолчанию инструмент androiddeployqt копирует шаблон приложения из пути установки Qt для Android в каталог сборки вашего проекта, а затем поверх него копирует содержимое пути, указанного в этой переменной, перезаписывая любые существующие файлы. Например, вы можете создать собственный файл AndroidManifest.xml для вашего приложения, а затем поместите его непосредственно в каталог, указанный в этой переменной.

ANDROID_PERMISSIONS

Примечание: Эта переменная применяется только к модулям Android.

Определяет список разрешений модуля:

 ANDROID_PERMISSIONS + = android.permission.ACCESS_FINE_LOCATION 

Для получения дополнительной информации см. Документы Android .

ANDROID_TARGET_SDK_VERSION

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает целевой уровень Android API для проекта. По умолчанию для этой переменной задан уровень API 29.

ANDROID_VERSION_CODE

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает номер версии приложения. Для получения дополнительной информации см. Управление версиями приложений Android.

ANDROID_VERSION_NAME

Примечание. Эта переменная применяется только к целевым объектам Android.

Задает версию приложения в виде удобочитаемой строки.Для получения дополнительной информации см. Управление версиями приложений Android.

КОНФИГУРАЦИЯ

Задает конфигурацию проекта и параметры компилятора. Значения распознаются внутри qmake и имеют особое значение.

Следующие значения CONFIG управляют флагами компилятора и компоновщика:

Опция	Описание
релиз	Проект должен быть построен в режиме релиза. Если также указан debug , последний вступает в силу.
отладка	Проект должен быть построен в режиме отладки.
debug_and_release	Проект подготовлен для сборки в в обоих режимах отладки и выпуска .
debug_and_release_target	Этот параметр установлен по умолчанию. Если debug_and_release также задано, сборки отладки и выпуска попадают в отдельные каталоги отладки и выпуска.
build_all	Если указано debug_and_release , проект по умолчанию создается как в режиме отладки, так и в режиме выпуска.
autogen_precompile_source	Автоматически создает файл .cpp , который включает предварительно скомпилированный файл заголовка, указанный в файле .pro.
заказано	При использовании шаблона subdirs эта опция указывает, что перечисленные каталоги должны обрабатываться в том порядке, в котором они указаны. Примечание: Использование этой опции не рекомендуется. Укажите зависимости, как описано в документации по переменной SUBDIRS.
precompile_header	Включает поддержку использования предварительно скомпилированных заголовков в проектах.
precompile_header_c (только MSVC)	Включает поддержку использования предварительно скомпилированных заголовков для файлов C.
warn_on	Компилятор должен выводить как можно больше предупреждений. Если также указано warn_off , действует последний.
warn_off	Компилятор должен выводить как можно меньше предупреждений.
исключения	Поддержка исключений включена. По умолчанию.
exceptions_off	Поддержка исключений отключена.
ltcg	Генерация временного кода соединения включена. По умолчанию этот параметр отключен.
rtti	Поддержка RTTI включена. По умолчанию используется компилятор по умолчанию.
rtti_off	Поддержка RTTI отключена. По умолчанию используется компилятор по умолчанию.
stl	Поддержка STL включена. По умолчанию используется компилятор по умолчанию.
stl_off	Поддержка STL отключена. По умолчанию используется компилятор по умолчанию.
поток	Поддержка потоков включена. Это включено, если CONFIG включает qt , что является значением по умолчанию.
utf8_source	Указывает, что исходные файлы проекта используют кодировку UTF-8. По умолчанию используется компилятор по умолчанию.
hide_symbols	Установить скрытую видимость символов в двоичном файле по умолчанию. По умолчанию используется компилятор по умолчанию.
c99	Поддержка C99 включена. Этот параметр не действует, если компилятор не поддерживает C99 или не может выбрать стандарт C. По умолчанию используется компилятор по умолчанию.
c11	Поддержка C11 включена. Этот параметр не действует, если компилятор не поддерживает C11 или не может выбрать стандарт C.По умолчанию используется компилятор по умолчанию.
strict_c	Отключает поддержку расширений компилятора C. По умолчанию они включены.
c ++ 11	Поддержка C ++ 11 включена. Этот параметр не действует, если компилятор не поддерживает C ++ 11 или не может выбрать стандарт C ++. По умолчанию поддержка включена.
c ++ 14	Поддержка C ++ 14 включена. Этот параметр не действует, если компилятор не поддерживает C ++ 14 или не может выбрать стандарт C ++. По умолчанию используется компилятор по умолчанию.
c ++ 1z	Поддержка C ++ 17 включена. Этот параметр не действует, если компилятор не поддерживает C ++ 17 или не может выбрать стандарт C ++. По умолчанию поддержка отключена.
c ++ 17	То же, что и c ++ 1z.
c ++ 2a	Поддержка C ++ 2a включена. Этот параметр не действует, если компилятор не поддерживает C ++ 2a или не может выбрать стандарт C ++. По умолчанию поддержка отключена.
c ++ latest	Включена поддержка последнего стандарта языка C ++, который поддерживается компилятором. По умолчанию эта опция отключена.
strict_c ++	Отключает поддержку расширений компилятора C ++. По умолчанию они включены.
depends_includepath	Добавление значения INCLUDEPATH к DEPENDPATH включено. По умолчанию.
lrelease	Запустите lrelease для всех файлов, перечисленных в TRANSLATIONS и EXTRA_TRANSLATIONS.Если embed_translations не задано, установите сгенерированные файлы .qm в QM_FILES_INSTALL_PATH. Используйте QMAKE_LRELEASE_FLAGS, чтобы добавить параметры к вызову lrelease. По умолчанию не установлено.
embed_translations	Вставьте сгенерированные переводы из lrelease в исполняемый файл под QM_FILES_RESOURCE_PREFIX. Также требуется установка lrelease . По умолчанию не установлено.
create_libtool	Создайте libtool.la для созданной в настоящее время библиотеки.
create_pc	Создайте файл pkg-config .pc для текущей собранной библиотеки.
no_batch	Только NMake: отключение генерации пакетных правил NMake или правил вывода.
skip_target_version_ext	Отключить автоматический номер версии, добавляемый к имени файла DLL в Windows.
suppress_vcproj_warnings	Подавить предупреждения генератора проектов VS.
windeployqt	Автоматически вызывать windeployqt после связывания и добавлять выходные данные как элементы развертывания.
dont_recurse	Подавить рекурсию qmake для текущего подпроекта.
no_include_pwd	Не добавлять текущий каталог в INCLUDEPATHS.

Когда вы используете опцию debug_and_release (которая используется по умолчанию в Windows), проект будет обработан три раза: один раз для создания «мета» Makefile и еще два раза для создания Makefile.Отладка и Makefile.

Во время последних проходов build_pass и соответствующая опция debug или release добавляются к CONFIG . Это позволяет выполнять задачи, специфичные для сборки. Например:

 build_pass: CONFIG (отладка, отладка | выпуск) {
    unix: TARGET = $$ join (TARGET ,,, _ отладка)
    иначе: TARGET = $$ join (TARGET ,,, d)
} 

В качестве альтернативы ручному написанию условных операторов типа сборки некоторые переменные предлагают варианты, специфичные для сборки, например QMAKE_LFLAGS_RELEASE в дополнение к общему QMAKE_LFLAGS.Их следует использовать, когда они доступны.

Мета-файл Makefile делает под-сборки вызываемыми через цели debug и release , а также комбинированную сборку через цель all . Когда используется опция build_all CONFIG , по умолчанию используется комбинированная сборка. В противном случае последняя указанная опция CONFIG из набора ( debug , release ) определяет значение по умолчанию. В этом случае вы можете явно вызвать цель all для создания обеих конфигураций одновременно:

Примечание: Детали немного отличаются при создании проектов Visual Studio и Xcode.

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

Опция	Описание
create_prl	Эта опция позволяет qmake отслеживать эти зависимости. Когда эта опция включена, qmake создаст файл с расширением .prl , который сохранит метаинформацию о библиотеке (дополнительную информацию см. в разделе «Зависимости библиотеки»).
link_prl	Когда эта опция включена, qmake обработает все библиотеки, связанные с приложением, и найдет их метаинформацию (дополнительную информацию см. В разделе «Зависимости библиотек»).
no_install_prl	Этот параметр отключает создание правил установки для сгенерированных файлов . prl.

Примечание: Параметр create_prl требуется, когда строит статическую библиотеку, а link_prl требуется, когда использует статическую библиотеку.

Следующие параметры определяют тип приложения или библиотеки:

Опция	Описание
qt	Целевым объектом является приложение или библиотека Qt, для которого требуется библиотека Qt и файлы заголовков. Правильные пути включения и библиотеки для библиотеки Qt будут автоматически добавлены в проект. Это определено по умолчанию, и его можно точно настроить с помощью переменной \ l {#qt} {QT} .
x11	Целевой объект — приложение или библиотека X11.Правильные пути включения и библиотеки будут автоматически добавлены в проект.
testcase	Цель — автоматизированный тест. Цель проверки будет добавлена ​​в созданный Makefile для запуска теста. Актуально только при создании файлов Makefile.
insignificant_test	Код выхода автоматического теста игнорируется. Уместно, только если также установлен testcase .
windows	Целевым является оконное приложение Win32 (только приложение).Правильные пути включения, флаги компилятора и библиотеки будут автоматически добавлены в проект.
консоль	Целевой объект — консольное приложение Win32 (только приложение). Правильные пути включения, флаги компилятора и библиотеки будут автоматически добавлены в проект. Рассмотрите возможность использования опции cmdline для кроссплатформенных приложений.
cmdline	Целевой объект — кроссплатформенное приложение командной строки. В Windows это означает CONFIG + = console .В macOS это означает CONFIG - = app_bundle .
общий	Целевой объект — общий объект / DLL. Правильные пути включения, флаги компилятора и библиотеки будут автоматически добавлены в проект. Обратите внимание, что dll также можно использовать на всех платформах; будет создан файл общей библиотеки с соответствующим суффиксом для целевой платформы (.dll или .so).
dll
статическая	Целью является статическая библиотека (только lib).Соответствующие флаги компилятора будут автоматически добавлены в проект.
staticlib
plugin	Целью является подключаемый модуль (только lib). Это также включает dll.
дизайнер	Цель — плагин для Qt Designer .
no_lflags_merge	Гарантирует, что список библиотек, хранящийся в переменной LIBS , не сокращается до списка уникальных значений перед его использованием.
метатипы	Создайте файл _metatypes. json для текущего проекта. <имя> — это базовое имя TARGET, состоящее только из строчных букв.
qmltypes	Автоматическая регистрация типов QML, определенных в C ++. Для получения дополнительной информации см. Определение типов QML из C ++. Также создайте файл