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

[Aleksey Cheusov <vle@gmx.net>]

 >> Речь идет об одной из моих последних open source разработок,
 >> mk-configure, легковесной простой использовании (да, я знаю, звучит как
 >> маркетоидное заклинание :-) , уж простите ) альтернативе GNU
 >> autotools. Ни много, ни мало...

> Есть ещё одно соображение, не прозвучавшее за прошедшие 2 дня обсуждения.

> Не секрет, что многие мантейнеры пакетов нередко используют заклинание
> "autoreconf -fisv" для того, чтобы заменить поставляемые в исходниках
> сгенерированные файлы на более адекватные.
Да, что, кстати, ломает изначальную идеологию autotools -- предоставить
тарбол, достаточный для сборки абсолютно везде.  Оказывается,
недостаточный, необходимо, оказывается, еще и autotools ставить. Новое
поколение разработчиков считает даже, что за предоставленный в тарболе
готовый configure нужно бить по рукам. Когда я об этом услышал, я был
просто в шоке :-)

Во-первых, это делает подход с кодогенерацией абсолютно неуместным.
Преврати autotools в библиотеку на шеле и пиши декларативно на шеле,
безо всяких m4 и кодогенерации.

Во-вторых, получается такая же ситуация, как и с mk-configure.  Для
mk-configure-based проектов нужно поставить кучу всего, и для
autotools-based -- тоже.

> Основная идея проекта, отличающая его от GNU autotools -- в замене
> сгенерированных (предвычисленных "на все случаи жизни")
> configure+Makefile.in на декларативные правила, которые будет
> вычислять каждый пользователь во время сборки
Угу.

> -- в первую очередь должна понравиться разработчикам операционной
> системы.
Вот, кстати пример. Что делают разработчики BSD систем, когда помещают
сторонний софт, собранный явно не средствами соответствующих bsdmake-ов,
в свои деревья? Правильно. Выбрасывают родные системы сборки к черту и
пишут свои, коротенькие маленькие на родном bsdmake-е. Тот же подход
может быть успешно применим и при разработке больших и долгоиграющих
узкоспециализированных программных комплексов. Заодно решается проблема
кросс-сборки, актуальная для эмбеда.

Вот пример, как GNU grep встроен в NetBSD
http://cvsweb.netbsd.org/bsdweb.cgi/src/gnu/usr.bin/grep/Makefile?only_with_tag=MAIN

> В то же время есть две гораздо более многочисленные группы пользователей,
> которым подход mk-configure менее предпочтителен:
> - Обычные пользователи, собирающие софт из исходников без изменений.  Как
>   уже было сказано, необходимые для сборки проектов, использующих
>   mk-configure, новые инструментальные средства _нужных_версий_ -- это
>   сейчас проблема.
На мне лежит забота об обратной совместимости.  Так что "нужных версий"
можно опустить.  Я бы поставил ударение на "новые инструментальные
средства" и "малораспространенные". Принимаю помощь в пакетировании для
Debian, FreeBSD, Fedora, OpenSuse, Gentoo, Slackware и проч. :-)

> - Разработчики софта, рассчитывающие, что их проект будет работать на
>   любой платформе, которую может поддерживать autotools.  Очевидно, что
>   mk-configure как минимум на первых порах сможет поддерживать только
>   самые "живые" платформы.
Да.

> Весьма вероятно, что инертность этих двух групп потушит любое начинание
> в этой области, вне зависимости от деталей реализации.
Без активной помощи со стороны -- да.

-- 
Best regards, Aleksey Cheusov.