From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_SORBS_WEB, SPF_PASS, URIBL_SBL autolearn=no version=3.2.5 X-Authenticated: #3271302 X-Provags-ID: V01U2FsdGVkX18F08ICMmQFL62WZJf9ICJAm5A4UiApTSYKuUFcnA ZEhdU75jq1OuTm To: ALT Linux Sisyphus discussions References: <4A59D212.8040809@altlinux.ru> <4A59F895.10003@altlinux.ru> <20090712185734.GA19410@mw.office.seiros.ru> From: Aleksey Cheusov Date: Sun, 12 Jul 2009 23:02:22 +0300 In-Reply-To: <20090712185734.GA19410@mw.office.seiros.ru> =?koi8-r?B?KCLk?= =?koi8-r?B?xc7J0yDzzcnSzs/XIidz?= message of "Sun, 12 Jul 2009 22:57:34 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Subject: Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 20:05:12 -0000 Archived-At: List-Archive: List-Post: 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.