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

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