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 ----------------------------------------------------------------------------