ZenMake 0.10.0

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

Надо примеры использования.

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

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

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

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

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 это тоже генераторы.

Есть demo projects: https://gitlab.com/pustotnik/zenmake/-/tree/master/demos

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

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

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

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

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

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

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

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

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

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

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

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

Есть cmake…

Что сложного в

add_library(X)
target_sources(X PRIVATE x.cpp)
target_link_libraries(X PRIVATE Y Z)

?

Есть cmake…

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

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

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

CMake is too complicated

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

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

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

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

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

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

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

Есть божественные автотулзы, всё остальное ненужно

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

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

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

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

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

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

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

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

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

ninja Well, I don’t know a lot about this system.

Аналитика уровня лор…

Уже есть meson. Больше не нужно.

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

Это который не умеет в пробелы в именах файлов?

Уже есть meson. Больше не нужно.

Переусложненное говно, уж лучше CMake.

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

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

Шта? CMake в миллион раз сложнее meson.

Зачем тебе пробелы в именах файлов?

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

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

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

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

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

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

Почему нет?

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

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

Ну, нет их и нет, какая разница?

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

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

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

А мне вот хочется.

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

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

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

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

Конфиги на питоне — нечитаемое и раздутое говно. 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, а относительно чего работает точка?

Там сразу понятно, что происходит, не нужно даже знать что такое Makefile в принципе, чтобы разобраться.

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

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

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

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

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

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

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

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

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

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

Я 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