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

[Aleksey Cheusov]

Ух ты! А я, признаться, уже и не ожидал увидеть здесь хоть какой-то
конструктив...

> Perl/Python/Ruby с некоторой натяжкой есть на практических всех
> современных Linux/BSD-системах.
Мысль понял. Почему я не использую ЯП, вместо комбинации POSIX shell +
unix tools? Ответ простой. Потому что средство подбирается не по
принципу "крутости", современности или распространенности, а исходя из
задачи.  Система сборки -- задача простая, и для ее реализации я выбрал
подходящие на мой взгляд и простые средства.  Ни питон, ни руби, ни перл
там не нужны. Тем более, что все они довольно громоздкие.

> "POSIX shell" фактически нет нигде. С некоторой натяжкой можно
> считать, что bash есть везде, но:
У меня достаточно большой опыт написания портабельных скриптов на шеле,
авке и прочих под разные оси.

> 1. К POSIX shell он имеет довольно приблизительное отношение.
shell как шел, только очень медленный по сравнению с некоторыми другими.
Где список претензий к bash по части POSIX?

> 2. Его поведение сильно зависит от сборки в конкретном месте.
Я не пользуюсь GNU-ыми расширениями.

> 3. Авторы его регулярно ломают и это поведение меняют.
В части POSIX? Где?

> Есть dash, он он тоже ужасен и, к тому же, относительно редок (AFAIR,
> до сих пор распространение он получил только в Debian - все остальные
> ставят сейчас в /bin/sh все равно bash).
dash - неплохой шел в качестве системного. Почти идеальный выбор, если
бы не дебильный встроенный echo, из-за которого ломается libtool.
Даже не знаю, в какой момент и зачем они его так сломали ash.
Заставить всех не пользоваться echo абсолютно невозможно.

> Есть ash, но он не менее ужасен и исчезающие редок.
/bin/sh в NetBSD и FreeBSD -- наследники ash. Равно как и dash.  Так что
никуда он не исчезающий.

> Под красивым словосочетанием "POSIX shell" вы еще, насколько я вижу из
> исходников, понимаете sed, awk, grep и еще кучу всяких утилит.
Нет. Я, слава богу, вижу разницу между шелом, авком и прочими утилитами.
Я надеюсь в этом нет сомнений?

> Их BSD-аналоги, скажем, тоже, как ни странно, плохо совместимы с
> GNU-реализациями.
Я не сажался на иглу GNU и BSD расширений. В программах, которые
создаются, чтобы быть портабельными, расширения не использую.  О том,
где что и какое, я, опять же, в курсе. Много моих PR по поводу
NetBSD-ного userspace-а можно найти у них в BTS. Там и shell и xargs и
прочее. Сколько патчей я слал или просто репортил на nawk имени bwk я
уже просто не помню -- кучу. К сожалению Брайн Керниган, по-моему, их
проигнорил с объяснением "у меня так работает 30 лет, поэтому ничего
менять не буду". По крайней мере ответа на вопрос "а как же посикс..." я
от него так и не дождался. В NetBSD же все приняли, приложили и починили
(ну, почти все, есть еще парочка проблем). Арноль Роббинс последний раз
исправлял багу от меня в gawk примерно месяц назад, может два. В dash
тоже есть мой патч, правда касался сборки. По секрету могу расказать о
проблеме в /usr/xpg4/bin/awk. Никуда не репортил, потому что не знаю
куда, и не уверен, имеет ли смысл репортить что-то для десятки. Про
соляроидный /bin/sh и /usr/bin/awk я ничего не скажу, потому без матюков
не смогу. С моей подачи недавно пофиксили одну багу во FreeBSD-ом
/bin/sh, любопытные сами найдут. Короче, народ, давайте жить дружно. Я
знаю, что можно и чего нельзя сделать на шеле и юниксовых приблудах. И
где заложены грабли я тоже знаю. Не все, конечно, но очень многие.

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

> Потеря портабельности для системы сборки - смерти подобна.
Именно поэтому все пишется на POSIX shell и POSIX unix tools.  Напомню,
я не выпускаю версии, пока не проверю на всех имеющихся у меня
системах. У всех моих проектов есть довольно немаленькое количество
тестов.

> "NetBSD make", если понимать это буквально, еще более исчезающе редок.
Этот аргумент я принимаю, но только как маркетоидный, но не как
технический.

NetBSD make нужно именно буквально понимать. bmake -- это портированный
на другие платформы NetBSD make. Об-autotools-еный.  Регулярно синкается
с репозиторием NetBSD. Где он не работает я просто не знаю.  Наверное,
только на нативной винде. Не в курсе.

> С GNU make он пересекается плохо.
Только в той части, которая POSIX make, на котором ничего сделать
нельзя. Не зря примерно треть любителей autoconf сползают на GNU make.
Незаметно для себя... В остальном GNU make и NetBSD абсолютно разные.

Почему я не использую GNU make? Этот вопрос надо добавить в FAQ:
- потому что для GNU make я не нашел аналога mk-files
  (возможно, плохо искал)
- потому что меня воротит от уродливой комбинации foreach/eval/call вместо
  простого и элегантного bsdmake-овского .for/.endfor, который, кстати,
  повсеместно используется в mk-configure.
- потому что bmake проще и понятнее, чем GNU make.

Спасибо за идею насчет FAQ-а. Я таки его заведу.

В остальном же GNU make и NetBSD make по возможностям примерно
сопоставимы.  Теоретически систему аналогичную mk-configure можно
написать и на GNU make, я видел по крайней мере одну попытку -- MOBS (a
la automake).  Жаль, померла. Если найдется желающий, с радостью приму
такую реализацию. Пока же занимаюсь поддержкой только NetBSD make, на
большее сил нет.

