LINUX.ORG.RU

qmake vs CMake vs qbs

 ,


1

7

Пишу некоторые программы на Qt в QtCreator. Пробовал все три системы сборки. Сейчас мне кажется, что с точки зрения удобства, qbs на голову выше всего остального. qmake малофункционален, а CMake страшен как чёрт.

Но это моя точка зрения. Хотел бы узнать аргументированное мнение других.

Хотел бы узнать аргументированное мнение других.

Не вижу ничего особо страшного в CMake. Местами можно было бы и лучше, но зато гибко всё.

Ну и CMake - это генератор, в отличии от qbs (если ничего не изменилось).

DarkEld3r ★★★★★
()

А я вообще не понимаю до конца, зачем оно все надо. Получается так: нужен текстовый редактор для набора кода, напр. vim, плюс что-то для сборки, не писать же в ручную make-файлы, напр. CMake или что там еще, плюс отладчик, напр. gdb. В результате получается IDE! Почему бы не использывать готовое, напр. Eclipse или какой-нибудь Qt-creator?

hotpil ★★★★
()
Ответ на: комментарий от hotpil

Ты на билд сервер, который собирает либу/апликуху для 5 разных платформ, тоже потащишь еклипс и будешь настраивать для него все 5 тулсетов?

По теме. а qmake научился уже не тащить за собой весь Qt? И что там с qbs сейчас? что требует?

ossa ★★
()
Ответ на: комментарий от hotpil

Потому что это привязывает код к конкретной IDE, чего быть не должно. В реальном мире над кодом часто работают разные разработчики с разными предпочтениями по IDE, это их право. Максимум - можно поддерживать нескольких систем сборки одновременно, например *.vcproj параллельно с qmake.

По поводу исходного вопроса: практика показывает, что система сборки не важна, важно скорее аккуратно сконфигурировать сборку. По системам сборки: классическим решением является autotools, он ставит идеологически правильную цель (не писать мейкфайлы, а автогенерировать их из списков зависимостей), но реализует это набором костылей на баше, что многим не нравится. Cmake несколько более «чистый» в этом плане.

Ради интереса привожу ещё мнение старых пердунов из Bell Labs, которые вообще считают, что всё сложнее чистых makefiles - ересь))

Cheater
()

cmake портабельный, работает со всеми ide и системами сборки. Остальное рядом с ним просто говно.

anonymous
()

Теплое с мягким. qbs - это система сборки, а CMake - это конфигуратор/генератор проектов. Для CMake имеется куча готовых модулей для подключения сторонних библиотек, неплохой гуй для конфигурации параметров сборки, CPack для сборки deb/rpm пакетов или там всяких виндовых инсталляторов. Когда последний раз ковырял qbs, ничего из этого там не было.

CMake поддерживает большинство популярных IDE, а qbs используется только в культекреаторе и интегрировать его в другие IDE никто особо желанием не горит. Даже относительно недавняя CLion и то CMake использует.

Поэтому qbs может являться конкурентом qmake, но никак не CMake. Если задача писать только поделки на культях и только под культекреатор, то да, qbs вполне сгодится. Для всего остального - CMake.

archie
()

qbs не пробовал, про qmake и cmake согласен.

Stil ★★★★★
()
Ответ на: комментарий от panter_dsd

CMake намного удобнее, чем qmake. qbs не щупал.

Что совершенно не мешает ему быть страшным как ядерная война.

Stil ★★★★★
()
Ответ на: комментарий от hotpil

Почему бы не использывать готовое, напр. Eclipse или какой-нибудь Qt-creator?

CMake умеет генерить «проекты» для разных IDE. Про билд-сервер уже сказали.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Cheater

но реализует это набором костылей на баше, что многим не нравится. Cmake несколько более «чистый» в этом плане.

Ну костылями я бы это не назвал, скорее использование уже существующих GNU инструментов (bash, make, m4) вместо изобретения велосипедов. Тем, кто раньше с этими инструментами плотно работал, автотулзы покажутся знакомыми и родными. Остальным будет проще начинать сразу с CMake, т.к. порог вхождения ниже, достаточно освоить его простенький макроязык и полистать мануалы с примерами.

archie
()

зачем это авторитетное мнение в Development?

