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

В этом разделе описывается, как настроить файлы проектов 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 вставит целевой объект check в сгенерированный Makefile. Этот целевой объект запустит приложение. Тест считается пройденным, если он завершается с кодом выхода, равным нулю.

Целевой объект 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 для того же в режиме релиза. Если оставить как есть, имя целевого объекта останется неизменным.