как установить qmake linux
Развертывание Qt и QML приложений в Linux и Windows
Введение
В данной статье мы рассмотрим, как правильно собрать все зависимости qt для вашего приложения, которое было собрано динамически.
Для начало немного теории
Зачем это нужно?
Существует несколько способов сборки приложений, основные из них это:
Статическая сборка.
Статическая сборка подразумевает создание бинарника, в котором будут слинковоны все необходимые ему компоненты. Другими словами все что нужно для его работы будет лежать в нем. Такой подход удобен для маленьких консольных приложений, у которых мало зависимостей, в противном случае размер конечного бинарника будет крайне велик.
Динамическая сборка.
Отличается от статической тем, что в бинарнике будут лежать только исходные тексты вашего приложения (размер бинарника будет минимальный), но при выполнении такого приложения ему понадобятся сторонние библиотеки, которые использовались при его написании.
Теперь немного описания
Давайте рассмотрим пример
Для примера я написал простое qt приложение с использованием qml — MyApp.
MyApp (main.cpp)
MyApp (main.qml)
MyApp слинкована динамически, то есть для работы ему требуются библиотеки qt.
Если попробовать запустить приложение, сразу после сборки мы получим ошибку:
Из сходных текстов мы видим, что приложение зависит от GUI библиотек qt и библиотек qml. Поиск и сборка всех ресурсов (библиотек и плагинов) займет очень много времени.
Чтобы сэкономить время и силы, мы воспользуемся утилитой CQtDeployer (скачать можно здесь )
или установить в Snap Store
После выполнения данной команды, вы получите полностью готовое для работы приложение с готовым лаунчером, который настроит все необходимое окружение для работы вашего приложения на всех машинах под управлением Linux.
Давайте подробнее рассмотрим некоторые из параметров CQtDeployer:
/my/project/qml
/newLibs
После выполнения cqtdeployer у вас появится папка Distro c уже готовым приложением со всеми его зависимостями содержимое этой папки должно выглядеть примерно следующим образом:
Таким образом можно подготовить ваше приложения для упаковки в deb или snap пакет, после чего можно приступить к его распространению. Учитывайте, что после выполнения cqtdeployer, ваше приложение необходимо запускать с помощью sh скрипта, который настроит для вашего приложения необходимое окружение.
Для Windows все точно так же. только в консоли нужно будет писать не cqtdeployer а %cqtdeployer%
Откуда ноги растут
Запрещенных веществ у нас не было (хотя в конце могут возникнуть сомнения). Было кое-что поинтереснее, если вы понимаете о чем я. Да, это легаси 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 и переводчику/автору статьи т.к. именно благодаря им всё получилось.
Старое состояние проекта можно посмотреть здесь, а новое соответственно доступно без привязки к коммиту, если вдруг захочется.
Qt Documentation
Contents
This documentation discusses specific deployment issues for Qt for Linux/X11. We will demonstrate the procedures in terms of deploying the Plug & Paint application that is provided in Qt’s examples directory.
Due to the proliferation of Unix systems (such as commercial Unixes, Linux distributions, and so on), deployment on Unix is a complex topic. Before we start, be aware that programs compiled for one Unix flavor will probably not run on a different Unix system. For example, unless you use a cross-compiler, you cannot compile your application on Irix and distribute it on AIX.
Static Linking
Static linking is often the safest and easiest way to distribute an application on Unix since it relieves you from the task of distributing the Qt libraries and ensuring that they are located in the default search path for libraries on the target system.
Building Qt Statically
To use this approach, you must start by installing a static version of the Qt library:
We specify the prefix so that we do not overwrite the existing Qt installation. The example above only builds the Qt libraries, i.e. the examples and Qt Designer will not be built. When make is done, you will find the Qt libraries in the /path/to/Qt/lib directory.
When linking your application against static Qt libraries, note that you might need to add more libraries to the LIBS line in your project file. For more information, see the Application Dependencies section.
Linking the Application to the Static Version of Qt
Once Qt is built statically, the next step is to regenerate the makefile and rebuild the application. First, we must go into the directory that contains the application:
Now run qmake to create a new makefile for the application, and do a clean build to create the statically linked executable:
To check that the application really links statically with Qt, run the ldd tool (available on most Unices):
Verify that the Qt libraries are not mentioned in the output.
Now, provided that everything compiled and linked without any errors, we should have a plugandpaint file that is ready for deployment. One easy way to check that the application really can be run stand-alone is to copy it to a machine that doesn’t have Qt or any Qt applications installed, and run it on that machine.
Remember that if your application depends on compiler specific libraries, these must still be redistributed along with your application. For more information, see the Application Dependencies section.
The Plug & Paint example consists of several components: The core application (Plug & Paint), and the Basic Tools and Extra Filters plugins. Since we cannot deploy plugins using the static linking approach, the executable we have prepared so far is incomplete. The application will run, but the functionality will be disabled due to the missing plugins. To deploy plugin-based applications we should use the shared library approach.
Shared Libraries
We have two challenges when deploying the Plug & Paint application using the shared libraries approach: The Qt runtime has to be correctly redistributed along with the application executable, and the plugins have to be installed in the correct location on the target system so that the application can find them.
Building Qt as a Shared Library
We assume that you already have installed Qt as a shared library, which is the default when installing Qt, in the /path/to/Qt directory.
Linking the Application to Qt as a Shared Library
After ensuring that Qt is built as a shared library, we can build the Plug & Paint application. First, we must go into the directory that contains the application:
Now run qmake to create a new makefile for the application, and do a clean build to create the dynamically linked executable:
This builds the core application, the following will build the plugins:
If everything compiled and linked without any errors, we will get a plugandpaint executable and the libpnp_basictools.so and libpnp_extrafilters.so plugin files.
Creating the Application Package
There is no standard package management on Unix, so the method we present below is a generic solution. See the documentation for your target system for information on how to create a package.
To deploy the application, we must make sure that we copy the relevant Qt libraries (corresponding to the Qt modules used in the application), the platform plugin, and the executable to the same directory tree. Remember that if your application depends on compiler specific libraries, these must also be redistributed along with your application. For more information, see the Application Dependencies section.
We’ll cover the plugins shortly, but the main issue with shared libraries is that you must ensure that the dynamic linker will find the Qt libraries. Unless told otherwise, the dynamic linker doesn’t search the directory where your application resides. There are many ways to solve this:
Note: If your application will be running with «Set user ID on execution,» and if it will be owned by root, then LD_LIBRARY_PATH will be ignored on some platforms. In this case, use of the LD_LIBRARY_PATH approach is not an option).
The disadvantage of the first approach is that the user must have super user privileges. The disadvantage of the second approach is that the user may not have privileges to install into the predetermined path. In either case, the users don’t have the option of installing to their home directory. We recommend using the third approach since it is the most flexible. For example, a plugandpaint.sh script will look like this:
By running this script instead of the executable, you are sure that the Qt libraries will be found by the dynamic linker. Note that you only have to rename the script to use it with other applications.
When looking for plugins, the application searches in a plugins subdirectory inside the directory of the application executable. Either you have to manually copy the plugins into the plugins directory, or you can set the DESTDIR in the plugins’ project files:
An archive distributing all the Qt libraries, and all the plugins, required to run the Plug & Paint application, would have to include the following files:
| Component | File Name | |
|---|---|---|
| The executable | plugandpaint | |
| The script to run the executable | plugandpaint.sh | |
| The Basic Tools plugin | plugins\libpnp_basictools.so | |
| The ExtraFilters plugin | plugins\libpnp_extrafilters.so | |
| The Qt xcb platform plugin | platforms\libqxcb.so | |
| The Qt Core module | libQt5Core.so.5 | |
| The Qt GUI module | libQt5Gui.so.5 | |
| The Qt Widgets module | libQt5Widgets.so.5 | |
Remember that if your application depends on compiler specific libraries, these must still be redistributed along with your application. For more information, see the Application Dependencies section.
To verify that the application now can be successfully deployed, you can extract this archive on a machine without Qt and without any compiler installed, and try to run it, i.e. run the plugandpaint.sh script.
An alternative to putting the plugins in the plugins subdirectory is to add a custom search path when you start your application using QApplication::addLibraryPath() or QApplication::setLibraryPaths().
Application Dependencies
Additional Libraries
To find out which libraries your application depends on, run the ldd tool (available on most Unices):
This will list all the shared library dependencies for your application. Depending on configuration, these libraries must be redistributed along with your application. In particular, the standard C++ library must be redistributed if you’re compiling your application with a compiler that is binary incompatible with the system compiler. When possible, the safest solution is to link against these libraries statically.
FontConfig and FreeType are other examples of libraries that aren’t always available or that aren’t always binary compatible. As strange as it may sound, some software vendors have had success by compiling their software on very old machines and have been very careful not to upgrade any of the software running on them.
When linking your application against the static Qt libraries, you must explicitly link with the dependent libraries mentioned above. Do this by adding them to the LIBS variable in your project file.
Your application may also depend on one or more Qt plugins, such as the JPEG image format plugin or a SQL driver plugin. Be sure to distribute any Qt plugins that you need with your application. Similar to the platform plugin, each type of plugin must be located within a specific subdirectory (such as imageformats or sqldrivers ) within your distribution directory.
The How to Create Qt Plugins document outlines the issues you need to pay attention to when building and deploying plugins for Qt applications.
В© 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.