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

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