ZenMake 0.10.0

интересно, когда-нибудь появиться для C++ система сборки уровня карго?

Карго-школьников уже затыкали здесь. Спойлер: уже появилось.

Надо было их генерацию в configure запихать, а не в build. Хотя я ещё ту версию в бою не проверял, несколько она старт просаживает…

юзать CMake - ад. Даже automake будет где-то лучше, но он ещё хуже CMake

Взаимоисключающие параграфы такие взаимоисключающие.

Makefile

Не переживай, это ведьмак с флаконом - они всегда такие.

Конечно же доходит. Просто уже в виде флагов компиляции внутри сгенерированных файлов.

Это бред. Хотя на хэлвордах может и понятнее - но там на чём угодно понятно будет. Т. е. это не заслуга make, это просто хэлворд.

Нашёл о чём спросить. Я бы узнал, когда оно будет хотя бы так же широко распространено, как и cmake(а лучше ещё ширше). Но это риторический вопрос.

очень жалко что в C/C++ мире стандартом стал угрёбищный CMake с угрёбищнейшим синтаксисом DSL

Это было вполне предсказуемо, ибо конкурентов нет.

Первый адекватный коммент. На самом деле модулей хватит(особенно, если их в апстрим протолкнуть умудриться).

Определение параметров окружения, поиск зависимостей, поддержка разных компиляторов и платформ - до бэкэнда это всё не доходит.

Конечно же доходит. Просто уже в виде флагов компиляции внутри сгенерированных файлов.

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

Вот это ты погорячился, что у waf императивные скрипты. Waf он дуальный: по одному измерению идет днкларативное описание проекта (через bld), зависимостей (через use) и детализация таргета (через features), т.д. В принципе, только это и должно оставаться в wscript. Никакой императивщины там нет. А вот по другому измерению идет расширение системы сборки и детализация, как те или иные фичи преобразуются в команды. И вот это уже гораздо удобнее делать императивно. Но это лежит уже в tools. И вот именно такого деления сильно не хватает в cmake: расширение анализа проекта, чтобы, например, просто пометить таргеты какие-то, и для них всех сделать какое-то действие. Например, поставить версию, или добавить файлы, сгенерировать moc… Или вон как альбатрос чинил: сбросить описание проекта на диск.

В чём его адекватность?

Хватит дробить эко систему

Поздно пить Боржоми, систем сборки уже развелось как тараканов. Причём виновата в этом как раз угрёбишность симейка.

В чём его адекватность?

Вот в этом посыле:

Хватит дробить эко систему

Поздно пить Боржоми, систем сборки уже развелось как тараканов.

Пока вижу только cmake, autotools, autotools-like(ака вручную на скриптах), boost.build(хуже автолулзов) и plain make. Это даже близко не «развелось как тараканов».

Причём виновата в этом как раз угрёбишность симейка.

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

Кстати,

угрёбишность симейка

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

На этом этапе их и не надо искать. Хватит тупить. По такой «логике» компилятор не генерирует машинный код, потому там переменные отсутствуют, а есть только диапазоны адресов. Суть генератора не в сохранении концепций входа в выходе, а в генерации одного по другому.

У cmake одна большая проблема - 15+ лет истории (нашел самое старое - v2.4.0 в 2006г). И если у него есть legacy, значит проект успешный. Как Бьярне говорил: есть или проекты с легаси, или которыми никто не пользуется.

Многое из упоротости синтаксиса - результат необходимости поддерживать старые проекты.

Поэтому сейчас есть тн «modern cmake», который и надо учить и пользовать в новых проектах.

Ещё SCons и что-то гугловое, не помню названия, как минимум. Знаю даже унтерменшей, который gradle для проекта на плюсах юзают. И ты так говоришь, будто маргинальных поделий типа сабжа мало на свете.

На этом этапе их и не надо искать

Конечно не надо - всё уже найдено самим cmake-ом. Я об этом и говорил.