anonymous
()
Ответ на: комментарий от Stil

Решаешь какой регистр тебе нравится и пишешь в мне - в чем проблема?

panter_dsd ★★★★
()

Кстати, какие системы сборки понимают правила с несколькими целями (то есть генерацию сразу нескольких файлов)? Все известные мне реализации make в этом месте кладут на POSIX.

anonymous
()
Ответ на: комментарий от archie

А еще он очень удобен для всякого bare metal прогинга

Gorthauer ★★★★★
()

Qmake кострат от нормальных систем, cmake универсален, поэтому местами не очень удобен, а qbs так и не научился без локальных конфигов. ИМО cmake

arcanis ★★★★
()

Ни разу не слышал что CMake страшный. Синтаксис у него самый обыкновенный - функция(аргументы). Если не нравится что в endif нужно указывать условие из if - очень зря, это сильно улучшает читабельность. Так очень сильно должно было бы быть в сишном препроцессоре, например. qmake, по мне, годится только для чистого Qt софта - если начинают использоваться дополнительные библиотеки или хитрые ключи компиляции - начинается лапша из условий под разные системы/компиляторы, захардкоженные пути и всё остальное. В итоге всё равно без правок ничего не собирается. На qbs я пока вообще не видел ни одного проекта, так что говорить особо не о чем. Про возможности я читал, ничего выдающегося не увидел.

Итого, сейчас стандарт де-факто это, cmake, я считаю вполне заслуженно и именно его и надо использовать. Он простой, лаконичный и мощный, умеет всё что должна уметь система сборки и реально собирает проекты на машине отличной от машины разработчика без модификаций, в том числе проекты со сложными зависимостями. При этом он умеет и кое-что сверх возможностей системы сборки, например ctest и cpack - очень полезные штуки.

slovazap ★★★★★
()

Да, CMake лютое и слабоюзабельное говно, которое нужно подпирать костылями. ЕМНИП, они до сих пор не смогли толково разделить компилятор и линкёр.

У QBS Js головного мозга и зависимости на кучу монструозных Qt5-библиотек, но преимущество в том, что компилит он сам без всяких там дурных make-утилит.

QMake вроде бы прошлый век, но прост как валенок, да и файлы проектов-хелловорлдов на нём выглядят очень просто.

Нормальной системы сборки, которая не только бы была удобной, но и помогла грамотно организовать проект — под GNU/Linux до сих пор нет; и это очень печально.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от ossa

По теме. а qmake научился уже не тащить за собой весь Qt?

Он никогда ничего за собой и не тащил:

exl@exl-Lenovo-G560e:~$ ldd `which qmake`
        linux-vdso.so.1 =>  (0x00007fff553fc000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f75d2507000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f75d22f0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75d1f2a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f75d1c24000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f75d2848000)

Скорее всего мейнтейнеры твоего дистрибутива — косорукие идиоты.

EXL ★★★★★
()
Ответ на: комментарий от EXL

которое нужно подпирать костылями.

пример костылей

они до сих пор не смогли толково разделить компилятор и линкёр.

Чо? норкоман штоле?

да и файлы проектов-хелловорлдов на нём выглядят очень просто.

дадада. А когда дело доходит НЕ до хеловорда - начинается геморрой с кучей харкода и подпорок.

anonymous
()
Ответ на: комментарий от anonymous

А когда дело доходит НЕ до хеловорда - начинается геморрой с кучей харкода и подпорок.

Когда дело доходит НЕ до хелловорлда, начинается геморрой с кучей CMake-костылей: Любителям CMake посвящается.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Автор - типичный неосилятор и балабол (впрочем, ему там уже расписали).

А во втором пункте, так вообще 3.14здобольство с первой строки «У cmake есть ещё одна неприятная особенность – у него нельзя штатными средствами изменить линковщик отличный от того, что выбрал cmake.». Пасаны просто гнушаются доки почитать и в рассылку спросить, а потом ноют, как бабы, ага.

Как мне gold использовать в нём без хаков?

Без каких хаков? Написания скприта? внезапно, это и есть принцип работы cmake. Все остальное - это нытьё от ниосиляторов.

anonymous
()
Ответ на: комментарий от EXL

охлол. Ты хоть вчитывался, что там герой топика хочет и делает?

