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

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

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