qmake vs CMake vs qbs

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

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

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

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

Попробуй ещё autoconf с automake

http://www.gnu.org/software/autoconf/manual/autoconf.html

https://www.gnu.org/software/automake/manual/automake.html

Попробуй ещё autoconf с automake

Не, не хочу.

а зря

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

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

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

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

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

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

Попробуй ещё autoconf с automake

Как тут мне говорили...

10.02.2015

Okay

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

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

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

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

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

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

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

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

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

По теме. а 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)

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

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

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

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

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

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

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

cmake портабельный

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

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

http://stunpix.com/post/cmake-weak-sides/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если нравиться qbs, то потыкай в scons.

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

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

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

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

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

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

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

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

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

а можешь назвать минусы scons? кстати, вопрос для всех присутствующих, кроме питонофобов.

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

Кстати, annulen, как там premake проживает?

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

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

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

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

#ifndef PENIS_H__
#define PENIS_H__

// .....

#endif // PENIS_H__