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

[Aleksey Cheusov <vle@gmx.net>]

 AC>> Как раз наоборот.
 AC>> bmake PREFIX=/usr/pkg MANDIR=/some/where/man
 AC>> по сути своей ничем не отличется от
 AC>> ./configure --prefix=/usr/pkg --mandir=/some/where/man
 AC>> Не вижу необходимости плодить сущности без необходимости.
 AC>> Опции не нужны. На самом деле хватает указания значений переменных
 AC>> make-а.
 AC>> Опции же типа ./configure --lalala-includedir=yyy --lalala-libdir=yyy
 AC>> я считаю, эм... скажем так, весьма сомнительным дизайнерским решением.

> Простой пример -- libgsm у нас и в некоторых других дистрибутивах
> находится в разных includedir. Вопрос -- как решается эта проблема?

Я пока не понял, в чем именно заключается проблема. В том, что каталогов
с инклюдами и библиотеками больше одного? Это не проблема.

   LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' ./configure
   make

Точно также, только короче на одну команду делается в mk-configure

   LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' bmake

Для этого не нужны опции --foo-includedir и --bar-includedir.
Это просто лишний, ничего не добавляющий к функциональности, код (жир).

> autotools позволяют создать configure который автоматически обнаружит эту
> библиотеку.
Проблема в том, что autotool не должен ИСКАТЬ библиотеку с которой
приложение может затребовать. autotools должен ОБНАРУЖИТЬ библиотеку там
и только там, где указал тот, кто приложение собирает.  То есть логика
configure.ac, который работает примерно так "а дайте ка я посмотрю в
каталоге /usr/local/include, может я там найду что-нибудь полезное", в
корне ошибочна и вызывает огромные проблемы при сборке софта на
платформах и хостах, отличных от той, на которой софт разрабатывался.
Именно такую логику я называю "сверхестественным недоинтеллектом".  Это
одна из распространенных ошибок писателей на autotools -- слишком велик
соблазн дернуть за какую-нибудь ручку.
Их слишком много (shell для настройки проекта -- это примерно как
граната у обезьяны в руках).

Во избежание неправильного понимания повторю: configure.ac должен искать
заголовки и библиотеки только в системных каталогах и там, куда
указывают LDFLAGS и CPPFLAGS/CFLAGS. Всё. Заглядывать в
/usr/X11R999/{include,lib}, /usr/local/{include,lib},
/opt/application/{include,lib} -- категорически неправильно.
Собирающий софт человек знает свою платформу и хост гораздо лучше автора
приложения в подавляющем большинстве случаев.

Пример: есть одно старое древнее приложение xsokoban, которое я собирал
для pkgsrc.
http://www.cs.cornell.edu/andru/xsokoban.html
Его чудовищный
configure.ac может наблюдать каждый, скачав тарбол.  Здесь можно видеть,
что мне пришлось с ним сделать (кастрировать, по-другому не назовешь),
чтобы привести его в чувство.
http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/xsokoban/patches/patch-ab?hideattic=0&revision=1.1.1.1&view=markup
Обратить внимание на удаленную секцию про поиски libXpm.

 AC>> bmake USE_EXTERNAL_LIBX=1 USE_LOCALLIBY=1
 AC>> Не вижу никаких принципиальных отличий от опций ./configure.
 AC>> Построение же приложения с или без каких-то библиотек в зависимости от
 AC>> их наличия -- натуральное зло, об этом знает каждый пакетировщик.

> Если делается приложение которое предназначено только для опакечивание --
> это так. Увы, не всегда это правило верно. К примеру Asterisk подавляющее
> большинство пользователей собирают сами, увы. При этом в нем несколько
> десятков модулей, и для некоторых из них нужны сторонние библиотеки. И
> многие из этих модулей большинству пользователей не нужны.
Скажем так. В настоящее время большинство программ поступают к конечному
пользователю в виде уже готового пакета в его родной системе. И среди
программистов и среди админов в последнее время распранен такой подход:
"если программы нет в моей системе, значит это она мне не нужна".
Это говорит о том, расстояние между автором и конечным пользвателем из
года в год увеличивается. Лично я не вижу смысла заботиться о постоянно
уменьшающейся доле пользователей, собирающих софт руками, оправдывая
этой заботой нарушение правильного подхода к настройке и сборке софта,
то есть нарушением нормального дизайна.

 AC>> На мой взгляд этот уровень не нужен, как не нужен сам ./configure.

> Вы пробовали написать приложение, которое бы:
> а) пользовалось большим количеством сторонних библиотек;
Нет. Любой дурак может написать большое приложение. Попробуй написать
маленькое ;-) У меня довольно много проектов в open source, и все они
невелики по объему исходного кода. Много сторонних библиотек я тоже не
использую.

> б) использовало бы некоторые ОС-специфичные функции (к примеру системные
> вызовы);
Да. Например dictd, древняя версия которого есть в репозитории
ALT Linux. Есть и другие.

> в) собиралось бы под хотя бы 2-3 разных ОС;
Естественно. dictd, runawk, paexec...

> г) собиралось бы под несколько аппаратных архитектур (с учетом того что
> некоторые типы данных в C на этих архитектурах имеют разный размер в
> байтах)
Само собой. Примеры те же. Почти все, что мной создано. Я тестирую свой
софт на всех ОС и любом железе, которое мне доступно. В данный момент
это NetBSD, Linux, FreeBSD, Solaris, Darwin.  По железу:
alpha,x86,x86-64. Периодически "проскакивает" другое железо.

Список проектов можно найти на {sourceforge,freshmeat}.net и в
репозитории pkgsrc-wip (там pkgsrc специфичные проекты, например
распределенная, устойчивая к сбоям система пакетной сборки (bulk
builder) для пакетов pkgsrc, примерный аналог вашего hasher-а).

> Я понимаю зачем может быть полезен некоторый уровень абстракции _над_
> autotools. Понимаю что у autotools есть много недостатков. Но не понимаю
> зачем нужна система которая позволяет _меньше_ чем autotools.
Я был бы весьма признателен за список того, чего не хватает в
mk-configure. На данный момент реализованы в полном объеме все
возможности, необходимые в 95% случаев. Напомню, проекту 4 месаца. Менее
критичные вещи я отложил "на потом". Одним словом проект развивается и
не стоит на месте, например, только что сделал я поддержку custom тестов
(a la AC_TRY_COMPILE).

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

-- 
Best regards, Aleksey Cheusov.