А вы и собираться за меня будете? Ага! Вспоминаю систему сборки для плюсов

Это точно нормально сравнивать сборку самого Qt с используемыми им системами сборки? По факту они уже 3 года тянут поддержку легаси в виде системы сборки qbs и прямо уж совсем выгнанным на мороз его не назвать.

Зависимость cmake от make/ninja/etc. несоизмеримо большая чем зависимость make от драйвера компилятора. make может и без драйвера обойтись за счёт гемора, а cmake без того же make не будет работать (хотя может и будет в каком-то виде). Более самодостаточный софт мне предпочтительнее.

Не в вечной бете, более активный и готовый. Поддерживает, наверно, больше всякого (по типу андроидов и т.д.). premake сам собрать проект не мог, создавал makefile, а xmake и сам может собирать.

Зависимость cmake от make/ninja/etc. несоизмеримо большая чем зависимость make от драйвера компилятора. make может и без драйвера обойтись за счёт гемора, а cmake без того же make не будет работать (хотя может и будет в каком-то виде). Более самодостаточный софт мне предпочтительнее.

Какая разница, бошьшая зависимость или меньшая. Главное, что она есть. Преимущество в виде «меньшая зависимость» что практически дает?

Меньшая зависимость = большая самостоятельность компонентов, которые более цельные. LamerOk выше более точно выразил, что меня напрягает: с cmake для процесса сборки нужно на одно приложение больше. Компилятор же будет всегда и какая-то система сборки тоже (кроме тривиальщины), но двух-фазная система сборки более геморойна по сравнению с однофазной. У однофазных сообщения об ошибках лучше, не будет боков из-за несоответствия их версий, не будет боков с переконфигурированием, когда надо сносить каталог и начать заново, потому что вторая фаза тупит и требует обновления из первой, но не знает этого.

Трансформироваться» этот тезис может, только если бы первая и вторая версии в чём-то отличались.

А не пи3Dи ты. Одинаковые тезисы, ага. Только идиот может считать это одним и тем же тезисом.

Это всё умеет любая приличная система сборки, не говоря уж нормальных решениях, типа Make.

Ага ну давай сравним размер кода Makefile для задачи обычной сборки с предварительным получением из git хэша коммита и ликновкой с парой библиотек, установки, копирования зависимостей, сборки deb пакета.

Ну, давай. Выйди к доске и покажи всему классу

А за воротник тебе не дать?

Кому ты горбатого лепишь?

Ну видимо шуту местному.

Меньшая зависимость = большая самостоятельность компонентов

Это теория. Конкретные кейсы есть, когда есть проблемы?

У однофазных сообщения об ошибках лучше

CMake выдает ровно те же сообщения от нижележащей системы сборки.

LamerOk выше более точно выразил

Он написал то же, что и говорят все хейтеры cmake: нормальные системы сборки и т.п.

А в чем конкретно (кейсы с пррмерами) cmake плох - никто не осилит сказать.

Я тебе выше написал. Это характерно и для autoconf, и для meson, и для cmake, и для premake, но у тебя так горит от упоминания именно cmake, что ты этого не видишь. Можешь продолжать им пользоваться, если он тебе так нравится.

Ничего ты не написал конкретно. Все ваши аргументы - плохо, что сам не собирает, лишняя сущность, херовый синтаксис и т.п. Конкретно что нельзя сделать на нем - хз.

но у тебя так горит от упоминания именно cmake

Потому что у вас аргументов ноль. И вы «херовый cmake» - используете как аксиому.

Можешь продолжать им пользоваться, если он тебе так нравится.

Спасибо, сэр.

CMake, это прям какой-то C++ из мира систем сборки.

xmake и сам может собирать.

Ок, заинтересовал. Надо будет посмотреть, что это за штуковина такая.

Потому что у вас аргументов ноль.

«И имя мне – Легион!»

Ты сам некоторые аргументы выше перечислил, а теперь говоришь, что это не аргументы… Может для тебя и нет, а для остальных это очевидно имеет значение. Я поэтому и говорю: нравится – пользуйся.

Ты сам некоторые аргументы выше перечислил, а теперь говоришь, что это не аргументы… Может для тебя и нет, а для остальных это очевидно имеет значение.

Ок. нравится – НЕ пользуйся (с).

Но, если ты приводишь на публичном ресурсе утверждение, будь готов, что его оспорят.

1. Херовый синтаксис. - Субъективно. Какая мера херовости?

2. Сам не собирает. - Так и другие системы сборки не собирают сами.