> Если будете пытаться генерировать Makefiles так, чтобы "работало
> везде" - и на bmake, и на GNU make - потеряете массу
> возможностей.
Даже при поверхностном прочтении тех ссылок, что я давал, станет
очевидно, что кодогенерация -- это как раз то, от чего я отказался.
Там прямо так и написано.

> Будете поддерживать только bmake - сильно осложняете
> использование своего продукта для Linux-пользователей.
Тут согласен. Но не так уж "сильно" и только на первых порах.  Думаю, не
секрет, что пишущие на autoconf как правило очень плохо знают m4. Ну и
пакетирование, к примеру, пакетов для pkgsrc тоже не требует глубинных
знаний bmake-а, хотя все Makefile-ы пакетов написаны на нем. Есть
несколько шаблонных конструкций, которые легко выучить и оперивать ими
буквально годами, не вникая в детали bmake. Кроме того (повторюсь) bmake
проще GNU make-а, поэтому изучить его значительно легче. Т.о. проблема
обучения имеет место, но не очень серьёзная. Сравнивать же
bmake/mk-configure с scons/waf (python!)  по сложности обучения я просто
не буду. Это вообще не серьезно. И не надо говорить, что питон
уже все знают.

> Сейчас по факту оно несовместимо не только с GNU make
С какой стати все должны быть совместимы с каким-то там GNU make? ;-)

>, но еще и с FreeBSD/OpenBSD make.
Эти make-и в одних местах поломаны. В других сильно недоразвиты по
сравнению с bmake. В третьих -- несовместимы, я не в курсе, кто "первый
начал", но есть такой печальный факт.

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

> Критика любых make-подобных программ всё так же применима к нему
> (полагаю, Вы с ней знакомы, но эту точку зрения не разделяете).
С чем-то согласен, с чем-то нет. К критике make-ов я отношусь спокойно,
без истерик. Альтернативы типа scons игнорирую, виду их чрезмерной
массивности. python для реализации альтернативных make-ов -- выбор
неудачный. Уж больно он толтый. Естественно, это тоже субъективно.

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

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

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

Запускаешь, к примеру

   bmake PREFIX=/usr/pkg <other options here>

и СРАЗУ идешь пить кофе.
Но можно сделать и фейковый таргет configure. Еще одно спасибо,
включу в TODO. Для тех, у кого ностальгия. В общем, подумаю.

> * Отсутствие возможности (насколько я могу судить - принципиальное)
> даже в каком-то далеком будущем организовать пользователю красивый
> TUI/GUI для сборки. В cmake и scons оно есть. В waf оно планируется в
> виде внешнего конфигуратора.
А зачем ГУИ для сборки??? Мы же в юниксе. Может его еще и во все цвета
радуги раскрасить? :-) Это делается внешними алиасами. У меня, почти все
команды цветные, включая make. colorit(1). Цветной make мне даром не
нужен. ГУИ тем более. Над строго форматированным текстовым выводом
подумаю. И за это спасибо, включу в todo "на подумать".

> * Достаточно медленная работа, отсутствие адекватного кэширования
> результатов configure. В некотором смысле - это следствие используемых
> инструментов - в том числе см. выше про критику всех make.
Здесь просто полное несоответствие фактам. В mk-configure кеширование
как раз есть, а нет его как раз в autoconf-е (между проектами).
Медленно работает? Глупости. Все работает быстро. Настолько быстро,
насколько это вообще возможно. Количество fork(2)-ов можно даже
посчитать.

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

> * Крайне плохо масштабируемая модель синтаксиса входных файлов.
Здесь не понял. Можно развернуть?

>  Нет и я не очень представляю как в представленной парадигме
> реализовать подпроекты,
Подпроекты есть. См. mkc.subdir.mk Довольно примитивно, но для маленьких
и средних проектов достаточно. Для ОЧЕНЬ больших я собирался сделать
что-то, очнованное на графах. Опять же, легко все это пишется.
Идея родилась в результате очередного флейма.

> группы, иерархию опций, зависимости между ними
> и т.п.
Что имеется ввиду под группами и иерархией опций?

> * Отсутствие (насколько я вижу по Вашим ответам - принципиальное)
> каких-то средств интеграции в deployment,
Можно конкретнее? Чего конкретно хочется?

> continuous integration и
Я тоже знаю много страшных слов. Но CI не имеет никакого отношения к
системе сборки, насколькоя его понимаю.

> unit testing.
unit testing добавить как раз не проблема. Пишется отдельный модуль
mkc.test.mk, включай и используй. bmake test и оно поехало.  Записал в
todo "на подумать", низкий поклон.  Хотя, конечно, unit тестирование --
это явно не задача mk-configure.  Авторы приложений и библиотек сами
могут себе написать подходящую для них систему.  Есть образцы для
подражания?

> * Модель эмбеддинга системы сборки в продукт.
В mk-configure эмбендинга как раз нет. mk-configure должен быть
поставлен на систему ПЕРЕД сборкой. Об этом явно говорится в README.

> Учитывая выбранные средства программирования - в пределе это дает на
> порядок более bloated, чем autotools решение.
Как следствие предыдущего пункта -- нет.
Таким жирным, как autobloat mk-configure не будет никогда.
Именно в силу заложенных в него принципов.

> Извините, но оно уже сейчас занимает 35 килобайт - и при этом не умеет
> делать практически ничего. Для сравнения - waf занимает 80 и умеет
> очень много всего.
Я посмотрю на забытый всеми waf и сравню, что он может и чего нет.

-- 
Best regards, Aleksey Cheusov.