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

[Aleksey Cheusov]

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

> Позвольте в этом усомниться.

В своем прошлом письме Вы наглядно продемонстрировпли, что ваше
представление о userspace-ах, отличных от GNU, в некоторой дымке, мягко
говоря. Поэтому кому кому, но точно не Вам судить о степени моей
компетенции в этом вопросе.  К тому же я что-то не припомню имени Михаил
Якшин среди тех, что репортили мне хоть когда-нибудь хоть что-нибудь.  В
общем, оставим очень животрепещую тему моих умений и перейдем к
следующей теме.

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

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

> Обсуждение этого вопроса достаточно объемно и, думаю, выходит за рамки
> тематики системы сборки и обсуждения в этом списке рассылки. Если
> хотите - можно продолжить это обсуждение приватно.
Все проблемы bash, свзанные с POSIX давно описаны авторами здесь
http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html
И среди них ни одной, что мешала бы писать на bash переносимые
скрипты. В основном нарушения касаются интерактивного шела.
К тому же есть волшебные пузырки --enable-strict-posix-default.

> Вашу точку зрения на портабельность POSIX shell, utilities и святую
> веру в то, что там и правда всё хорошо и одинаково работает я понял.
Мою точку зрения Вы не поняли, и понять не могли, потому что не
прочитали написанное. Точка.

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

> Собственно, нежелание поддерживать ничего, кроме POSIX, тоже вряд ли
> приведет к чему-то хорошему. "Конкуренты" уже давно признали
> существование Windows, OS X, Symbian.
MacOS-X - это нормальный UNIX, даже сертифицированный с недавних
пор. Что касается Windows... Меня он действительно не
интересует. Совсем. К тому же я уже сказал, что для винды есть cygwin,
Interix и много чего еще, и кросс-сборка в списке моих приоритетов. Так
что здесь я не вижу проблем.
Хотите собирать под windows и symbian -- собирайте.

> Если вдаваться в функционально-декларативную идею make - то
> конструкции вида foreach вообще противоестественны.
Мухи отдельно, котлеты отдельно. Эта тема уже горяче обсуждалась
С Виктором Вагнером не так давно в фидо.
Мой ответ на точно такой же его вопрос где-то здесь.
http://groups.google.com/group/fido7.ru.unix.prog/browse_thread/thread/58ebfd29006c1afe/8944e979305bd3dc?lnk=gst&q=cheusov+wagner+%22.foreach%22#8944e979305bd3dc
Вопрос Витуса искать по фразе "сливай воду".
Вкратце. Декларативный уровень make-а и циклы .foreach находятся на
разных уровнаях make-а, они абсолютно не пересекаются.

 >> И не надо говорить, что питон уже все знают.

> Субъективно - scons/waf/cmake - проще, чем то, что я вижу в
> mk-configure.
Ок. Михаила Якшина вычеркиваем :-)

> действительно значительно большее количество человек, чем прилично
> знают shell и Makefiles.
Если разработчики под UNIX уже не знают ни make ни shell,
то мне становится страшно.

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

> Боюсь, что это будет опять же оффтопиком в этом постинге, но
> Система состоит из 2 больших частей: "клиент" и "сервер".
> Сборка возможна в 4 вариантах. "Варианты" - это набор из
> десятка-другого типизированных опций и процедуры сборки:
> 1. Configure, собирается клиент, собирается сервер, все вместе в
> каком-то виде пакуется в один бинарный пакет.
По-моему это не список требований к системе сборки, а модель
развертывания чего-то где-то. Слишком много частностей, среди которых я
не уловил ни одной принципиальной проблемы для чего-то, основанного на
bmake, в том числе mk-configure. Или я чего-то не понял за лесом
несущественных мелочей? Комбайнов по развертыванию всяких систем и
созданию LiveCD по-моему как грязи.

> Т.к. опций много и они зависят друг от дружки (например, в зависимости
> от задания системы "B" могут появляться какие-то специфичные для
> выбранной системы опции) желательно наличие какого-то удобного
> конфигуратора - на уровне того, что показывают рядовому пользователю
> при сборке ядра Linux.
Как ГУИ конфигураторы, так и проверка непротиворечивости заданных опций
делаются отдельными модулями. Последнее, например можно сделать
отдельным .mk модулем. Зачем городить всеумеющий саморазваливающийся
комбайн?

> Процесс "configure" вполне может быть итеративный или иметь более, чем
> одну стадию.
Моя религия: командный интефейс отдельно, диалоги с пользовалетем --
отдельно, уровнем выше. Спрашивать "А вы уверены? Точно?" это не задача
системы сборки.

> Опции имеет смысл как можно скорее валидировать - если пользователь,
> сказал, например, "каталог для установки - такой-то", то стоит
> убедиться в том, что он существует и в него можно писать.
Отдельный модуль и make precheck или make validate.
Это вообще не зависит от выбора системы сборки.

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

> Под словами "пакуется в пакет" понимается модульная поддержка упаковки
> в один из возможных пакетов (в зависимости от выбранных систем B и C -
> ALT-specific rpm, RH-specific rpm, SuSE-specific rpm, Debian deb,
> Ubuntu deb и т.п.).
mkc.deb.mk, mkc.altlinux-rpm.mk и тд.

> Предполагается, что каждое из таких действий должно быть оформлено в
> виде некоторого семейства модулей - при сборки выбирается модуль,
> соответствующий системам B или C из данного семейства.
Мелочи.

