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

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

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

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