Как установить qmake linux
Qt Documentation
Contents
This tutorial teaches you the basics of qmake. The other topics in this manual contain more detailed information about using qmake.
Starting Off Simple
Let’s assume that you have just finished a basic implementation of your application, and you have created the following files:
We’ll add the source files to the project file first. To do this you need to use the SOURCES variable. Just start a new line with SOURCES += and put hello.cpp after it. You should have something like this:
We repeat this for each source file in the project, until we end up with the following:
If you prefer to use a Make-like syntax, with all the files listed in one go you can use the newline escaping like this:
Now that the source files are listed in the project file, the header files must be added. These are added in exactly the same way as source files, except that the variable name we use is HEADERS.
Once you have done this, your project file should look something like this:
The finished project file should look like this:
You can now use qmake to generate a Makefile for your application. On the command line, in your project directory, type the following:
Then type make or nmake depending on the compiler you use.
For Visual Studio users, qmake can also generate Visual Studio project files. For example:
Making an Application Debuggable
The release version of an application does not contain any debugging symbols or other debugging information. During development, it is useful to produce a debugging version of the application that has the relevant information. This is easily achieved by adding debug to the CONFIG variable in the project file.
Use qmake as before to generate a Makefile. You will now obtain useful information about your application when running it in a debugging environment.
Adding Platform-Specific Source Files
A simple scope that adds the platform-dependent file for Windows looks like this:
When building for Windows, qmake adds hellowin.cpp to the list of source files. When building for any other platform, qmake simply ignores it. Now all that is left to be done is to create a scope for the Unix-specific file.
When you have done that, your project file should look something like this:
Use qmake as before to generate a Makefile.
Stopping qmake If a File Does Not Exist
You may not want to create a Makefile if a certain file does not exist. We can check if a file exists by using the exists() function. We can stop qmake from processing by using the error() function. This works in the same way as scopes do. Simply replace the scope condition with the function. A check for a file called main.cpp looks like this:
Use qmake as before to generate a makefile. If you rename main.cpp temporarily, you will see the message and qmake will stop processing.
Checking for More than One Condition
Suppose you use Windows and you want to be able to see statement output with qDebug() when you run your application on the command line. To see the output, you must build your application with the appropriate console setting. We can easily put console on the CONFIG line to include this setting in the Makefile on Windows. However, let’s say that we only want to add the CONFIG line when we are running on Windows and when debug is already on the CONFIG line. This requires using two nested scopes. First create one scope, then create the other inside it. Put the settings to be processed inside the second scope, like this:
Nested scopes can be joined together using colons, so the final project file looks like this:
That’s it! You have now completed the tutorial for qmake, and are ready to write project files for your development projects.
В© 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 и переводчику/автору статьи т.к. именно благодаря им всё получилось.
Старое состояние проекта можно посмотреть здесь, а новое соответственно доступно без привязки к коммиту, если вдруг захочется.
Установил qt5 из исходников, все делал по инструкции, прописал в PATH, но все равно не видит qmake Как решить?
$ qmake qmake: could not exec ‘/usr/lib/x86_64-linux-gnu/qt4/bin/qmake’: No such file or directory Все делал как написано в http://qt-project.org/doc/qt-5/linux-building.html но не работает. Прежде было установлено qt4-qmake, но я его деинсталлировал вместе со всем qt4.
Мне надо именно версия не ниже 5.3
И тебе обязательно было его собирать? Ты ж ламер, ты даже гуглить не удосуживаешься перед тем, как делать глупые вещи.
Держи! Там будут привычные тебе «Next->Next->Finish!»
Дело в том что предидущую версию я так и устанавливал, но это слишком много из интернета тянет, с изходников меньше трафика жрет, правда компиллировалось оно у меня наверное часов 8
Вписывал в /etc/environment, не помогло, потом вписал в /etc/profile, тоже не помогло. Ну и в /etc/ld.so.conf.d/x86_64-linux-gnu.conf директорию с библиотеками прописал.
Вписывал в /etc/environment, не помогло, потом вписал в /etc/profile, тоже не помогло
Ну так в результате PATH у тебя какой сейчас?
Все решил уже. Оказывается что после удаления qt4-qmake в системе остался qtchooser, который сохранил симлинки в /usr/bin Все решил правкой конфигов qtchooser
используй лоркод, читать кашу из выхлопа и текста невозможно, глаза ломаются
я просто не знаю как им пользоваться этим лоркодом. На лоре пишу очень редко.
Уже разобрался в лоркоде, но поздно, не редактируется вопрос и комментарии.
повтори все выхлопы в новом коментарии, не думаю что модеры будут против.
Уже решил проблему.
Недокументированный QMake
Вступление
Обратите внимание, что информация была написана для Qt4, но некоторые из них могут работать в Qt3. Кстати, должно работать в Qt5 или же рассмотреть для удаления.
Недокументированные переменные
Так что, если вы пытаетесь выяснить что-то вроде: «Как мне изменить имя компилятора, который используется в make-файле?» или «Как я могу изменить способ вызова файла-копии для ‘make install’?» и тому подобное, в каталоге mkspecs вы должны искать имя переменной, которую нужно изменить.
Вот несколько особенно полезных (начиная с v4.3.4), обнаруженных при исследовании источника qmake:
Пользовательские инструменты
В документации по qmake в Qt4 кратко упоминается о возможности пользовательских «компиляторов», но для описания, к сожалению, не так много.
Надеюсь, Trolltech (Qt Company) уже предоставили вам то, что вам нужно!
Самое простое определение пользовательского инструмента обычно выглядит примерно так:
Чтобы определить пользовательский инструмент, вы должны сначала выбрать имя для составной переменной (аналог структуры) для определения. В приведенном выше примере я выбрал «idl.c».
Есть несколько свойств, которые могут быть включены в определение пользовательского инструмента:
После того, как вы определили составную переменную для инструмента, вы должны затем добавить эту составную переменную в QMAKE_EXTRA_COMPILERS. Это дает понять qmake, что он должен просмотреть указанные вами файлы и запустить на них этот инструмент.
Примеры
Вот еще один, причем необычный, пример:
Способ компиляции разных файлов с разными CXXFLAGS (на основе qt / src / gui / painting / painting.pri):
И, наконец, пример того, как вызывать пакетный файл с именем «PreBuildEvent.bat» каждый раз, когда вы компилируете свой код (протестировано в VisualStudio на основе qt-creator-enterprise-src-3.1.0 \ share \ qtcreator \ static.pro):
Особенности конфигурации
Есть несколько «переключателей», которые могут быть добавлены к переменной CONFIG, которые влияют на различное поведение qmake (обратите внимание, что это не включает функции CONFIG специфичные для пользовательских инструментов или установщиков):
Когда используются debug_and_release и static_and_shared, все четыре комбинации Debug / Release и Static / Shared будут добавлены в дополнение к build_pass.
Путем проверки этих значений в области build_pass можно настроить соответствующее содержимое make-файла. Например, если исходный код содержит отладочные выходные разделы, обусловленные определением макроса препроцессора DEBUG_SECTION, следующий синтаксис qmake позволяет определить значение макроса во время компиляции:
Кроме того, есть несколько значений с неопределенным значением:
Еще одна интересная ценность для тех, кому надоели длинные журналы компиляции:
Не используйте временный файл, содержащий флаги командной строки, например, для звонков. компилятор или компоновщик (@C: \ TEMP \ nm1234.tmp), но пишите все непосредственно в командную строку (специфично для nmake). Полезно для воспроизводимых журналов сборки:
Другая интересная функциональность qmake, по крайней мере, начиная с Qt4, заключается в том, что он имеет (недокументированный) переключатель «config», который изменяет значение переменной CONFIG во время выполнения без изменения содержимого обрабатываемого файла. Это особенно полезно для замены целей сборки. Действительно, qmake не может генерировать другие цели сборки, кроме классических «release», «debug», «clean» и «install». Поскольку переменная CONFIG проверяется при разрешении областей, она позволяет создавать сложную структуру проекта, основанную на целях, которая остается удобочитаемой.
Вышеупомянутый проект будет иметь 4 возможных выхода:
Выборочная установка конфигурации
SUBDIRS проекты
Вы можете использовать его как:
проект, который имеет:
Недокументированные режимы
Помимо хорошо известных режимов «-project» и «-makefile», qmake поддерживает несколько других ключей, которые могут переводить его в разные режимы.
Значения встроенных свойств:
Например, если Qt 4.1.3 установлен в /usr/local/Trolltech/Qt-4.1.3 (по умолчанию):
Недокументированные функции
Есть несколько очень удобных функций, которых нет в документации по Qt4. Некоторые из них не были добавлены до Qt 4.2, так что будьте осторожны.
Функции потока программы
Что касается qmake, то это тестовые функции, принадлежащие своему собственному разделу:
Замена функции
Эти функции возвращают значение:
Недокументированные тонкости
Подстановочный знак можно использовать практически везде: области видимости, значения, и т.д.
Определение, используется ли статическая сборка Qt:
Рекомендуем хостинг TIMEWEB
Рекомендуемые статьи по этой тематике
Развертывание 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%