> Разумеется, хочется, чтобы была система отслеживания зависимостей -
> если пользователь задал конфигурацию #1, сказал "make all", у него
> что-то не собралось или незадеплоилось - он чуть-чуть подправил
> конфигурацию, сделав тем самым конфигурацию #2 - чтобы были
> перевыполнены только нужны этапы сборки. Как можно догадаться, речь
> явно не о file-level dependencies
Нельзя этого видеть. В pkgsrc, например, после успешной стадии
fetch, checksum, extract, patch, configure, build, build, ...
touch-ится соответствующий файл в специальном месте.
У меня есть любимый анекдот на эту тему.

> Хочется, чтобы у всего этого был красивый и вменяемый пользовательский
> интерфейс - чтобы было явно видно, на какой стадии мы находимся
> сейчас, какой у нас прогресс, сколько еще осталось ждать.
Ой.

> На саму систему можно посмотреть в районе http://www.inquisitor.ru/ -
гляну.

> Если интересно дискутировать далее на эту тему - предлагаю опять же, в приват.
"Дискутировать" на тему inquisitor я не в состоянии.  Гляну --
посмотрим. Пока слушаю, но, подозреваю, Вам хочется всеумеющий комбайн,
который разваливается от времени под собственным весом. Такое не может
существовать без капиталовложений десятка транснациональных корпораций
и тысяч человеко-часов. Надеюсь, я ошибаюсь.
Если мы еще хоть косвенно о mk-configure,
то таким путем он точно не пойдет. ВСЕГО он уметь не будет. Никогда.

 >>   bmake PREFIX=/usr/pkg <other options here>
 >>
 >> и СРАЗУ идешь пить кофе.

> И, вернувшись через полчаса, узнаешь, что сборка проработала две
> минуты и упала где-то в начале из-за неправильно указанной опции.
make precheck
спасет раненого кота. Это не проблема системы сборки, это проблема
писателя и запускателя Makefile-ов.

 >> Здесь просто полное несоответствие фактам. В mk-configure кеширование
 >> как раз есть, а нет его как раз в autoconf-е (между проектами).

> Прочитайте, пожалуйста, полностью - "адекватного кэширования". Вы
> как-то странно постоянно сравниваете себя с autotools

Термин "адекватное кэширование" прямо таки требует раскрытия.

> Ну, для справки - именно fork(2) при выполнении configure проекта на
> каком-нибудь scons будет в разы меньше - просто потому, что оно не
> будет вызывать столько всяких внешний программ и столько раз дергать
> шелл.
Это не принципиально. Основные потери не на шеле, и не на форках.

> На глаз - ну посмотрите хотя бы, сколько ./EXAMPLE.configure --help
> выполняется. По-моему - уже на грани фола, и как это ускорить, не
> меняя парадигмы - я не представляю.
EXAMPLE.configure -- это фейк, его нет, там пусто. Он ничего не делает
вообще. Это пример нереализованного будушего.

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

> Все, что можно передать в сборку из configure, запихивается в
> environment и command line. Он относительно маленький и пользоваться
> неирархическими плоскими путями типа

> MODULE1_SUBMODULE2_SUBSUBMODULE3_SOMETHING_MORE_HERE_OPTION=2

> при наличии нескольких сотен опций неудобно.
Я их не вижу. Поэтому все удобно.
Если хочется config файл, я уже показывал, как его сделать.
bmake -f huge_amount_of_setting_here.mk -f Makefile

или, например, .sinclude "local_setting.mk" внутри Makefile.

> Кроме того, и command
> line, и environment не резиновые.
command line хватит на тысячи опций.  Несчастные пользователи
поломанного Irix shell, у которого лимит что-то вроде 20Kb, поставят
себе нормальный shell и тоже будут счастливы.  environment? Никогда не
видел, чтобы его не хватило.  Кроме того, см. выше про -f -f.

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

> Вообще-то самое непосредственное. Тоже система, тоже сборки, только
> работающая не здесь и сейчас по толчку пользователя, а висящая неким
> демоном и реагирующая на внешние воздействия. Большинство джавных
> систем сборки это обеспечивают.
wikipedia описывает термин слишком общё. Он включает МАССУ разных вещей.
Зачем нужен демон мне совершенно не очевидно.

 >>  Авторы приложений и библиотек сами
 >> могут себе написать подходящую для них систему.  Есть образцы для
 >> подражания?

> Речь не о том, чтобы на пустом месте придумать что-то суперновое и
> супергениальное. Есть масса сложившихся подходов к тестированию -
> людьми написаны миллионы тестов под JUnit, CUnit, RUnit, Test::More и
> т.п. Есть "стандарт" TAP (Test Anything Protocol). Идея в том, чтобы
> обеспечить легкий запуск тестов всех этих форматов и хоть какую-то их
> интеграцию в сборочную среду.
.include "mkc.JUnit.mk"
bmake test

> То же самое по сути относится к инструментам code coverage и генерации
> документации.
mkc.man.mk и
mkc.info.mk уже есть много-много лет.
Они умеют делать много разного.
Есть мега проект mk-latex.
Все остальное -- аналогично.

> Современные сборочные фреймворки дают пользователю
> возможность сделать "что-нибудь test", "что-нибудь coverage" или
> "что-нибудь doc" и получить вменяемые результаты без написания единой
> строчки кода, кроме, собственно, самих тестов и документации.
Одна строчка нужна всегда "хочу подлючить такой-то модуль".
И ровно одна требуется при подходе mk-configure.

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

> Тогда, вероятно, я не так понял роль shell-скрипта "configure". Он не
> распространяется с продуктом?
Во-первых, shell скрипт configure -- это для тех, кого бесит bmake.
Во-вторых это не реализовано, это только мысли вслух. В-третьих, это
замена только для autoconf, но никак не для automake. В-четвертых -- это
не "эмбеддинг", это "файл конфигурации". Сама же библиотека
mkc_configure (source mkc_configure) -- ставится вместе с mk-configure.

-- 
Best regards, Aleksey Cheusov.