LINUX.ORG.RU

ZenMake 0.10.0

 , ,


0

3

ZenMake — ещё одна система сборки для C/C++ и ряда других языков программирования с декларативными конфигурационными файлами.

ZenMake написан на python с использованием Waf в качестве фреймворка. Основная цель проекта — быть простым в использовании насколько это возможно, но оставаться достаточно гибким.

Зачем еще одна система сборки? Подробности (на английском): https://zenmake.readthedocs.io/en/latest/why.html

Основной репозиторий: https://gitlab.com/pustotnik/zenmake

Документация: https://zenmake.readthedocs.io/

Примеры использования: https://gitlab.com/pustotnik/zenmake/tree/master/demos

Способы использования:

  1. Установить в систему через pip install zenmake и использовать на манер CMake, Meson и др., вызывая zenmake в корне проекта.
  2. Скачать zipapp-форму zenmake.pyz отсюда или сгенерировать самостоятельно через команду zipapp и использовать как встроенную систему сборки.

>>> Подробности



Проверено: alpha ()

Ответ на: комментарий от pon4ik

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SCons

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

xaizek ★★★★★ ()
Ответ на: комментарий от xaizek
[ "$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 может начинать бугуртить с двойной силой.

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

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

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

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

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

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

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

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

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

  • bazel
  • buck
  • conan
  • gn
  • meson
  • msbuild
  • premake
  • qbs
  • qmake
  • scons
  • shake
  • tup
  • waf
RazrFalcon ★★★★★ ()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от a1batross

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

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

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

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

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

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

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

anonymous ()