3. Дальше хитрец Lamerok привел аргумент, что ладно мол сам не собирает, так он еще и сам компилятор не вызывает. - Ну ок. Этот факт сам по себе чем плох? Какую этот несет ошибку или какое неудобство? Из-за этого кейса нельзя реализовать какую-нибудь задачу? Там был ответ, что сообщения об ошибках лучше без cmake, на что я ответил, что нет, те же самые. По крайней мере на g++/clang/msvc, может на других компиляторах иначе, но кто же привел пример с кейсом.

Я не говорю, что ваши аргументы - не аргументы, я говорю, что это спорные аргументы и вот почему. А вы кроме этих теорем конкретных примеров не приводите.

Я же не фанатик и готов согласиться с тем, что cmake - херня на постном масле. Но докажите, приведите примеры с кейсами:

• Вот тут не работает то-то и то-то.
• Вот тут невозможно реализовать такое-то поведение.
• Вот тут не выводится то-то.

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

Субъективно. Какая мера херовости?

Субъективная, кэп. Регистро-независимость. Многословность. Дебильные скобки, где не надо. Пробелы вместо разделителей. Подстановка переменных с поведением как в bash при их пустом значении (надо брать в кавычки, чтобы вело себя нормально). Скопировали тупо худшие аспекты autoconf, которые не было необходимости копировать от слова совсем (здесь же нет макропроцессора для оболочки).

Сам не собирает. - Так и другие системы сборки не собирают сами.

Вот как с тобой можно разговаривать, если ты просто игнорируешь сказанное и бессмысленно повторяешь свой тезис? Пусть будет так: cmake разделяет сборку на генерацию правил в файлах и их исполнение внешней независимой программой в отличии от ряда других систем сборки, которые обходятся своими силами. Так понятней?

Там был ответ, что сообщения об ошибках лучше без cmake, на что я ответил, что нет, те же самые.

А я не об этих ошибках говорил. А о тех, которых не должно быть. Пример: ninja мне ругается на отсутствие файла, путь к которому meson в ней прописал, но не прописал, что надо переконфигурировать, если его нет. А могло бы просто использовать другую ветку условий, если бы сборку в полном объёме делал meson.

Но докажите

А я их документировал? Он мне доставлял геморрой в разных юзкейсах, мне этого хватило, а ты сам смотри.

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

А ты дома в тетради пиши, тогда никто не оспорит.

Вот как с тобой можно разговаривать, если ты просто игнорируешь сказанное и бессмысленно повторяешь свой тезис? Пусть будет так: cmake разделяет сборку на генерацию правил в файлах и их исполнение внешней независимой программой в отличии от ряда других систем сборки, которые обходятся своими силами. Так понятней?

Ха. Ты игнорируешь первоначальный тезис и задвигаешь новый. Не я сказал, что cmake не вызывает компилятор - и в этом его херовость.

Пример: ninja мне ругается на отсутствие файла, путь к которому meson в ней прописал, но не прописал, что надо переконфигурировать

Я так полагаю тут про cmake? Можно пример?

А я их документировал? Он мне доставлял геморрой в разных юзкейсах, мне этого хватило, а ты сам смотри.

Хм. Ну дык следующий раз документируй. А то получается как почтальон Печкин. Столько проблем, столько проблем - Каких - Да не помню.

Субъективная, кэп. Регистро-независимость. Многословность. Дебильные скобки, где не надо. Пробелы вместо разделителей. Подстановка переменных с поведением как в bash при их пустом значении (надо брать в кавычки, чтобы вело себя нормально). Скопировали тупо худшие аспекты autoconf, которые не было необходимости копировать от слова совсем (здесь же нет макропроцессора для оболочки).

В целом все так. Но достаточное ли это основание для того, чтобы пилить херову гору систем сборки? И вносить вклад в отсутствие единого стандарта для выбора системы сборки?

Ничего ты не написал конкретно. Все ваши аргументы - плохо, что сам не собирает, лишняя сущность, херовый синтаксис и т.п. Конкретно что нельзя сделать на нем - хз.

А может будут какие-то аргументы в пользу «непрямой» сборки? Почему cmake не дергает компилятор напрямую? Вот какие это плюшки даёт? Хоть одну скажи, может я соглашусь даже тогда.

Пока лишь видно переусложнённую архитектуру, страшный сон перфекциониста. Здоровая тяга к простым и красивым решениям, а не к вороху дерьма и костылей на костылях. Аналогично с мезоном или с конаном каким-нибудь, где всё обмазано тройным слоем пистона, непрятно держать в руках.

Так кроме самого факта нет и у меня аргументов. А если и там нет и там - так может один хрен, что там под капотом вызывается?

