Qmake stash что это
Проект файлов содержит всю информацию, требуемую qmake для сборки вашего приложения, библиотеки или плагина. В основном, вы используется серии объявлений для спецификации ресурсов в проекте, но поддержка простых программных конструкций позволяет описывать различные процессы сборки для различных платформ и сред.
Элементы проектного файла
Формат проектного файла используемый qmake может быть использован для поддержки как простых, так и довольно сложных систем. Простой проект файлов использует простой декларативный стиль, объявляющий переменные идентифицирующие исходные и заголовочные файлы в проекте. Комплексные проекты могут использовать структуры потоков для управления процессом сборки.
Переменные
В проектном файле, переменные используются для хранения списка строк. В простейшем проекте, эти переменные информируют qmake о настройке параметров для использования, или поставляют имена файлов и используемых путей в процессе сборки.
qmake ищет эти переменные в каждом проектном файле, и используется содержимой для определения того, что должно быть записано в Makefile. Например, список значений в переменных HEADERS и SOURCES используются для уведомления qmake об исходных и заголовочных файлах в некоторых директориях.
Переменные могут также использоваться внутри для хранения временных списков значений, а существующие списки значения могут быть перезаписаны или расширены новыми значениями.
Присваивание списка значений переменной:
Список значений переменных расширяется следующим образом:
Примечание: Первое задание значений включает только те значения, которые указаны в одной строке с переменной HEADERS. Второе объявление разделяет значения как в переменной SOURCES через обратный слеш («\»).
Переменная CONFIG является другой специальной переменной, которая используется qmake, когда генерируется Makefile.
Список переменных
Далее представлен список наиболее часто используемых переменных и описание их содержания.
Пробелы
Обычно, пробелы разделяют значения в переменных. Для указания переменной, содержащей в своём имени пробел, вы должны заключить переменную в скобки:
Текст, заключённый в скобки, считается одним предметом в списке переменных. Подобный подход также применяется и в других случаях. Например при указаний путей к файлам, содержащим пробелы:
Комментарии
Вы обычно добавляется комментарии в проект файлов. Коментарии начинаются со знака # и продолжаются до конца одной строки.
Встроенные функции и управление потоком
qmake предоставляет несколько встроенных функций для включения содержания переменных. Обычно используемой функцией в простых проектах является функция include(), которая принимает имя файла в качестве аргумента. Содержание файла включается в проект в том месте, где была использована функция include. Функция include обычно используется для подключения других проектов файлов.
Поддержка условных структур делает доступным области, которые ведут себя, как если бы они были объявления в языке программирования:
Более сложные операции над переменными обычно требуют циклов, которые предоставляются встроенными функциями, такими как find(), unique(), count(). Эти функции, и многие другие предоставляют управление строками и путями с поддержкой ввода и вызова внешних инструментов.
Шаблоны проекта
Переменная TEMPLATE используется для объявления типа проекта, который будет собран. Если он не декларирован в проектном файле, то qmake соберёт проект как приложение и генерирует Makefile или эквивалентный.
Далее представлены типы проектов, доступные для генерации qmake и их описания.
Когда используются поддиректории, то qmake генерирует Makefile для каждой поддиректории, выполняются все проектные файлы, которые находятся и запускается утилита make на вновь созданном Makefile. Переменная SUBDIRS используется для содержания списка всех поддиректорий, с которыми будет произведена работа.
Основная конфигурация
Переменная CONFIG указывает параметры и функции, которые должны быть выполнены в проекте.
Проект может быть собран в режиме отладки и выпуска, или в обоих. Если отладка и выпуску указаны одновременно, то в силу вступает последний. Если указано debug_and_release, собираются обе версии проекта. Makefile, который генерируется qmake включает правило, которое собирает обе версии. Это может быть выполнено следующим образом.
Примечание. Переменная CONFIG также может иметь условия сборки, если используются или не используются определённые параметры для сборки проекта.
В данном случае включаются различные конфигурации для сборок отладки и выпуска.
Примечание. Некоторые из этих параметров получают эффект только в случае соответствия платформе сборки.
Шаблоны приложения и библиотеки предоставляют Вам более специализированные настройки параметров процесса сборки. Например, если Ваше приложение используется Qt библиотеку и Вы хотите собрать в режиме debug, то Ваш проект должен содержать следующую строку:
Примечание. Вы должны использовать «+=», а не «=», или qmake не добавит использование настроек Qt.
Объявление Qt библиотек
Если переменная CONFIG содержит значение qt, то для qmake включена поддержка Qt приложений. Это делает возможным определять, какие модули Qt будут использоваться в приложении. Преимущество этого в том, что в переменная QT может быть использована для объявления только необходимых библиотек и модулей. Например мы можем включить модули XML и network следующим образом:
Примечание. QT включает модули core и gui по умолчанию, также как и модули XML и network. Следующий тип присвоения модулей переменной не включает core и gui и приведёт к ошибкам при компиляции.
Если вы хотите собрать проект без модуля gui, то Вам нужно исключить его следующим оператором «-=».
Особенности настройки
Например, qmake, может быть настроена на сборку со внешними библиотеками, которые поддерживают pkg-config, такие как D-Bus и ogg библиотеки.
Объявление других библиотек
Если используются другие библиотеки в вашем проекте в дополнение к модулям Qt, то Вам нужно указать их в проектном файле.
Пути, по которым qmake ищет библиотеки указываются в переменной LIBS. Вы можете указывать путь к библиотеке, используя Unix-style.
Пути, содержащие заголовочные файлы, также могут быть указаны подобным образом с помощью переменной INCLUDEPATH
Рекомендуем хостинг TIMEWEB
Рекомендуемые статьи по этой тематике
Откуда ноги растут
Запрещенных веществ у нас не было (хотя в конце могут возникнуть сомнения). Было кое-что поинтереснее, если вы понимаете о чем я. Да, это легаси 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 и переводчику/автору статьи т.к. именно благодаря им всё получилось.
Старое состояние проекта можно посмотреть здесь, а новое соответственно доступно без привязки к коммиту, если вдруг захочется.
Проект файлов содержит всю информацию, требуемую qmake для сборки вашего приложения, библиотеки или плагина. В основном, вы используется серии объявлений для спецификации ресурсов в проекте, но поддержка простых программных конструкций позволяет описывать различные процессы сборки для различных платформ и сред.
Элементы проектного файла
Формат проектного файла используемый qmake может быть использован для поддержки как простых, так и довольно сложных систем. Простой проект файлов использует простой декларативный стиль, объявляющий переменные идентифицирующие исходные и заголовочные файлы в проекте. Комплексные проекты могут использовать структуры потоков для управления процессом сборки.
Переменные
В проектном файле, переменные используются для хранения списка строк. В простейшем проекте, эти переменные информируют qmake о настройке параметров для использования, или поставляют имена файлов и используемых путей в процессе сборки.
qmake ищет эти переменные в каждом проектном файле, и используется содержимой для определения того, что должно быть записано в Makefile. Например, список значений в переменных HEADERS и SOURCES используются для уведомления qmake об исходных и заголовочных файлах в некоторых директориях.
Переменные могут также использоваться внутри для хранения временных списков значений, а существующие списки значения могут быть перезаписаны или расширены новыми значениями.
Присваивание списка значений переменной:
Список значений переменных расширяется следующим образом:
Примечание: Первое задание значений включает только те значения, которые указаны в одной строке с переменной HEADERS. Второе объявление разделяет значения как в переменной SOURCES через обратный слеш («\»).
Переменная CONFIG является другой специальной переменной, которая используется qmake, когда генерируется Makefile.
Список переменных
Далее представлен список наиболее часто используемых переменных и описание их содержания.
Пробелы
Обычно, пробелы разделяют значения в переменных. Для указания переменной, содержащей в своём имени пробел, вы должны заключить переменную в скобки:
Текст, заключённый в скобки, считается одним предметом в списке переменных. Подобный подход также применяется и в других случаях. Например при указаний путей к файлам, содержащим пробелы:
Комментарии
Вы обычно добавляется комментарии в проект файлов. Коментарии начинаются со знака # и продолжаются до конца одной строки.
Встроенные функции и управление потоком
qmake предоставляет несколько встроенных функций для включения содержания переменных. Обычно используемой функцией в простых проектах является функция include(), которая принимает имя файла в качестве аргумента. Содержание файла включается в проект в том месте, где была использована функция include. Функция include обычно используется для подключения других проектов файлов.
Поддержка условных структур делает доступным области, которые ведут себя, как если бы они были объявления в языке программирования:
Более сложные операции над переменными обычно требуют циклов, которые предоставляются встроенными функциями, такими как find(), unique(), count(). Эти функции, и многие другие предоставляют управление строками и путями с поддержкой ввода и вызова внешних инструментов.
Шаблоны проекта
Переменная TEMPLATE используется для объявления типа проекта, который будет собран. Если он не декларирован в проектном файле, то qmake соберёт проект как приложение и генерирует Makefile или эквивалентный.
Далее представлены типы проектов, доступные для генерации qmake и их описания.
Когда используются поддиректории, то qmake генерирует Makefile для каждой поддиректории, выполняются все проектные файлы, которые находятся и запускается утилита make на вновь созданном Makefile. Переменная SUBDIRS используется для содержания списка всех поддиректорий, с которыми будет произведена работа.
Основная конфигурация
Переменная CONFIG указывает параметры и функции, которые должны быть выполнены в проекте.
Проект может быть собран в режиме отладки и выпуска, или в обоих. Если отладка и выпуску указаны одновременно, то в силу вступает последний. Если указано debug_and_release, собираются обе версии проекта. Makefile, который генерируется qmake включает правило, которое собирает обе версии. Это может быть выполнено следующим образом.
Примечание. Переменная CONFIG также может иметь условия сборки, если используются или не используются определённые параметры для сборки проекта.
В данном случае включаются различные конфигурации для сборок отладки и выпуска.
Примечание. Некоторые из этих параметров получают эффект только в случае соответствия платформе сборки.
Шаблоны приложения и библиотеки предоставляют Вам более специализированные настройки параметров процесса сборки. Например, если Ваше приложение используется Qt библиотеку и Вы хотите собрать в режиме debug, то Ваш проект должен содержать следующую строку:
Примечание. Вы должны использовать «+=», а не «=», или qmake не добавит использование настроек Qt.
Объявление Qt библиотек
Если переменная CONFIG содержит значение qt, то для qmake включена поддержка Qt приложений. Это делает возможным определять, какие модули Qt будут использоваться в приложении. Преимущество этого в том, что в переменная QT может быть использована для объявления только необходимых библиотек и модулей. Например мы можем включить модули XML и network следующим образом:
Примечание. QT включает модули core и gui по умолчанию, также как и модули XML и network. Следующий тип присвоения модулей переменной не включает core и gui и приведёт к ошибкам при компиляции.
Если вы хотите собрать проект без модуля gui, то Вам нужно исключить его следующим оператором «-=».
Особенности настройки
Например, qmake, может быть настроена на сборку со внешними библиотеками, которые поддерживают pkg-config, такие как D-Bus и ogg библиотеки.
Объявление других библиотек
Если используются другие библиотеки в вашем проекте в дополнение к модулям Qt, то Вам нужно указать их в проектном файле.
Пути, по которым qmake ищет библиотеки указываются в переменной LIBS. Вы можете указывать путь к библиотеке, используя Unix-style.
Пути, содержащие заголовочные файлы, также могут быть указаны подобным образом с помощью переменной INCLUDEPATH
Рекомендуем хостинг TIMEWEB
Рекомендовані статті на цю тему
История успешного перевода ScreenPlay с QMake на CMake
ScreenPlay — это опенсорсное приложение для Windows (а скоро — ещё и для Linux и macOS), предназначенное для работы с обоями и виджетами. Оно создано с использованием современных инструментов (C++/Qt/QML), активная работа над ним ведётся с первой половины 2017 года. Код проекта хранится на платформе GitLab.
Автор статьи, перевод которой мы сегодня публикуем, занимается разработкой ScreenPlay. Он столкнулся с рядом проблем, решить которые ему помог переход с QMake на CMake.
QMake и разработка больших проектов
▍Совместное использование кода в QMake — это очень неудобно
▍Внешние зависимости
▍CONFIG += ordered — убийца производительности компиляции
QBS и CMake
▍Почему QBS проигрывает CMake?
Сообщение о прекращении поддержки QBS (Qt Build System, система сборки Qt) стало для меня настоящим шоком. Я даже был одним из инициаторов попытки это изменить. При использовании QBS применяются приятные синтаксические конструкции, знакомые каждому, кто когда-либо писал QML-код. Не могу сказать того же о CMake, но после того, как я несколько месяцев поработал с этой системой сборки проектов, я могу с уверенностью заявить о том, что переход на неё с QBS был правильным решением, и о том, что я продолжу пользоваться CMake.
CMake, хотя и имеет некоторые недостатки синтаксического плана, работает надёжно. А проблемы QBS больше относятся к сфере политики, чем к технической стороне вопроса.
Это — один из основных факторов, заставляющих программистов, недовольных размером Qt (и в плане количества строк кода, и в плане размера библиотеки), искать альтернативу. Кроме того, многим крайне не нравится MOC. Это — метаобъектный компилятор, который преобразует C++-код, написанный с использованием Qt, в обычный C++. Благодаря этому компилятору можно, например, пользоваться удобными конструкциями, вроде тех, которые позволяют работать с сигналами.
▍Альтернативы QBS
В нашем распоряжении, помимо QBS, имеются такие системы сборки проектов, как build2, CMake, Meson, SCons. Они, за пределами экосистемы Qt, используются во многих проектах.
▍Плохая поддержка QBS в IDE
Насколько мне известно, единственной IDE, поддерживающей QBS, является QtCreator.
▍Блестящий союз vcpkg и CMake
Помните, как выше я возмущался проблемами с внешними зависимостями? Поэтому неудивительно то, сколько положительных эмоций у меня вызвал диспетчер пакетов vcpkg. Для установки зависимости достаточно одной команды! Полагаю, vcpkg может пригодиться любому C++-программисту.
О кажущейся непривлекательности синтаксиса CMake
Если судить о CMake по первой десятке ссылок найденных Google, то может показаться, что в этой системе используются весьма непривлекательные синтаксические конструкции. Но проблема тут в том, что Google выводит первыми старые материалы о CMake со Stack Overflow, датированные 2008 годом. Тут же попадаются и ссылки на старую документацию к версии CMake 2.8. Синтаксические конструкции, используемые при работе с CMake, могут быть очень даже симпатичными. Дело в том, что применение CMake предусматривает, в основном, использование конструкций, показанных ниже (это — сокращённый вариант файла CMakeList.txt из проекта ScreenPlay).
Ninja ускоряет CMake
Роль CMake заключается лишь в том, чтобы генерировать инструкции для выбранной разработчиком системы сборки проектов. Это может оказаться огромным плюсом при работе с людьми, которые пользуются не Qt Creator, а Visual Studio. При использовании CMake можно (и нужно) выбрать Ninja в качестве системы сборки, используемой по умолчанию. Компиляция проектов с применением связки CMake+Ninja — это очень приятно. И то и другое можно найти в наборе инструментов Qt Maintenance. Кроме прочего, эти инструменты очень быстро обрабатывают изменения при итеративном подходе к разработке. На самом деле, всё работает так быстро, что при использовании Godot со SCons мне очень хочется и тут пользоваться CMake.
Vcpkg позволяет CMake проявить себя во всей красе
Управление зависимостями в C++-проектах — это непростая задача. Для её решения многие проекты даже размещают в своих Git-репозиториях необходимые DLL. А это плохо, так как из-за этого неоправданно увеличиваются размеры репозиториев (Git LFS мы тут не касаемся). Недостаток vcpkg заключается лишь в том, что этот диспетчер пакетов поддерживает лишь одну глобальную версию некоего пакета (то есть, приходится самостоятельно устанавливать разные версии vcpkg, но это — нечто вроде хака, да и нужно это редко). Правда, в планах развития проекта можно увидеть то, что он идёт в правильном направлении.
Для установки пакетов используется такая команда:
Мы, при работе над ScreenPlay, просто создали скрипты install_dependencies_windows.bat и install_dependencies_linux_mac.sh для клонирования репозитория vcpkg, для его сборки и установки всех наших зависимостей. При работе с Qt Creator необходимо записывать в CMAKE_TOOLCHAIN_FILE относительный путь к vcpkg. Кроме того, vcpkg нужно сообщить о том, какую ОС и какую архитектуру мы используем.
Итоги
У подхода, когда пользуются всем самым новым и популярным, есть свои плюсы. Но что делать, например, когда системы сборки с большим потенциалом, вроде QBS, вдруг оказываются на обочине? В конечном счёте, разработчик сам принимает решения о том, чем ему пользоваться в его проектах. Именно поэтому я решил перевести свой проект на CMake. И, надо сказать, это было правильное решение. Сегодня, в 2020 году, CMake смотрится очень даже хорошо.