anonymous
()
Ответ на: комментарий от slovazap

CMake на голову выше QMake, ибо последний есть гора костылей для сборки самого Qt, целью которого никогда не было стать системой сборки общего назначения.

В самом же CMake главная проблема — его язык. Созданный когда-то давно из разумных причин, но потерявший адекватность к настоящему моменту. Регистронезависимость; отсутствие возвращаемых значений; разименование несуществующих переменных без ошибок в пустое значение как на этапе синтаксического разбора, так и на этапе выполнения; отсутствие структур и коллекций; кастрированное позднее связывание между целями сборки; все переменные глобальные, области видимости только в функциях; кастрированная стандартная библиотека без какого-либо стиля именования и порядка аргументов, я до сих пор каждый раз открываю документацию, чтобы вспомнить порядок аргументов, пляшущих от функции к функции.

ИМХО, язык им давно пора заменить на один из промышленных, вроде Python. С ломанием обратной совместимости и утилитами для конвертирования из старого в новое.

Печально признавать, но с таким подходом CMake идёт по классической схеме устаревания, делая ставку на удержание уже имеющихся пользователей. При этом для новых пользователей он слабо способен конкурировать с современными системами сборки, вроде QBS, которые пишутся без оглядки на совместимость.

Dendy ★★★★★
()
Ответ на: комментарий от EXL

Портабельность уровня WinAPI.

Толстота уровня «стрелка весов пошла по второму кругу и стекло треснуло».

slackwarrior ★★★★★
()
Ответ на: комментарий от EXL

А мужики-то не знали. Там в треде ТСу объяснили, где у него ошибка в ДНК.

slackwarrior ★★★★★
()
Ответ на: комментарий от hotpil

Потому, что:
a) Всем, кто захочет поучаствовать в разработке твоего ПО придется ставить и осиливать тормознутого монстра
б) Ты так гибко не настроишь eclipse, как это можно сделать в описанном тобой случае
в) Ни одна шкурка для gdb не превзойдет по функционалу (да и по удобству, если привыкнуть) сам gdb

peregrine ★★★★★
()
Ответ на: комментарий от Dendy

Регистронезависимость

Ох лол, это надо в + записывать

peregrine ★★★★★
()
Ответ на: комментарий от EXL

Ты почему такой тупой и безграмотный? У тебя родители - наркоманы из депрессивного посёлка, да?

anonymous
()
Ответ на: комментарий от slovazap

Если не нравится что в endif нужно указывать условие из if - очень зря, это сильно улучшает читабельность.

указывать условие в endif давно не является обязательным(где-то с версии 2.6.x), поэтому это на текущий момент только - «сильно улучшает читабельность», что уже само по себе плюс.

dhampire ★★★
()
Ответ на: комментарий от EXL

есть 2 бинарника, как узнать какой их них слинкован через ld.bfd, а какой ld.gold ?

dhampire ★★★
()
Ответ на: комментарий от slovazap

Если не нравится что в endif нужно указывать условие из if - очень зря, это сильно улучшает читабельность.

Это уже давно совершенно необязательно. Читабельность оно кстати никаким боком не улучшает, а скорее наоборот.

m0rph ★★★★★
()
Ответ на: комментарий от EXL

Нормальной системы сборки, которая не только бы была удобной, но и помогла грамотно организовать проект — под GNU/Linux до сих пор нет; и это очень печально.

и чем autoconf/automake неудобны?

Harald ★★★★★
()
Ответ на: комментарий от Cheater

Ради интереса привожу ещё мнение старых пердунов из Bell Labs, которые вообще считают, что всё сложнее чистых makefiles - ересь))

А собственно в чем порочность использования обычных Makefile? Там хотя бы понятно что откуда, меньше авантюризма.

Deleted
()
Ответ на: комментарий от Dendy

ИМХО, язык им давно пора заменить на один из промышленных, вроде Python.

Мне в этом плане нравится Premake с Lua на борту.

anonymous
()
Ответ на: комментарий от slovazap

Так очень сильно должно было бы быть в сишном препроцессоре

Обычно в coding standards прописывается, что писать надо так:

#ifndef PENIS_H__
#define PENIS_H__

// .....

#endif // PENIS_H__
DELIRIUM ☆☆☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.