собрать qt приложение cmake
Личный опыт разработки ПО
CMake и Qt
В заметке представлен способ сборки программ использующих библиотеку Qt. Рассмотрены вопросы локализации приложения и подключения ресурсов, например изображений.
Помимо файлов с примерами есть файл с шаблоном приложения, используя который можно быстро создать достаточно сложный проект.
Для лучшего понимания материала, рекомендую прочитать введение в систему сборки приложений CMake.
Для проекта я рекомендую использовать следующую структуру директорий:
Таким образом в проекте существует директория build с файлом для системы сборки, также в этой директории создаются файлы для сборки, файлы генерируемые Qt и здесь же будет находится собранное приложение.
Второй важной директорией является директория resources, в корне которой находится XML файл resources.qrc содержащий список файлов с ресурсами включаемыми в приложение и директориями с ресурсами, например изображениями (images) и файлами с переводом на разные языки (translations).
Также в главной директории могут располагаться директории с подпроектами, файлы и директории с кодом. Под подпроектами я понимаю отдельные директории в корне проекта, содержащие код компилируемый в библиотеки и директорию build с файлом CMakeLists.txt, с помощью которого можно собрать данную библиотеку.
В файле для CMake придется сделать следующие вещи:
Поиск и подключение библиотек Qt
Поиск и подключение библиотек в CMake производится при помощи специальных расширений, рассмотрение которых выходит за рамки заметки, пока достаточно знать, что в стандартной поставке модуль для Qt уже есть и его можно использовать:
После этого будет предпринята попытка найти Qt и в случае успеха будет создан ряд переменных содержащих полезную информацию. Сейчас интерес для нас представляют QT_USE_FILE и QT_LIBRARIES, которые содержат путь к заголовочным файлам и библиотекам Qt:
Генерация MOC-файлов
Воспользовавшись макросом qt4_wrap_cpp можно из списка исходных кодов получить список MOC-файлов, который в свою очередь установить в зависимость к собираемому проекту:
В результате выполнения qt4_wrap_cpp переменная MOC_SOURCES будет содержать список сгенерированных MOC-файлов.
Генерация кода из файлов с ресурсами и включение их в приложение
Макрос qt4_add_resources из файла resources.qrc для каждого описанного там файла сгенерирует файлы с кодом, которые можно будет внедрить в приложение. Список этих файлов, как нетрудно догадаться, будет в первой переменной:
Файлы с переводом
Механизм локализации приложений Qt предлагает создание текстового файла с переводом (*.ts), работать с которым могут переводчики с помощью программы Linguist и последующей генерации из этих файлов бинарных ресурсов (*.qm) внедряемых в приложение.
Я использую следующий подход:
Для этих целей я использую следующий подход:
Что получилось
Последовательность сборки проекта
При применении предложенного подхода процесс сборки проекта выглядит следующим образом:
или открыв созданный проект с своей среде разработки и собрав подпроект translations
или выбрав команду build в своей среде разработки
Шаблон проекта с использование библиотеки Qt и системы сборки CMake
Для удобства я написал шаблон для приложений использующих CMake. Он содержит несколько директорий, файл CMakeLists.txt, пустой ts-файл (default.ts) и resources.qrc. Для использования вам надо будет добавить в CMakeLists.txt путь к файлам с кодом, указать используемые библиотеки и языки. Все переменные вынесены в начало файла и выглядят следующим образом:
Также необходимо добавить список файлов с ресурсами в resources.qrc и создать из пустого ts-файла столько файлов, сколько языков в списке, назвав их язык.ts
Убираем консольное окно в Windows
Если не приложить определенных усилий, приложение под Windows будет запускаться с консольным окном, что удобно при отладке, но не нужно в финальной версии. Чтобы его убрать нужно сделать две вещи:
Использование CMake с Qt 5
Поиск и подключение библиотек Qt 5
Одно из главных изменений при использовании CMake в Qt 5 — это результат увеличенной модульности в самом Qt.
В Qt 4, поиск осуществлялся следующим образом:
find_package (Qt4 COMPONENTS QTCORE QTGUI)
В Qt 5, можно найти все модули, которые Вы хотите использовать, отдельными командами:
find_package (Qt5Widgets)
find_package (Qt5Declarative)
В будущем, возможно, будет способ найти определенные модули в одной команде, но сейчас, в Qt 5, такого вида поиск работать не будет:
find_package(Qt5 COMPONENTS Widgets Declarative)
Сборка проектов Qt 5
Вкупе с новыми возможностями в CMake, как например автоматический вызов moc, простая система сборки CMake с использованием Qt 5 будет выглядеть примерно так:
Навстречу более современному использованию CMake
Функция CMake qt5_use_modules инкапсулирует всю установку, необходимую для использования Qt. Она может использоваться с несколькими аргументами сразу для краткости, например:
qt5_use_modules(hello_world Widgets Declarative)
Для qmake это эквивалентно следующему:
TARGET = hello_world
QT += widgets declarative
Все свойства находятся в области видимости конкретной используемой целевой функции, вместо того, чтобы быть в области видимости CMakeLists. Например, в этом фрагменте:
Детали реализации
Поиск Qt 5 происходит несколько иначе. Кроме возможности найти зависимости, используя Find-файл, CMake также в состоянии считывает файлы, обеспечивающие зависимости для определения местоположения библиотек и заголовочных файлов. Такие файлы называются файлами конфигурации, и обычно они генерируются самим CMake.
Сборка Qt 5 так же сгенерирует эти конфигурационные файлы CMake, но при этом не появятся зависимости от CMake.
Основное преимущество этого — то, что функции (и модули) Qt, которые могут использоваться с CMake, не будут зависеть от используемой версии CMake. Все модули Qt Essentials и Qt Addons создадут свой собственный файл конфигурации CMake, и функции, предоставляемые модулями, будут сразу доступны через макросы и переменные CMake.
Qt Documentation
Contents
CMake is a tool that helps simplify the build process for development projects across different platforms. CMake automates the generation of buildsystems such as Makefiles and Visual Studio project files.
Getting Started
The first requirement when using CMake is to use find_package to locate the libraries and header files shipped with Qt. These libraries and header files can then be used to build libraries and applications based on Qt.
The recommended way to use Qt libraries and headers with CMake is to use the target_link_libraries command. This command automatically adds appropriate include directories, compile definitions, the position-independent-code flag, and links to the qtmain.lib library on Windows.
To build a helloworld GUI executable, typical usage would be:
In order for find_package to be successful, Qt 5 must be found below the CMAKE_PREFIX_PATH, or the Qt5_DIR must be set in the CMake cache to the location of the Qt5Config.cmake file. The easiest way to use CMake is to set the CMAKE_PREFIX_PATH environment variable to the install prefix of Qt 5.
The CMAKE_AUTOMOC setting runs moc automatically when required. For more on this feature see the CMake AUTOMOC documentation
Imported targets
Note however that it is rare to require the full location to the library in CMake code. Most CMake APIs are aware of imported targets and can automatically use them instead of the full path.
Each module in Qt 5 has a library target with the naming convention Qt5:: which can be used for this purpose.
If your project has custom CMake build configurations, it may be necessary to set a mapping from your custom configuration to either the debug or release Qt configuration.
Plugins are also available as IMPORTED targets in CMake. The Qt Network, Qt SQL, Qt GUI, and Qt Widgets modules have plugins associated. They provide a list of plugins in the Qt5 _PLUGINS variable.
Variable Reference
Module variables
Equivalents of those variables will be available for all packages found with a find_package call. Note that the variables are case-sensitive.
Installation variables
Additionally, several other variables are available which do not relate to a particular package, but to the Qt installation itself.
Command Reference
Qt5::Core
Compiles big binary resources into object code
Creates an RCC file from a list of Qt resource files
Compiles binary resources into source code
Calls moc on an input file
Qt5::Widgets
Qt5::DBus
Generates an adaptor class for a D-Bus interface
Generates C++ sources implementing an interface for a D-Bus interface description file
Generates C++ sources implementing interfaces for D-Bus interface description files
Generates a D-Bus interface from a header file
Qt5::LinguistTools
Sets up the Qt Linguist translation toolchain
В© 2021 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
Qt Documentation
Contents
CMake automates the configuration of build systems. It controls the software compilation process by using simple configuration files, called CMakeLists.txt files. CMake generates native build configurations and workspaces that you can use in the compiler environment of your choice.
You can use CMake from Qt Creator to build applications for the desktop and Android devices. You can also build single files to test your changes.
CMake documentation is installed in Qt help file format (.qch) when you install CMake. It is automatically registered by Qt Creator, and you can view it in the Help mode.
Qt Creator automatically runs CMake to refresh project information when you edit a CMakeLists.txt configuration file in a project. Project information is also automatically refreshed when you build the project.
The File System section in the sidebar Projects view displays information from the file system. Qt Creator cannot determine whether the files are part of the project. For example, header files that Qt Creator finds in the project directories but that are not mentioned in the CMakeLists.txt files are listed here.
Adding CMake Tools
Qt Creator requires CMake’s file-based API. Please make sure to use CMake version 3.14, or later.
To view and specify settings for CMake:
To add a path to a CMake executable that Qt Creator does not detect automatically, and to specify settings for it, select Add. To make changes to automatically detected installations, select Clone.
Qt Creator uses the default CMake if it does not have enough information to choose the CMake to use. To set the selected CMake executable as the default, select Make Default.
To remove the selected CMake executable from the list, select Remove.
Select the Kits tab to add the CMake tool to a build and run kit. The kit also specifies the CMake generator that is used for producing project files for Qt Creator and the initial configuration parameters:
For more information, see Adding Kits.
Editing CMake Configuration Files
To open a CMakeLists.txt file for editing, right-click it in the Projects view and select Open With > CMake Editor.
You can also use the cmo filter in the locator to open the CMakeLists.txt file for the current run configuration in the editor. This is the same build target as when you select Build > Build for Run Configuration.
The following features are supported:
Adding External Libraries to CMake Projects
Through external libraries, Qt Creator can support code completion and syntax highlighting as if they were part of the current project or the Qt library.
Qt Creator detects the external libraries using the find_package() macro. Some libraries come with the CMake installation. You can find those in the Modules directory of your CMake installation. For more information, see cmake-packages(7).
Syntax completion and highlighting work once your project successfully builds and links against the external library.
Related Topics
В© 2021 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
Откуда ноги растут
Запрещенных веществ у нас не было (хотя в конце могут возникнуть сомнения). Было кое-что поинтереснее, если вы понимаете о чем я. Да, это легаси win-only Qt проект, начатый еще до начала времен под Qt 4.
Наша компания занимается разработкой и производством средств мониторинга и диагностики энергетического оборудования. В промышленности много старых проектов, тут они никого не пугают, особенно когда у вас аппаратно-программные комплексы. Но иногда приходится разгребать это, и в этот раз это досталось мне. А конкретно мне досталось эдакое сервисное ПО для нашего железа, которое бы работало с ним по разным протоколам.
Немного про системы сборки
Со временем проекты становятся все больше и больше, собирать их всё сложнее, если совсем маленький проект из main.cpp мы можем собрать одной командой то, когда проект состоит из сотни файлов, у вас не хватит нервов, чтобы набирать команды постоянно. Системы сборки призваны упростить этот процесс, программист заранее описывает некий набор команд, который затем выполняются каждый раз для сборки проекта.
Если вы вдруг думали, что make это компилятор, то нет, это своего рода враппер над компилятором.
Но несмотря на то, что появились системы сборки, которые значительно упростили жизнь программистам, они остаются платформо-зависимы и по сей день. Дальше было два пути:
Не секрет что The Qt Company начиная с Qt версии 6 отказывается от QMake в пользу CMake для сборки самого Qt. Параллельно с этим Qbs был объявлен deprecated. Правда, надо отдать должное сообществу, Qbs до сих пор развивается. Но при чем тут Qbs то? Дело в том, что Qbs появился как замена qmake.
Хотели как лучше, а вышло как в том анекдоте.
В 2020 было коммитов меньше чем в любой год до этого, а в 2021 и того меньше будет. Активность 2019 года связана с появлением Qt 6, а к возможностям самого qmake имеет опосредованное отношение. Если посмотреть на сами коммиты, то это в основном фиксы, а не добавление нового функционала. Таким образом можно предположить, что QMake поддерживается на остаточной основе и бурного развития не планируется.
Qmake хорош?
Answered: 1,853 Skipped: 20
Можно смело сказать, что QMake и в 2021 году входит в тройку самых популярных мета систем сборки (ninja, make не мета), а значит найти ответы на многие вопросы будет не так и сложно, хоть в документации и опущено множество моментов.
Почему многие все еще выбирают qmake?
Идеально для небольшого Qt проекта, не так ли? Вот именно, поэтому qmake и по сей день является рабочим решением и его рано выкидывать на свалку истории.
Я не призываю вас переходить здесь и сейчас на CMake, а QMake является более простой и понятной системой для начинающих (имхо), да и ее возможностей может хватать для многих проектов.
А что не так?
Кроссплатформенность у нас есть и довольно неплохая, реализована через mkspecs (аналог cmake-toolchains). С кросс-компиляцией сильно хуже, у меня так и не получилось её завести как надо, возможно руки виноваты, но с cmake почему-то было не сильно сложно.
Добавим сюда весьма смутное будущее, или наоборот ясное, учитывая рассмотренное выше. Недостаточно для того, чтобы пойти налево? Тогда qmake вам подходит.
К этому мы отдельно вернемся позже. А сейчас скажем просто, что qmake не слишком в этом хорош или даже совсем ничего не умеет, если сторонняя библиотека не содержит pro файл.
Сложность управления разделенными большими проектами
Сложности с кросс-компиляцией
Управление не Qt зависимостями
в счастливое светлое будущее?
Cmake лучше?
Или те же грабли, только вид сбоку? Возьму на себя смелость найти ответ на этот вопрос.
Наш проект интересен и сложен тем, что у нас разные целевые ОС и архитектуры. Просто прикинем, что нам надо всё собрать под 4 разных варианта: Windows x86, Windows x86_64, Linux Debian amd64, Linux Debian armhf. По итогу имеем три архитектуры и две ОС. Ну да, по итогу еще немного отстрелянных ног и набитых шишек (бесценный опыт).
Если у вас вдруг возник вопрос, то да, мы тащим qt в embedded. Но в оправдание скажу, что это сильно сэкономило время разработки т.к. qt части не надо переписывать на чистые плюсы, а можно взять as is.
CMakeLists первоначально выглядел как-то не очень.
Будущее cmake? Это де-факто стандартная система сборки в C++, вряд ли этого мало.
Кросс-компиляция в cmake работает через cmake-toolchains, достаточно собрать правильно окружение, написать toolchain файл и всё это будет полностью прозрачно для файла проекта. Т.е. в самом файле проекта не надо ставить никакие условия и флажки отдельно для кросс компиляции. Особо рукастые кросс-компилируют под embedded, используя cmake и компиляторы не из большой тройки. Здесь всё ограничивается вашей фантазией (иногда и отсутствующим генератором).
Управление зависимостями или самое сложное. Cmake предоставляет на самом деле множество способов для этого. Настолько много, что можно встретить споры на тему, что же именно лучше использовать и почему. Cmake тут полностью следует идеалогии языка: одну задачу можно решить множеством способов.
Попробуем сравнить детально
Сложность управления разделенными большими проектами
Возьмем простой пример. У нас есть App1, App2 и lib1, lib2. Каждый App зависит от каждой lib. Если всё немного упросить, то мы получим файлы следующего содержания:
В обоих случаях мы перечисляем поддиректории для включения. Но дальше в qmake надо явно указать, что конечный исполняемый файл зависит от собираемой библиотеки. Иначе они будут собираться одновременно, и можно получить ошибки линковки при чистой сборке (считай UB). В cmake это решили иначе и намного лаконичнее, позже обратим на это внимание.
Library
Самое интересное, что этот хак я так и не смог заставить работать под *nix. В конце концов плюнул и выкинул qmake просто.
Тут может показаться что cmake многословный и перегруженный, но директива target_link_libraries позволяет указать какой тип связывания мы хотим, в qmake же мы получим PUBLIC по умолчанию и дальше только флаги линкера/компилятора. find_package на первых порах выглядит громоздким, но на деле оказывается очень гибким и удобным инструментом. Пока опустим lib2 и другие.
Переменная QT_VERSION_MAJOR в старых версиях не устанавливается, будьте внимательны. Тогда получить ее можно так:
Application
Посмотрим, как будет выглядеть наш App1.
Внутренности App1.pri опустил, они нам не важны, т.к. там только перечисление исходников и заголовков.
Почти в 2 раза больше строк для cmake, что ж это такое-то.
Директива configure_file аналогична QMAKE_SUBSTITUTES, но с одним крайне важным отличием. Вы можете указать путь, по которому будет сгенерирован файл, а в qmake он будет рядом с исходным. Это неважно, если вам нужно использовать его только один раз. Но что если нам нужно генерировать по одному шаблону несколько файлов? Например, вытаскивать версию через информацию текущего коммита. А ничего, тогда придется страдать. Для каждой цели в случае qmake придется иметь копию этого файла в другой директории, иначе они будут затираться. Вообще cmake предоставляет больше способов работы с путями.
Можно сказать, что cmake предоставляет больше возможностей, но и больше приходится писать руками. CMake всё больше напоминает один известный ЯП.
Управление зависимостями
Тут у нас есть решения как общие для обеих систем сборки, так и специфичные для каждой. Начнем с общих.
Но что делать если нашей библиотеки нет в пакетном менеджере (или в репах нашего дистрибутива)? А это случается часто, надеюсь когда-нибудь в нашем ужасном С++ мире будет пакетный менеджер с библиотеками на любой чих (привет npm).
Вывод
QMake как система сборки хороша, максимально проста для вхождения и удобна. Если вы пишете маленький Qt-only проект или строго для одной платформ с одним компилятором, то всё прекрасно в вашем мире, но как только вам понадобится выйти за рамки дозволенного.
CMake сложен, один хороший человек сказал, что его стоит рассматривать как отдельный ЯП, вынужден с ним согласиться, потому что писать приходится много. Он позволяет очень много, настолько много что порой рождается такое.
Если у вас сложный проект, вы хотите жонглировать зависмостями, использовать одну кодовую базу на самых разных ОС и архитектурах или просто быть на гребне волны и не остаться за бортом, то ваш выбор cmake.
P.S. В статье опущены генераторные выражение т.к. аналогов в qmake попросту нет.
Отдельное спасибо выражаю товарищам из https://t.me/qt_chat, https://t.me/probuildsystems и переводчику/автору статьи т.к. именно благодаря им всё получилось.
Старое состояние проекта можно посмотреть здесь, а новое соответственно доступно без привязки к коммиту, если вдруг захочется.