Создание общих типов проектов

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

Платформенно-зависимые переменные здесь не описываются. Для получения дополнительной информации см. Qt для Windows - Развертывание и Qt для macOS.

Создание приложения

Шаблон app указывает qmake на генерацию файла Makefile, который будет собирать приложение. С помощью этого шаблона тип приложения можно указать, добавив один из следующих параметров в определение переменной CONFIG:

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

• HEADERS - Список файлов заголовков для приложения.
• SOURCES - Список файлов исходного кода C++ для приложения.
• FORMS - Список файлов пользовательского интерфейса для приложения (созданных с помощью Qt Designer).
• LEXSOURCES - Список файлов исходного кода Lex для приложения.
• YACCSOURCES - Список файлов исходного кода Yacc для приложения.
• TARGET - Имя исполняемого файла приложения. По умолчанию — имя файла проекта. (Расширение, если оно есть, добавляется автоматически).
• DESTDIR - Каталог, в который помещается исполняемый файл.
• DEFINES - Список дополнительных определений препроцессора, необходимых для приложения.
• INCLUDEPATH - Список дополнительных путей включения, необходимых для приложения.
• DEPENDPATH - Путь поиска зависимостей для приложения.
• VPATH - Путь поиска поставленных файлов.
• DEF_FILE - Только Windows: Файл .def, который должен быть связан с приложением.

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

TEMPLATE = app
DESTDIR  = c:/helloapp
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
DEFINES += USE_MY_STUFF
CONFIG  += release

Для элементов с единственным значением, например, шаблон или целевой каталог, мы используем «=»; но для многозначных элементов мы используем «+=», чтобы добавить к существующим элементам этого типа. Использование «=» заменяет значение переменной новым значением. Например, если мы напишем DEFINES=USE_MY_STUFF, все остальные определения будут удалены.

Создание тестового случая

Проект тестового случая — это app проект, предназначенный для выполнения в качестве автоматизированного теста. Любой app может быть помечен как тестовый случай, добавив значение testcase в переменную CONFIG.

Для проектов тестовых случаев qmake вставит в сгенерированный Makefile целевой check . Этот целевой объект запустит приложение. Тест считается пройденным, если он завершится с кодом выхода, равным нулю.

Целевой check автоматически рекурсивно проходит через проекты SUBDIRS. Это означает, что возможно выполнить команду make check из проекта SUBDIRS, чтобы запустить весь набор тестов.

Выполнение целевого объекта check может быть настроено с помощью определенных переменных Makefile. Эти переменные:

Примечание: Переменные должны быть установлены при вызове инструмента make, а не в файле .pro. Большинство инструментов make поддерживают установку переменных Makefile непосредственно в командной строке:

# Run tests through test-wrapper and use xunitxml output format.
# In this example, test-wrapper is a fictional wrapper script which terminates
# a test if it does not complete within the amount of seconds set by "--timeout".
# The "-o result.xml,xunitxml" options are interpreted by QTestLib.
make check TESTRUNNER="test-wrapper --timeout 120" TESTARGS="-o result.xml,xunitxml"

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

Тесты часто пишутся с помощью QTest или TestCase, но это не является обязательным условием для использования CONFIG+=testcase и make check. Единственное основное требование состоит в том, чтобы программа-тест завершалась с кодом выхода 0 при успешном выполнении и с ненулевым кодом выхода при ошибке.

Создание библиотеки

Шаблон lib сообщает qmake о генерации Makefile, который будет компилировать библиотеку. При использовании этого шаблона поддерживается переменная VERSION помимо системных переменных, которые поддерживает шаблон app. Используйте переменные в файле .pro для указания информации о библиотеке.

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

Следующий вариант также может быть определен для предоставления дополнительной информации о библиотеке.

• VERSION - Номер версии целевой библиотеки. Например, 2.3.1.

Имя целевого файла для библиотеки зависит от платформы. Например, в X11, macOS и iOS имя библиотеки будет начинаться с lib. В Windows префикс к имени файла не добавляется.

Создание плагина

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

• VERSION - Номер версии целевой библиотеки. Например, 2.3.1.

Создание плагина Qt Designer

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

QT          += widgets designer

См. Примеры Qt Designer для получения дополнительных примеров проектов на основе плагинов.

Создание и установка в режимах отладки и релиз

Иногда необходимо создать проект в режимах отладки и релиза. Хотя переменная CONFIG может содержать как debug , так и release варианты, применяется только последний указанный вариант.

Создание в обоих режимах

Чтобы включить создание проекта в обоих режимах, необходимо добавить вариант debug_and_release в переменную CONFIG:

CONFIG += debug_and_release

CONFIG(debug, debug|release) {
    TARGET = debug_binary
} else {
    TARGET = release_binary
}

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

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

make all

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

CONFIG += build_all

Это позволит обработать Makefile с использованием правила по умолчанию:

make

Установка в обоих режимах

Вариант build_all также гарантирует, что обе версии целевого объекта будут установлены при вызове правила установки:

make install

Можно настроить имена целевых объектов сборки в зависимости от целевой платформы. Например, библиотека или плагин могут иметь разное имя в Windows по сравнению с Unix-платформами:

CONFIG(debug, debug|release) {
    mac: TARGET = $$join(TARGET,,,_debug)
    win32: TARGET = $$join(TARGET,,d)
}

По умолчанию в приведенном фрагменте кода изменяется имя целевого объекта сборки при создании в режиме отладки. Мог быть добавлен else блок, чтобы сделать то же самое для режима релиза. В данном случае имя целевого объекта остается неизменным.