Суть генератора не в сохранении концепций входа в выходе, а в генерации одного по другому.

Подожди, но ведь тогда make - это тоже генератор(сорцы + мэйкфайл -> бинарь). И многие(если не все) другие программы тоже являются генераторами. Формально можно и так рассуждать, вот только пользы от этого никакой.

Не знаю релатных альтернатив кроме мезона, но хрен редьки не слаще, как по мне. Претензии были выше.

И многие(если не все) другие программы тоже являются генераторами. Формально можно и так рассуждать, вот только пользы от этого никакой.

Зависит от контекста.

Подожди, но ведь тогда make - это тоже генератор(сорцы + мэйкфайл -> бинарь).

В контексте сборки make берёт правила сборки и собирает. А cmake берёт одни правила сборки и выдаёт другие правила сборки, т.е. самостоятельно сборку он не выполняет, только подготовку к ней. В итоге он не способен выполнять задачу системы сборки без другой системы сборки. Это не доведение задачи до конца и делает его лишь генератором. То, что он делает работу по поиску зависимостей, суть не меняет, так как это не основная функция системы сборки.

SCons

Название знаю, но ни разу не встречал. Я думал, оно уже сдохло.

Знаю даже унтерменшей, который gradle для проекта на плюсах юзают

Да я тоже знаю - на прошлой странице был один: ZenMake 0.10.0 (комментарий).

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

Ну и зачем делать +1, когда и так не слишком хороши дела?

но хрен редьки не слаще, как по мне

И по мне тоже. Поэтому cmake.

Поэтому сейчас есть тн «modern cmake»

К которому ровно те же претензии по синтаксису(посты того же EXL поищи здесь). Я не знаю, почему так много ненависти из-за синтаксиса - к нему просто привыкаешь и всё.

В контексте сборки make берёт правила сборки и собирает. А cmake берёт одни правила сборки и выдаёт другие правила сборки, т.е. самостоятельно сборку он не выполняет, только подготовку к ней

Я не заявлял, что cmake сам может собирать.

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

make и ninja(и, возможно, другие бэкэнды cmake) - это не системы сборки. До СС они не дотягивают по функциональности.

А для меня программа не является СС, если она не в состоянии взять исходники и собрать бинарники. Зависимости и остальное это всё дополнительные функции. Не важно сколько таких функций, если главной (исходники -> бинарники) нет, то это не СС (не она ж собирает).

[ "$SRC1" -nt "$OBJ1" ] && gcc -c -o "$OBJ1" "$SRC1" &
[ "$SRC2" -nt "$OBJ2" ] && gcc -c -o "$OBJ2" "$SRC2" &
wait
{ [ "$OBJ1" -nt "$BIN" ] || [ "$OBJ2" -nt "$BIN" ] ; } && gcc -o "$BIN" "$OBJ1" "$OBJ2"

Bash-то, оказывается, система сборки. Пилите новость, кому скор нужен. EXL может начинать бугуртить с двойной силой.

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

Молодой проект не поддерживает ненужно-ОС? Трагедия.

Пусть расцветают сто цветов

От этого разрываются флаконы у растоманов. Теперь(после появления карго) на крестах сегфолты по сто раз в секунду не только в рантайме, но и при сборке.

авось какого-нибудь сумрачного гения всё задолбает и он запилит что-нибудь такое, что похоронит все остальные системы сборки, как Git похоронил остальные VCS

Там просто был один фин и сотни его фанатиков. Но посмотрим, может и сделает кто.

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

Но Bazel уже существует.

Ну у мезона тоже фин

Пока вижу только cmake, autotools, autotools-like(ака вручную на скриптах), boost.build(хуже автолулзов) и plain make.

• bazel
• buck
• conan
• gn
• meson
• msbuild
• premake
• qbs
• qmake
• scons
• shake
• tup
• waf

