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 ()
Последнее исправление: cetjs2 (всего исправлений: 4)

Я автор. Изначально делал для себя. Потом решил, что это может стать неплохим opensource проектом.

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

А в чём главные отличия от Waf?

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

Стараюсь много своего не добавлять, чтобы люди могли просто стянуть максимум два Python файла в свою сборку Waf.

Открыл документацию. Развитие в сторону декларативщины это хорошо.

a1batross ★★★★★
()
Последнее исправление: a1batross (всего исправлений: 1)

Premake/GENie

I haven’t tried to use it because I forgot about its existence. But it’s not a build system. It’s a generator for some other build systems […]

Так CMake и Meson это тоже генераторы.

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

ZenMake использует Waf только как фреймворк. Waf - императивные скрипты, а ZenMake - декларативные конфиги. Я даже избавился от wscript файлов, ибо в ZenMake они были лишней сущностью рядом с buildconf.py/.yml. Поэтому по использованию ZenMake больше похож на Bazel, чем на Waf, CMake, Meson и т.д.

Пользователю ZenMake не нужно знать о Waf вообще ничего. Уже сейчас я понял, что не надо было вообще упоминать Waf, ибо это только сбивает с толку.

Главная особенность ZenMake - простые в использовании декларативные конфиги. Но, при этом, если очень хочется, то можно и на питоне в buildconf.py свое добавить.

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

Meson можно назвать генератором к ninja (хотя он уже вроде умеет и другие бэкэнды, тот же CMake), однако ninja это не система сборки «для людей», это специальная система сборки, для которой как раз нужна «человеческая» система сборки над ней. Поэтому Meson это все такие не такой генератор как Premake.

А почему CMake был назван генератором, я не понял. Он же вроде полностью самостоятельный, нет? Я чего-то не знаю?

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

А, забыл, еще про одно отличие от Waf. Автор Waf, по каким-то своим заморочкам, не хочет, чтобы Waf можно было поставить в систему (через тот же pip), он ради этого даже специально другую лицензию на свой wafbook сделал. У меня нет таких заморочек, ZenMake можно как установить в систему через pip, так и использовать как встроенную в проект систему сборки в так называемой zipapp форме. Я добавил в новость об этом. Хотя все это есть в документации.

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

А почему CMake был назван генератором, я не понял. Он же вроде полностью самостоятельный, нет? Я чего-то не знаю?

Он как и Premake и Meson генерирует код для Make, Visual Studio, XCode или Ninja. Meson бы и для Make генерировал, но у автора пунктик по поводу него. Так что Meson здесь не особенный, это просто Ninja не сам по себе.

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

Он как и Premake и Meson генерирует код для Make, Visual Studio, XCode или Ninja.

Хм, я почему-то думал, что CMake независимый. Ну ок. Потом поправлю свои доки.

Vark
() автор топика

О, что это за новый тег такой «от автора»? Вроде не было же раньше такого.

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

Ну значит появился. Тег можно какой угодно создать

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

Есть cmake…

А вот и первый коментарий про то, что есть cmake и больше ничего не нужно.

Давайте так. Я не буду больше никак коментировать подобные коментарии, потому что это не имеет смысла. Если вас устраивает cmake или другая система сборки, то вы все равно не заинтересованы в других системах сборки. Моя система сборки может быть интересна только тем, кто, как и я, недоволен по тем или иным причинам уже существующими. А подобные вашим коментарии говорят лишь о желании лишь бы написать что-нибудь и/или поспорить. Но мне это не интересно.

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

Я посмотрел специально примеры синиаксиса у тебя и не увидел никакой простоты. Не увидел как организкются завистмомти. Лишь анплог просто глоба. О поддержке 3rdparty библиотек я вообще молчу.

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

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

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

Не увидел как организкются завистмомти. Лишь анплог просто глоба. О поддержке 3rdparty библиотек я вообще молчу.

Полагаю смотрел только quickstart guide. Признаю мне было лень расписывать все там, я понаделся на то, что люди посмотрят реальные примеры. О чем последняя строка в quickstart guide. Там есть и 3rdparty библиотеки и много чего еще. Правда некоторые примеры излишне многословны, потому что они еще используются и как функциональные тесты, т.е. там некоторые параметры задействованы просто чтобы их тестировать.

Мне показалось, что пихать все в quickstart guide будет слишком жирно по объему. Хотя, возможно стоит добавить в документацию некоторые типичные кейсы.

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

Осилятор, не волнуйся. Но это не отменяет того, что я считаю его переусложненым. Это мое мнение конечно, но тем не менее.

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

Да нет, просто его синтаксис весьма печален и мог бы быть гораздо лучше

Впрочем, пока не вижу и радости от этого варианта. Можно примеров в сложных проектах с тонной зависимостей?

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

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

Ясно ниасилятор

Я тоже неосилятор CMake. На платформах с нелинуксовыми тулчейнами юзать CMake - ад. Даже automake будет где-то лучше, но он ещё хуже CMake в целом, потому что переусложнен и потому что sh скрипты, которые ещё и медленные.

Skullnet ★★★★★
()
Последнее исправление: Skullnet (всего исправлений: 2)

Узнаю ЛОР. Ненужно, неасилятор, скоро думаю еше какие хвалебные отзовы подъедут. Все желание что-то объяснять и вообще делать просто пропадает.

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

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

Skullnet ★★★★★
()

