Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Mikhail Yakshin <greycat@altlinux.org>]

Приветствую,

>> Если не секрет, в двух словах, чем эта альтернатива лучше scons, например?
>> Спасибо.
>
> Если в двух словах, то mk-configure - это логическое продолжение mk
> скриптов в BSD системах. Те, кто видел дерево исходников BSD систем
> (базовые системы, не порты) понимают, о чем я. mk-configure -- развитие
> тех же идей с добавлением ala autoconf функциональности и кое-чего
> другого типа замены @полей@ в .in файлах.
> Но основные идеи следующие:
> - декларативный способ написания Makefile-ов;
> - никакой годогенерации;
> - модули пишутся на bmake и внешних скриптах на POSIX shell + unix tools,
> естественно никто не запретит использовать другие средства.

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

Perl/Python/Ruby с некоторой натяжкой есть на практических всех
современных Linux/BSD-системах. В принципе, можно считать, что и на
большинстве Windows-систем, где будет собираться свободное ПО, эти
языки тоже есть. Причем работают они одинаково by design на всех
платформах. Для того, чтобы написать на них что-то непортабельное -
надо постараться.

"POSIX shell" фактически нет нигде. С некоторой натяжкой можно
считать, что bash есть везде, но:

1. К POSIX shell он имеет довольно приблизительное отношение.
2. Его поведение сильно зависит от сборки в конкретном месте.
3. Авторы его регулярно ломают и это поведение меняют.

Есть dash, он он тоже ужасен и, к тому же, относительно редок (AFAIR,
до сих пор распространение он получил только в Debian - все остальные
ставят сейчас в /bin/sh все равно bash). Есть ash, но он не менее
ужасен и исчезающие редок.

Под красивым словосочетанием "POSIX shell" вы еще, насколько я вижу из
исходников, понимаете sed, awk, grep и еще кучу всяких утилит. Их
BSD-аналоги, скажем, тоже, как ни странно, плохо совместимы с
GNU-реализациями.

Любой, кто пишет на "POSIX shell" приобретает в удобстве и скорости
написания, но здорово теряет в первую очередь в портабельности. Потеря
портабельности для системы сборки - смерти подобна.

"NetBSD make", если понимать это буквально, еще более исчезающе редок.
С GNU make он пересекается плохо. Если будете пытаться генерировать
Makefiles так, чтобы "работало везде" - и на bmake, и на GNU make -
потеряете массу возможностей. Будете поддерживать только bmake -
сильно осложняете использование своего продукта для
Linux-пользователей. Сейчас по факту оно несовместимо не только с GNU
make, но еще и с FreeBSD/OpenBSD make. Одно это, в общем-то, хоронит
напрочь любую идею, сколько бы хорошей она ни была.

Критика любых make-подобных программ всё так же применима к нему
(полагаю, Вы с ней знакомы, но эту точку зрения не разделяете).

Я сейчас как раз нахожусь на перепутии проектировании некоей
достаточно сложной configure-подобной системы для своего проекта и
анализирую массу информации на эту тему, но к mk-configure, к
сожалению, пока я серьезно рассматривать не могу.

Даже если закрыть глаза на bmake, который предлагается заставлять
ставить всех пользователей, то фатальные, с моей точки зрения,
недостатки существующей системы такие:

* Подмена понятий при разделении хотя бы на 2 шага: интерактивный
(configure, пользователь долго взаимодействует с опциями и подбирает
нужную ему комбинацию) и неинтерактивный (make, пользователь пошел
пить кофе). То, что вы называете "configure" на практике просто
занимается проверками и кое-что строит на лету, а реальная
конфигурация на самом деле передается вместе с запуском bmake.

* Отсутствие возможности (насколько я могу судить - принципиальное)
даже в каком-то далеком будущем организовать пользователю красивый
TUI/GUI для сборки. В cmake и scons оно есть. В waf оно планируется в
виде внешнего конфигуратора.

* Достаточно медленная работа, отсутствие адекватного кэширования
результатов configure. В некотором смысле - это следствие используемых
инструментов - в том числе см. выше про критику всех make.

* Отсутствие хоть сколько-нибудь минимального набора модулей, умеющих
поддерживать распространенные языки, библиотеки и пакеты - насколько я
могу видеть, даже C/С++-программы сейчас собирать проблематично (ни
pkg-config, ни Qt/KDE, ни boost сходу не подключишь).

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

* Отсутствие (насколько я вижу по Вашим ответам - принципиальное)
каких-то средств интеграции в deployment, continuous integration и
unit testing.

* Модель эмбеддинга системы сборки в продукт. Учитывая выбранные
средства программирования - в пределе это дает на порядок более
bloated, чем autotools решение. Извините, но оно уже сейчас занимает
35 килобайт - и при этом не умеет делать практически ничего. Для
сравнения - waf занимает 80 и умеет очень много всего.

-- 
WBR, Mikhail Yakshin