Написал все, что знал? Frogarian ни разу не система сборки. Некоторые системы пытаются скрестить менеджер пакетов с системой сборки, но не он.

conan

Знатно на ноль поделил.

Про qmake я забыл - тоже встречается иногда. Остальным никто не пользуется, кроме никому не нужных поделок.

И кто его юзает в дикой природе?

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

gn используется в гугле для хрома и всех сопутствующих либ.

Почти весь гном на meson.

Но что взять с анонима.

Всё, как я и говорил: никому не нужные поделки.

Тогда может быть стоит примерчик показать, что вот есть такая задачка, и на cmake оно переусложнено вот так и так, а на этой новой системе сборки гораздо удобнее, потому что, и тут пример конкретный

Тогда может быть стоит примерчик показать…

… всем сборочным системам отличным от cmake, для оправдания своего существования. Иначе это избирательное применение против неугодных - личная неприязнь.

Ну и зачем делать +1, когда и так не слишком хороши дела?

Очевидно, чтобы навсегда низвергнуть это говно (CMake) из экосистемы C и C++, как низвергли autotools’ы.

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

С изучения матчасти.

Матчасть написана в стартовом сообщении - взять waf и попытаться упростить использование. Ты знаешь waf? Причем тут cmake и почему именно cmake?

Я вывел отдельную команду clangdb для таких случаев.

Думаю, что шмейк, что остальные мезонсы тоже не мгновенно стали широкоиспользуемыми.

Ну это фантазии всё, десять с лишним лет пытаются и никак не низвергнут.

А по ссылке обычный плач:

1. типичное поведение любой скриптухи
2. очевидно, автор сборки не учёл зависимость между двумя переменными, откуда кэш должен это знать: сказано внести значение - оно и внесло(угадывать мысли макак никто не хочет, да и не может)
3. мне не поверят, но на shell и tcl вызов функции вообще скобок не содержит и, сейчас вообще говном закидают, это не создаёт ровно никаких проблем
4. очередная маня-хотелка вида «нужно уметь собирать проект с cmake-ом без cmake-а» - бредятина как она есть
5. да, вот здесь есть разумное зерно(но автору не нужна кроскомпиляция, с его-то познаниями)
6. вообще никакой конкретики, читаем как «мне не нравится»

Уже не первый(и не второй) человек плачется здесь. Ты сам вообще аргументировал свою позицию вот так:

Оценки хелловорлда тред (комментарий)

Вышел LLVM/Clang 3.9 (комментарий)

система для сборки с зависимостями для C++ (комментарий)

Спойлер: «регистронезависимость». Куда там до низвержения, лол.

И кто его юзает в дикой природе?

Я сейчас сайт себе делаю. Приглашаю, как будет готов.

Владимир

Не знаю, как у zenmake, у cmake есть ряд трудностей и неудобств при кросс-компиляции.

1. я так и не нашел возможности использования нескольких компиляторов сразу. Например собираем прошивку для железки и сразу же библиотеку для работы с ней с компа.

2. toolchain файлы для кросс-компиляции - довольно неудобный инструмент.

3. когда ключевые опции задаются в суб-суб-директории, например arch/<platform>/, то распространить их на весь проект также бывает не очень удобно

Все это в принципе решаемо, но неудобно

makefile - тупое говно тупого говна

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

Просто запускать на build - это дополнительный оверхед, тк дерево будет обходиться минимум, 2 раза: один раз на clangdb, второй раз на build, при создании контекста (хотя может ваф это закеширует…). Это дополнительные расходы при тормозном диске (у меня на замапленном с хоста каталоге это занимало 10с, хотя обычно доли).

Да и не нужно оно наверное.

А вот на configure (после) - это логично. Так и cmake делает.

Где там что-то хотя бы близко аналогичное? И всеиспользуемое (это важнее)?

Лень читать весь тред, там слишком много взрыбков последователей царька, считающих, что UB++ лучше Раста)