Сорян, чувак, но простые примеры наглаядно показывают, что сабж не нужен, ибо Makefile гораздо нагляднее чем это. А те, что посложнее вообще хрень какая-то непонятная хуже чем CMake.

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

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

Но он ведь тоже отвратительный, с ним, перед тем как начать использовать, нужно сначала смириться. С тем же успехом можно смириться почти с чем угодно. Простой и понятной системы сборки помимо make в природе пока попросту не существует.

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

С чём там мириться? Написал конфиг в две строчки и всё работает. Даже внешние зависимости качает. Самое близкое к Cargo.

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

Впрочем, пока не вижу и радости от этого варианта.

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

Можно примеров в сложных проектах с тонной зависимостей?

С тонной нет, увы. Изначально я вообще не планировал, что эта система будет использоваться в огромных проектах. Это не значит, что этого нельзя делать, но не знаю какие тут могут быть сложности. Я вроде предусмотрел все основные потребности, но мог что-то упустить.

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

Карго это который в rust? Пока что не имел с ним дел, но вроде это пакетный менеджер, нет?

Vark
() автор топика

Набросал бы список киллер-фич в стартовый пост. Идти по ссылкам читать рунглийскую документацию, ну сам понимаешь.

Плюсую неадеквата с Make — самый простой вариант для небольшого некроссплатформенного проекта.

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

Есть вот такой проект как harfbuzz - там сразу три системы сборки: autotools, cmake и meson. Можно наглядно какая из них самая простая (meson).

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

Makefile гораздо нагляднее чем это

Серьезно? Посмотрел я значит на Makefile, который специально делал для demos/external-deps/1-makefile/foo-lib/, почесал репу. Ок. Даже спорить не буду.

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

Нет чёткой стройной декларации. Выглядит как императивщина.

Может, я просто не в курсе, и туда какой-то альтернативный язык конфигов завели, но, вроде бы, нет.

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

Собирать говнокод на плюсах в декларативном виде никто не сможет, увы.

RazrFalcon ★★★★★
()

Конфиги на питоне — нечитаемое и раздутое говно. YAML выигрывает по всем пунктам, но в примерах (C++) почти не представлен. Однако неясно вот что (взял за образец пример с quickstart):

tasks:
  util :
    features : shlib
    source   :  { include : 'shlib/**/*.cpp' }
    includes : '.'
  program :
    features : program
    source   :  { include : 'prog/**/*.cpp' }
    includes : '.'
    use      : util

buildtypes:
  debug :
    toolchain : auto-c++
  release :
    toolchain : g++
    cxxflags  : -O2
  default : debug

  • source : { include : 'shlib/**/*.cpp' } Тут есть следующие моменты:
    • по идее source — всего лишь список файлов, которые будут переданы компилятору, что наглядно видно в одном из примеров. Зачем же здесь из них делается что-то другое?
    • что за семантика у include?
  • includes, насколько я понимаю, аналог target_include_directories в CMake. Однако в CMake есть CMAKE_SOURCE_DIR и CMAKE_CURRENT_SOURCE_DIR, а относительно чего работает точка?
XMs ★★★★★
()
Ответ на: комментарий от RazrFalcon

В твоём примере выглядит очень хорошо, а вот на примере harfbuzz как-то не убедительно. С autotools даже разбираться не хочется, это не для людей, но в сравнении с cmake принципиальной разницы не видно, разве что строки считать.

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

Согласен. Но я это к тому, что те, кто уже смирился с CMake, особенную разницу вряд ли почувствуют.

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

YAML выигрывает по всем пунктам, но в примерах (C++) почти не представлен

По сути все, что можно описать в питоновском формате, можно описать в YAML формате. Как раз для тех, кому питон режет глаза, я добавил YAML. Согласен, что на питоне местами выглядит раздуто, но придумывать свой язык для этого я считаю перебором.

по идее source — всего лишь список файлов, которые будут переданы компилятору, что наглядно видно в одном из примеров. Зачем же здесь из них делается что-то другое?

Ничего другого здесь не делается. Тут include это не includes , которые .h/.hpp, это часть ant patterns, детальней здесь: https://zenmake.readthedocs.io/en/latest/buildconf-taskparams.html#source

Т.е. здесь include описывает какие файлы включать, потому что есть еще и exclude.

Хотя я ввел уже упрощенный вариант, когда exclude не нужен, то можно просто написать source : 'shlib/**/*.cpp'

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

Однако в CMake есть CMAKE_SOURCE_DIR и CMAKE_CURRENT_SOURCE_DIR, а относительно чего работает точка?

Относительно значения параметра startdir, который по умолчанию указывает на каталог, где находится buildconf.py/.yaml : https://zenmake.readthedocs.io/en/latest/buildconf.html#startdir

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

Аналог CTest предполагается?

Я CTest не пробовал, но запуск тестов есть: https://zenmake.readthedocs.io/en/latest/tests.html

Как поддержана кросскомпиляция?

Пока только через такое: https://zenmake.readthedocs.io/en/latest/buildconf.html#toolchains

Т.е. через настройку переменных окружения тулчейна для кроскомпиляции.

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

Я makefile вообще не знаю и он для абсолютно нечитаем.

Вообще не читаем

hello: main.o hello.o
    gcc -o hello main.o hello.o

main.o: main.c hello.h
    gcc -c main.c

hello.o: hello.c hello.h
    gcc -c hello.c
fsb4000 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.