Qmake cmake qbs что это
Каковы различия и сходства между CMake и qmake?
я бы хотел знать причины использования CMake для конкретного проекта поверх qmake и наоборот.
Просто каковы плюсы и минусы обеих систем сборки? Я искал и нашел несколько документов, но мне трудно понять.
Решение
Обе системы сборки, но они не очень похожи. Если ваш проект использует Qt, вам, вероятно, лучше всего использовать qmake. CMake более универсален и подходит практически для любого типа проекта.
Если ваш проект использует Qt, но вы не хотите использовать qmake, вам придется сделать еще несколько вещей самостоятельно:
Итак, вам придется проделать немного больше работы для создания проекта Qt без qmake, но это возможно, и это многому научит вас, как Qt и qmake делают вещи.
От себя лично (примите это только как рекомендацию, проведите дальнейшие исследования самостоятельно): я не большой поклонник qmake. Это поможет вам с Qt, но кроме этого я обнаружил, что он довольно ограничен.
В любом случае, я бы порекомендовал научиться создавать небольшой проект (
10 исходных файлов) без использования какой-либо системы сборки. Не используя CMake, не с Makefile, просто используя компилятор и компоновщик напрямую. Вы не должны на самом деле создавать какой-либо реальный проект таким образом, но вы должны научиться делать это, просто чтобы узнать, что на самом деле делают системы сборки. Знание того, что они делают, облегчит их использование.
Тем не менее, это немного более «ручное» руководство, поэтому подготовьтесь к тому, чтобы узнать, как компиляция и компоновка работают на более базовом уровне, без использования системы сборки. Он также находится в бета-версии (Premake 5), поэтому некоторые кусочки по-прежнему отсутствуют.
Другие решения
CMake — безусловно, самая мощная система сборки. Синтаксис «не очень хороший», мягко говоря. Но тогда для любого сложного проекта то, что нужно делать с QMake (или любой системой сборки, о которой я знаю), чтобы добиться чего-то, тоже нехорошо. Для простых проектов QMake лучше смотреть.
Если вам нужны проверки конфигурации для сторонних зависимостей, отличных от Qt, CMake — то, что вам нужно, поддержка проверок конфигурации в QMake минимальна или вообще отсутствует.
С другой стороны, QMake прекрасно работает с Qt Creator (там нет поддержки CMake, хотя можно использовать CMake с Creator).
Если вы хотите создавать и развертывать для iOS и Android из Qt Creator, я настоятельно рекомендую QMake. (Не уверен, что это возможно даже в наши дни с CMake — это, безусловно, вызовет гораздо больше головной боли).
Я использую CMake для своих проектов Qt и очень доволен им. В частности, у меня есть следующее в моем CMakeLists.txt:
Я надеюсь, что это поможет, если вы решите пойти с CMake.
Моя рекомендация: используйте qmake, если QtCreator — ваша IDE, и вы начинаете с Qt или C ++. Используйте cmake, если вы хотите делать какие-то сложные вещи в вашей сборке.
Русские Блоги
Что такое makefile cmake qmake и в чем разница
Автор: Вен Цин
Ссылка : https://www.zhihu.com/question/27455963/answer/36722992.
Источник: Жиху
Авторские права принадлежат автору. Пожалуйста, свяжитесь с автором для авторизации.
В определенных случаях под Linux небольшие проекты могут писать Make-файлы вручную, большие проекты используют automake, чтобы помочь вам создавать Make-файлы, если вы хотите кросс-платформенный, использовать cmake. Если графический интерфейс использует Qt, вы также можете использовать qmake + *. Pro для управления проектом, который также является кроссплатформенным. Конечно, cmake также имеет некоторые правила для Qt и заменяет qmake, чтобы помочь вам разобраться с командами, связанными с qt.
Последний эскиз, где cl представляет компилятор visual studio, а gcc представляет компилятор под linux
Автор: Чан Хуэй брат
Ссылка : https://www.zhihu.com/question/27455963/answer/89770919
Источник: Жиху
Авторские права принадлежат автору. Пожалуйста, свяжитесь с автором для авторизации.
2. Когда ваша программа имеет только один исходный файл, вы можете напрямую скомпилировать его с помощью команды gcc.
3. Но когда ваша программа содержит много исходных файлов, когда вы используете команду gcc для компиляции один за другим, вы легко запутываетесь и много работаете
4. Итак, появился инструмент make
Инструмент make можно рассматривать как интеллектуальный пакетный инструмент, который не имеет функции компиляции и компоновки, но он аналогичен пакетной обработке, вызывая пользователя, указанного в make-файле. Для компиляции и ссылки.
5. Что такое make-файл? Проще говоря, это как партитура песни. Инструмент make похож на дирижера. Дирижер ведет, как весь оркестр играет в соответствии с партитурой. Инструмент make компилирует и связывает в соответствии с командами в make-файле.
6. Команда makefile включает команду для вызова gcc (или другого компилятора) для компиляции исходного файла.
7. Makefile может быть использован вручную в некоторых простых проектах, но когда проект очень большой, от руки make-файл также очень проблематичен. Если вы измените make-файл платформы, вам придется изменить его снова.
8. В это время появился инструмент Cmake, cmake может легче генерировать make-файл для вышеупомянутого make. Конечно, у cmake есть и другие функции, то есть он может генерировать make-файлы, которые можно использовать на соответствующих платформах на разных платформах.
9. Но на основании чего cmake генерирует make-файл? Он также генерирует make-файлы на основе файла CMakeLists.txt (научное название: файл конфигурации).
10. Кто напишет файл CMakeLists.txt в конце? Уважаемый, вы написали это сами.
11. Конечно, если вы используете IDE, например VS, он может вам в общем помочь, вам просто нужно щелкнуть треугольник
13. Вы можете использовать Qt для реализации очень сложных функций просто потому, что Qt расширяет C ++. Вы пишете строку кода, а Qt пишет для вас сотни за кулисами. Тысячи строк и эти дополнительные коды полагаются на проприетарный moc-компилятор Qt (Meta-Object Compiler) и uic-компилятор (User Interface Complier) для повторного перевода вашей строки кода. Проблема в том, что вы должны вызвать moc и uic для предварительной обработки исходного файла Qt перед компиляцией программы, а затем вызвать компилятор для компиляции. Обычный make-файл, описанный выше, не применим и не может предварительно обработать исходный файл qt. Так что qmake родился.
14. Инструмент qmake производится Qt и используется для генерации специальных файлов make-файлов Qt. Этот файл make-файлов может автоматически вызывать moc и uic для предварительной обработки и автоматической компиляции исходной программы. Конечно, qmake также должен быть кроссплатформенным, и, как и cmake, он может генерировать make-файлы для различных платформ.
15. qmake генерирует соответствующий make-файл в соответствии с файлом проекта Qt (.pro). Файл проекта (.pro) относительно прост. Как правило, вы можете написать свой собственный почерк, но обычно он генерируется автоматически Qt Creator, средой разработки Qt. Вам нужно всего лишь нажать на злой треугольник, чтобы закончить его.
Откуда ноги растут
Запрещенных веществ у нас не было (хотя в конце могут возникнуть сомнения). Было кое-что поинтереснее, если вы понимаете о чем я. Да, это легаси 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 vs CMake vs qbs
Пишу некоторые программы на Qt в QtCreator. Пробовал все три системы сборки. Сейчас мне кажется, что с точки зрения удобства, qbs на голову выше всего остального. qmake малофункционален, а CMake страшен как чёрт.
Но это моя точка зрения. Хотел бы узнать аргументированное мнение других.
Хотел бы узнать аргументированное мнение других.
Не вижу ничего особо страшного в CMake. Местами можно было бы и лучше, но зато гибко всё.
А я вообще не понимаю до конца, зачем оно все надо. Получается так: нужен текстовый редактор для набора кода, напр. vim, плюс что-то для сборки, не писать же в ручную make-файлы, напр. CMake или что там еще, плюс отладчик, напр. gdb. В результате получается IDE! Почему бы не использывать готовое, напр. Eclipse или какой-нибудь Qt-creator?
Попробуй ещё autoconf с automake
Попробуй ещё autoconf с automake
CMake намного удобнее, чем qmake. qbs не щупал.
Ты на билд сервер, который собирает либу/апликуху для 5 разных платформ, тоже потащишь еклипс и будешь настраивать для него все 5 тулсетов?
По теме. а qmake научился уже не тащить за собой весь Qt? И что там с qbs сейчас? что требует?
По поводу исходного вопроса: практика показывает, что система сборки не важна, важно скорее аккуратно сконфигурировать сборку. По системам сборки: классическим решением является autotools, он ставит идеологически правильную цель (не писать мейкфайлы, а автогенерировать их из списков зависимостей), но реализует это набором костылей на баше, что многим не нравится. Cmake несколько более «чистый» в этом плане.
Как тут мне говорили.
cmake портабельный, работает со всеми ide и системами сборки. Остальное рядом с ним просто говно.
CMake поддерживает большинство популярных IDE, а qbs используется только в культекреаторе и интегрировать его в другие IDE никто особо желанием не горит. Даже относительно недавняя CLion и то CMake использует.
qbs не пробовал, про qmake и cmake согласен.
CMake намного удобнее, чем qmake. qbs не щупал.
Это смотря как готовить. Что тебя там так пугает?
Классика не устаревает
Но обрастает багами и костылями. Удачи в работе с libtool.
Почему бы не использывать готовое, напр. Eclipse или какой-нибудь Qt-creator?
CMake умеет генерить «проекты» для разных IDE. Про билд-сервер уже сказали.
а им пользоваться не обязательно
но реализует это набором костылей на баше, что многим не нравится. Cmake несколько более «чистый» в этом плане.
Ну костылями я бы это не назвал, скорее использование уже существующих GNU инструментов (bash, make, m4) вместо изобретения велосипедов. Тем, кто раньше с этими инструментами плотно работал, автотулзы покажутся знакомыми и родными. Остальным будет проще начинать сразу с CMake, т.к. порог вхождения ниже, достаточно освоить его простенький макроязык и полистать мануалы с примерами.
зачем это авторитетное мнение в Development?
Кстати, какие системы сборки понимают правила с несколькими целями (то есть генерацию сразу нескольких файлов)? Все известные мне реализации make в этом месте кладут на POSIX.
А еще он очень удобен для всякого bare metal прогинга
Qmake кострат от нормальных систем, cmake универсален, поэтому местами не очень удобен, а qbs так и не научился без локальных конфигов. ИМО cmake
Да, CMake лютое и слабоюзабельное говно, которое нужно подпирать костылями. ЕМНИП, они до сих пор не смогли толково разделить компилятор и линкёр.
У QBS Js головного мозга и зависимости на кучу монструозных Qt5-библиотек, но преимущество в том, что компилит он сам без всяких там дурных make-утилит.
QMake вроде бы прошлый век, но прост как валенок, да и файлы проектов-хелловорлдов на нём выглядят очень просто.
Нормальной системы сборки, которая не только бы была удобной, но и помогла грамотно организовать проект — под GNU/Linux до сих пор нет; и это очень печально.
По теме. а qmake научился уже не тащить за собой весь Qt?
Он никогда ничего за собой и не тащил:
Скорее всего мейнтейнеры твоего дистрибутива — косорукие идиоты.
они до сих пор не смогли толково разделить компилятор и линкёр.
да и файлы проектов-хелловорлдов на нём выглядят очень просто.
Портабельность уровня WinAPI.
Как мне gold использовать в нём без хаков?
Когда дело доходит НЕ до хелловорлда, начинается геморрой с кучей CMake-костылей: Любителям CMake посвящается.
А во втором пункте, так вообще 3.14здобольство с первой строки «У cmake есть ещё одна неприятная особенность – у него нельзя штатными средствами изменить линковщик отличный от того, что выбрал cmake.». Пасаны просто гнушаются доки почитать и в рассылку спросить, а потом ноют, как бабы, ага.
Как мне gold использовать в нём без хаков?
охлол. Ты хоть вчитывался, что там герой топика хочет и делает?
CMake на голову выше QMake, ибо последний есть гора костылей для сборки самого Qt, целью которого никогда не было стать системой сборки общего назначения.
В самом же CMake главная проблема — его язык. Созданный когда-то давно из разумных причин, но потерявший адекватность к настоящему моменту. Регистронезависимость; отсутствие возвращаемых значений; разименование несуществующих переменных без ошибок в пустое значение как на этапе синтаксического разбора, так и на этапе выполнения; отсутствие структур и коллекций; кастрированное позднее связывание между целями сборки; все переменные глобальные, области видимости только в функциях; кастрированная стандартная библиотека без какого-либо стиля именования и порядка аргументов, я до сих пор каждый раз открываю документацию, чтобы вспомнить порядок аргументов, пляшущих от функции к функции.
ИМХО, язык им давно пора заменить на один из промышленных, вроде Python. С ломанием обратной совместимости и утилитами для конвертирования из старого в новое.
Печально признавать, но с таким подходом CMake идёт по классической схеме устаревания, делая ставку на удержание уже имеющихся пользователей. При этом для новых пользователей он слабо способен конкурировать с современными системами сборки, вроде QBS, которые пишутся без оглядки на совместимость.
Толстота уровня «стрелка весов пошла по второму кругу и стекло треснуло».