Субъективная, кэп. Регистро-независимость. Многословность. Дебильные скобки, где не надо. Пробелы вместо разделителей. Подстановка переменных с поведением как в bash при их пустом значении (надо брать в кавычки, чтобы вело себя нормально). Скопировали тупо худшие аспекты autoconf, которые не было необходимости копировать от слова совсем (здесь же нет макропроцессора для оболочки).

Нужны ли специальные типы данных (списки) кроме строк? Если напрягает пробел в качестве разделителя, так можно при добавлении использовать list APPEND.

Подстановка переменных с поведением как в bash при их пустом значении.

Ну да. Это следствие того, что есть только строки.

Но нужно ли в системе сборки добавлять полноценные типы и структуры данных?

Но нужно ли в системе сборки добавлять полноценные типы и структуры данных?

Как раз таки нет необходимости, это же по сути скрипт, в классическом его понимании. Всё строковое и некоторые вещи даже проще делать, вот банальный пример:

project(MyProgram VERSION 1.0.0)
set(RUNTIME_OUTPUT_NAME "${PROJECT_NAME}-${PROJECT_VERSION}")
# Теперь RUNTIME_OUTPUT_NAME == "MyProgram-1.0.0"

Если только по методу «восход солнца вручную».

Что, уже появились телепатические системы сборки, считывающие требования прямо из волн мозга? Твой CMake соберёт мне проект с помощью Pelles C под Windows CE без каких-либо действий с моей стороны? Или как обычно шаг - вправо, шаг - влево и вся «мощь» CMake’а испаряется в лучах восходящего солнца, и на практике выясняется, что это эта херня из коробки работает в трёх с половиной примитивных случаях? И, как обычно, весь фанбоизм CMake-фанбоев объясняется тем, что их айсикью хватило только на то, чтобы скопипастить пример из гугла и собрать по инструкции их хеллоуворлд на локалхосте?

А Make как будто не часть костылей UNIX / POSIX.

Что там ещё у тебя попало в список «костылей»? yacc? awk? tcl?cc? perl? lex? eqn?

cmake не вызывает компилятор - и в этом его херовость.

Это лишь один из его существенных недостатков, который порождает более мелкие.

Хм. Ну дык следующий раз документируй. А то получается как почтальон Печкин. Столько проблем, столько проблем - Каких - Да не помню.

Вот ты и собирай по сайтам, а потом делай видео, где все неправы, а ты прав в тиктоке. А я просто буду использовать что-то лучше.

cmake не вызывает компилятор - и в этом его херовость.

Это лишь один из его существенных недостатков, который порождает более мелкие.

Ты бы ещё предложил в него компилятор запихнуть.

CMake и Meson используют отдельные генераторы только ради совместимости с разными IDE и редакторами, дабы пользователи новички не ныли - «а почему этот проект неработает в моей проприетарной IDE». Взять хотя бы тот же qbs и jam, многие ли IDE поддерживают их?

Новички обламаются на этапе генерации или потом будут удивляться, что изменения в/из IDE не отражаются. Ориентироваться на них не стоит. Да и они же (cmake) потом какой-то демон пилили, чтобы IDE с cmake взаимодействовало, так как IDE было сложно его использовать. Это просто исторически не в ту сторону пошло и исправлять надо где-то в IDE (плагинами для систем сборок или вроде того).

Да, это проблема. Насколько я знаю сейчас с этим борются через перегенерацию файлов и общение IDE с системами сборки идёт через специальное API: CMake, Meson. Всё остальное по идее IDE должна делать своими силами.

Вот ты и собирай по сайтам, а потом делай видео, где все неправы, а ты прав в тиктоке. А я просто буду использовать что-то лучше.

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

«Если я что-то утверждаю, я не обязан представлять доказательства. Если вы утверждаете обратное, опровергая меня, это вы должны доказательства представлять. Разве это не так?

Типо раз я что-то написал, то теперь «по логике» обязан тебя развлекать? Щас же, мы не на формальных дебатах и у меня нет никакого интереса тебе что-то доказывать. И требуешь доказать, что ты неправ, как раз ты:

Я же не фанатик и готов согласиться с тем, что cmake - херня на постном масле. Но докажите, […]

Это я написал ПОСЛЕ того, что написал ты и компания. А раз ты написал ииенно ЧТО-ТО, а доказывать лень, то грош цега таким утверждениям.

Взять хотя бы тот же qbs и jam, многие ли IDE поддерживают их?

Ну по Qbs по крайней мере в VSCode и QtCreator есть поддержка.

Я бы прикрутил и к другим IDE, например Eclipse и прочим, если бы знал JAVA. :)

Qbs не трудно прикручивать - там очень простой АПИ.