Comments 19
В 2020 было коммитов меньше чем в любой год до этого
Но ведь есть 2018. 128 против 133 в 2020.
QMake очень хорошо заточен для разработки на Qt, иногда это сильно проявляется даже в мелочах. Скажем добавить иконку приложения для OSX - всего одна строка в .pro файле.
Для Cmake придётся писать скрипт, который будет править .plist и добавлять шаг сборки. Ничего критического конечно, но с Qmake даже не придётся задумываться об этом.
Можно провести такие аналогии, то qmake — js/python, а cmake — C++.
CMake — диалект Лиспа с небольшим отличием в синтаксисе: название функции ставится перед скобкой, а не внутри.
Что-то автор явно перегнул про QMake, пишу проект с плагинами и утилитами на QMake под windows/linux/macOS и нет проблем, компилятор Linux/macOS - Clang, для Windows - MSVC, в проекте около 40 подпроектов. Как-то попытался перевести проект на CMAKE - сказать, что я офигел - ничего не сказать, в общем не стал насиловать себе мозг и оставил проект на QMAKE ибо в нём не нужно воевать с системой сборки, а заниматься написанием ПО. Хоть CMAKE и набирает популярность, но он очень корявый и требует высокого порога вхождения, да и с QT он всё ещё недружелюбен несмотря на усилия разработчиков QT.
Использую и CMake и QMake в Qt-шных проектах.. в целом не считаю что есть какая то драматичная разница.. и там и там есть плюсы и минусы..
Есть один момент который я не смог победить от слова "совсем" при попытке перейти от qmake в cmake ( может кто то посоветует - что я делаю не так ).. сборка большого Qt проекта под малинку в Docker контейнере WSL (там собран тулчейн для кросскомпиляции) из Visual Studio через VisualGDB с отладкой на реальной малинке.. Qt собран статически - требование заказчика.. в случае с cmake он не может правильно собрать в кучу весь список статических библиотек от используемых модулей qt.. workaround добавить простыню руками, но это как то костыльно на мой вкус.. при этом в той же среде qmake проект генерирует makefile правильно..
Ситуация такая, все собрано в статике, включая плагины и когда используется qmake в финальной линковке он правильно собирает список всех статически собранных плагинов которые нужно прицепить к проекту и их зависимостей, а в случае в cmake цепляются только несколько основных модулей и огромная простыня unresolved и вот что и где сказать в cmake чтобы он их тоже собрал я честно говоря так и не понял.. но грешу на то что это из за того, что qt собрано нн сколько статически сколько под кросскомпиляцию.. если собирать просто статически qt и потом использовать cmake для той же платформы такой проблемы нет..
Используем qmake уж 6 лет, проект из 30+ подпроектов, совершенно никакой головной боли, в нашем случае все работает и все элементарно. Лучшей системы сборки и не пожелаешь.
Сначала я использовал QMake в своих проектах (даже не-Qt-шных), и потом как мой основной проект начал разрастаться, то пользоваться QMake без суровых костылей стало невыносимо. И тут я перевёл все свои основные проекты на CMake, потому что эта система намного более универсальная, более гибкая по функционалу, и, следовательно, более сложная в использовании. По себе я скажу так:
Для маленьких личных проектов, QMake шикарен, не перегружен и удобен. Если надо создать всякую мелочёвку для личных дел, использую QMake до сих пор.
Для больших проектов лучше всё же CMake, потому что выше вероятность возникновения уймы узких мест, с которыми QMake не справится вообще. Использую CMake для создания публичных проектов, с учётом того, что их можно будет собрать под огромный спектр платформ, особенно тех, куда Qt-модули вообще нини.
Если пишите на Qt, то используйте qmake. Меньше проблем больше счастья
Мой голос за QMake
Заводим трактор: QMake -> CMake