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

["Денис Смирнов" <mithraen@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 6069 bytes --]

On Sun, Jul 12, 2009 at 11:02:22PM +0300, Aleksey Cheusov wrote:

AC> Я пока не понял, в чем именно заключается проблема. В том, что каталогов
AC> с инклюдами и библиотеками больше одного? Это не проблема.
AC>    LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' ./configure
AC>    make

Правильно написаный configure на autotols сделает это за меня.

И я, кстати, почти никогда не переопределяю переменные окружения для
./configure.

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

Он _очевиден_. Глядя на эти опции autotools я понимаю что таким образом
добавлена эта библиотека.

Кстати рекомендую посмотреть на spec чего-нибудь вроде mplayer, где
используетяс много with/without. Или на тот же asterisk.

AC> Проблема в том, что autotool не должен ИСКАТЬ библиотеку с которой
AC> приложение может затребовать. autotools должен ОБНАРУЖИТЬ библиотеку там
AC> и только там, где указал тот, кто приложение собирает.  

В случае если собирает пользователь на произвольной системе, а не
мантейнер дистрибутива -- эти слова неправда. Фича autotools как раз в том
что пользователь не должен знать где у него библиотеки.

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

Да, я согласен, не многие умеют писать нормальые configure-скрипты.

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

Эта самая уменьшающаяся доля пользователей -- является как раз
квалифицироваными пользователями, разработчиками, будущими мантейнерами.

То есть те о ком вы не собираетесь заботиться, для меня лично является
иденственной аудитории, которой я готов многим помочь не выставив
предварительно счет.

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

Таким образом, естественно, что вы не учли при разработке своего решения
интересов тем, кому приходится писать большие системы :)

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

Как выглядит сборка под разные ОС?
В случае autotools она выглядит так:
./configure
make
make install

AC> Само собой. Примеры те же. Почти все, что мной создано. Я тестирую свой
AC> софт на всех ОС и любом железе, которое мне доступно. В данный момент
AC> это NetBSD, Linux, FreeBSD, Solaris, Darwin.  По железу:
AC> alpha,x86,x86-64. Периодически "проскакивает" другое железо.
AC> Список проектов можно найти на {sourceforge,freshmeat}.net и в
AC> репозитории pkgsrc-wip (там pkgsrc специфичные проекты, например
AC> распределенная, устойчивая к сбоям система пакетной сборки (bulk
AC> builder) для пакетов pkgsrc, примерный аналог вашего hasher-а).
AC> Я был бы весьма признателен за список того, чего не хватает в
AC> mk-configure. На данный момент реализованы в полном объеме все
AC> возможности, необходимые в 95% случаев. Напомню, проекту 4 месаца. Менее
AC> критичные вещи я отложил "на потом". Одним словом проект развивается и
AC> не стоит на месте, например, только что сделал я поддержку custom тестов
AC> (a la AC_TRY_COMPILE).
AC> Но начинается любой проект с концепции...  Зачем я сюда и
AC> пришел. Выслушать "фи" насчет идеологии и, приняв к сведению, учесть при
AC> разработке.

Я как раз к концепции и придираюсь :) Честно скажу, несколько лет назад я
пользовался slackware и считал autotools жутким непонятным монстром
который мне мешал ковыряться в коде. И приложения где были простые
самодельные makefile мне нравились.

Сейчас, когда я много времени трачу на сборку, у меня к любой системе
сборки всегда один вопрос -- чем она _принципиально_ лучше autotools? Если
нет ни одной killer feature -- то ее использование кем-либо буду для себя
считать неудобным. Потому что мне как мантейнеру, пришлось с autotools
сколь-нибудь разобраться. Другая система -- требует отдельного вкуривание
в него, и не всегда понятно с какими перспективами.

Система созданная вами облегчает жизнь разработчику (ее применение требует
меньше эзотерических знаний чем autotools), однако слегка _осложняет_
жизнь мантейнеру (повторюсь - большинство пакетов собирается тремя
командами) и пользователю. А также не очень-то пригодна для больших
проектов.

Ради интереса -- ознкомьтесь с системой сборки в Asterisk, там
действительно все непросто, и даже над autotools еще написали отдеьлную
обвязку для управления зависимостями. Думаю это поставит перед вами ряд
вопросов которые вам будет интересно решить :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]