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

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