@anchor{History}
Вы спросите, зачем вообще Autoconf был написан? Как он оказался там, где он сейчас есть? Почему он выглядит подобно плевку гориллы? Если вы не интересуетесь такими вопросами, то в этой главе ничего полезного для вас нет, и вы можете спокойно пропустить ее. Но если вам действительно интересно, то я пролью немного света....
В июне 1991 года я сопровождал много утилит GNU для Free Software
Foundation. По мере того, как они переносились на все большее количество
платформ, количество ключей `-D', которое пользователю надо было
выбрать в `Makefile' (около 20), становилось обременительным.
Особенно для меня--- я тестировал каждую новую версию на различных
платформах. Так что я написал для пакета fileutils небольшой скрипт на
языке командного процессора для определения некоторых правильных
настроек, и я выпустил его как часть пакета fileutils 2.0. Этот скрипт
configure работал достаточно хорошо, так что в следующем месяце я
вручную адаптировал его для создания подобных скриптов configure
для нескольких других пакетов утилит GNU. Brian Berliner также
адаптировал один из моих скриптов к своей системе контроля версий CVS.
Позже, тем же летом, я узнал, что Richard Stallman и Richard Pixley
разработали аналогичные скрипты для использования в наборе утилит
компиляции GNU; так что я адаптировал мои скрипты configure для
поддержки развивающегося интерфейса их скриптов: использование файлов
`Makefile.in' как шаблонов; добавление `+srcdir', первого
ключа (из многих); и создание файлов `config.status'.
По мере получения ответов от пользователей я добавил много улучшений,
используя Emacs для поиска и замены, вырезания и вставки, одних и тех же
изменений в каждом из скриптов. По мере того, как все большее количество
утилит GNU были адаптированы для использования скриптов
configure, ручное обновление становилось все более неудобно.
Rich Murphey, сопровождавший
графические утилиты GNU, послал мне письмо, в котором писал, что скрипты
configure работают очень хорошо, и спрашивал, нету ли у меня
утилиты для их генерации, и могу ли я послать ее ему. Нет, я думал, но я
должен был! Так, что я начал работать над тем, как создавать эти
файлы. Так началось путешествие от рабства написанных вручную скриптов
configure к изобилию и легкости Autoconf.
Пакет Cygnus configure, который был разработан примерно в то же
время, управлялся таблицей; он предназначался в основном для работы с
небольшим количеством типов систем и небольшим количеством возможностей,
которые по большей части нельзя было автоматически определить (например,
детали формата объектных файлов).
Автоматическая система настройки, которую Brian Fox разработал
для Bash, использовала аналогичный подход. Для общего пользования, мне
кажется безнадежной попытка сопровождать постоянно обновляемую базу
данных возможностей каждого из вариантов каждой операционной системы.
Легче и надежнее будет проверять большинство свойств на лету---
особенно на гибридных системах, которые люди изменяли локально, или на
которых были установлены заплатки от производителя.
Я рассматривал архитектуру, сходную с используемой в Cygnus
configure, где имеется один скрипт configure, который при
запуске считывает части `configure.in'. Но я не хотел
распространять с каждым пакетом тесты для всех возможностей, так что я пришел к
решению иметь разные скрипты configure, созданные из
`configure.in' с помощью препроцессора. Этот подход также
представлял больший контроль и большую гибкость.
Я также ознакомился с использованием пакета Metaconfig, созданного Larry
Wall, Harlan Stenn и Raphael Manfredi, но я решил не использовать его по
нескольким причинам. Создаваемые с его помощью скрипты Configure
являются интерактивными, что я нашел достаточно неудобным; мне не
понравился способ, каким он проверял некоторые возможности (такие как
наличие библиотечных функций); я не знал, сопровождался ли он тогда все
еще, а скрипты Configure, которые я рассматривал, не
работали на многих современных системах (таких как System V R4 и NeXT);
у него не было достаточной гибкости в реакции на наличие или отсутствие
какой-либо возможности; я нашел его трудным в освоении; он был слишком
большим и сложным для моих нужд (я не осознавал тогда, как сильно
придется развить Autoconf).
Я рассматривал использование языка Perl для создания моих скриптов
configure, но решил, что m4 лучше для выполнения простых
текстовых подстановок: это получается проще, поскольку операция вывода
подразумевается по умолчанию. Плюс к тому, каждый пользователь уже имеет его в своей
системе. (В начале я не полагался на расширения GNU для m4).
Несколько моих друзей в университете штата Maryland создавали надстройки
на m4 для разных программ, включая tvtwm, и я был
заинтересован в изучении нового языка.
Поскольку мои скрипты configure определяли возможности системы
автоматически, без интерактивного взаимодействия с пользователем, я
решил назвать программу, которая создавала эти скрипты именем
Autoconfig. Но с добавлением номера версии, это имя было слишком длинным
для старых систем UNIX, так что я укоротил имя до Autoconf.
Осенью 1991 я собрал группу товарищей, чтобы начать поиски Чаши Грааля
Переносимости (эээ, ну, то есть, чтобы они тестировали альфа-версии).
Они предоставляли мне обратную связь, а я занимался инкапсуляцией
кусочков моих вручную написанных скриптов в макросы m4, добавлял
возможности и улучшал технологию проверок. Среди тестеров особенно
выделялись:
Pinard, кто выдвинул идею сделать `autoconf' скриптом командного
процессора, который запускал бы m4 и проверял бы, чтобы все
макросы были обработаны; Richard Pixley, кто предложил для получения более точных
результатов запускать компилятор вместо поиска заголовочных файлов и
символов по файловой системе; Karl Berry, который использовал Autoconf для
настройки TeX и добавил индекс макросов в документацию; а
также Ian Taylor, который добавил поддержку создания заголовочного файла
C как альтернативу помещения ключей `-D' в `Makefile', так что
он смог использовать Autoconf для пакета UUCP. Люди, тестировавшие
альфа-версии, бодро изменяли свои файлы снова и снова, поскольку имена и
соглашения о вызовах изменялись от версии к версии Autoconf. Они также
предоставили мне множество специфических проверок, отличных идей и
исправленных ошибок.
В июле 1992, после месяцев тестирований альфа-версий, я выпустил
Autoconf 1.0, и преобразовал много утилит GNU для его использования. Я
был очень удивлен положительной реакцией на выпуск пакета. Так много
людей стало использовать его, так что я не смог отслеживать их, включая
людей, работающих над программным обеспечением, которое не является
частью проекта GNU (например, TCL, FSP и Kerberos V5). Autoconf
продолжал быстро развиваться, поскольку множество людей, использующих
configure, писали мне о проблемах, с которыми встретились.
Autoconf превратился в хороший тест реализаций m4. UNIX m4
начали выдавать дампы памяти, из-за длины макросов, определяемых
Autoconf; несколько ошибок было найдено в GNU m4. В
конечном счете мы осознали, что нам необходимо использовать некоторые
возможности, которые имеются только в GNU m4. В частности, версия
4.3BSD m4 имела слишком маленький набор встроенных макросов; версия для
System V немного лучше, но все равно не предоставляла всех нужных нам
возможностей.
Происходила дальнейшая разработка по мере того, как люди Autoconf в
более жесткие условия (и использовали так, как я не ожидал). Karl Berry
добавил проверки для X11. David Zuhn сделал поддержку C++.
Pinard сделал диагностику неправильных аргументов. Jim Blandy
использовал пакет для настройки GNU Emacs, закладывая фундамент для
некоторых последующих улучшений. Roland McGrath, использовавший пакет для
библиотеки GNU C, написал скрипт autoheader для автоматизации
создания шаблонов заголовочных файлов C, а также добавил ключ
`--verbose' к configure. Noah Friedman добавил поддержку
ключа `--macrodir' и переменной среды AC_MACRODIR. (Он также
ввел в употребление термин autoconfiscate, который означает "адаптировать
программное обеспечение для использования Autoconf".) Roland и Noah
улучшили экранирование специальных символов в макросе AC_DEFINE и исправили множество
ошибок, особенно когда я пресытился проблемами с переносимостью
с февраля по июнь 1993.
Постепенно накапливался длинный список важных возможностей, которыми
хотелось бы пользоваться, а несколько лет, в течение которых множество
людей накладывали на Autoconf заплатки, привели к накоплению всякого
хлама, который невозможно было вычистить. В
апреле 1994, в процессе работы на Cygnus Support, я начал полный
пересмотр Autoconf. Я добавил большинство возможностей, которые
отсутствовали в Autoconf, но присутствовали в Cygnus configure -- в
основном адаптируя некоторые части Cygnus configure с помощью
David Zuhn и Ken Raeburn. Эти возможности включают поддержку использования
`config.sub', `config.guess', `--host' и `--target';
создание ссылок на файлы; и запуск скриптов configure в
подкаталогах. Добавление этих возможностей позволило Ken'у преобразовать для использования
Autoconf GNU as, а Rob'у Savoye -- DejaGNU.
Я добавил множество возможностей, о которых просили разные люди. Многие
просили, чтобы скрипты configure могли использовать результаты
проверок при последующих запусках, потому что (особенно при настройке
большого дерева исходных текстов, как, например, делает Cygnus) они были
ужасающе медленны. Mike Haertel предложил добавить специфические для
машин скрипты инициализации. Люди, распространяющие программное
обеспечение, которое будет работать на MS-DOS, просили предоставить
возможность переопределения расширений `.in' в именах файлов, из-за
чего появлялись имена типа `config.h.in', содержащие две точки.
Jim Avera сделал обширное исследование проблем с экранированием кавычек
в макросах AC_DEFINE и AC_SUBST; его
проницательность привела к значительным улучшениям. Richard Stallman
просил, чтобы вывод компилятора посылался в файл `config.log'
вместо `/dev/null', чтобы помочь людям отлаживать скрипты
configure для Emacs.
Я сделал некоторые изменения, потому что был недоволен качеством
программы. Я сделал сообщения о результатах проверок менее
двусмысленными, и сделал так, чтобы эти сообщения всегда выдавались.
Я подправил имена
макросов и подправил несовместимости со стандартами кодирования. Я
добавил некоторые вспомогательные утилиты, которые были разработаны,
чтобы помочь в адаптации пакетов для использования
Autoconf. С помощью
Pinard, я сделал так, чтобы макросы не прерывали другие сообщения других
макросов. (Эта возможность вывела на чистую воду некоторые узкие места в
производительности GNU m4, которые были поспешно исправлены!) Я
реорганизовал документацию, чтобы она вращалась вокруг тех самых
проблем, которые люди и хотели решить. И я начал создавать набор
тестов, поскольку опыт показал, что Autoconf имеет ярко выраженную
тенденцию к регрессу при изменениях.
Опять же, несколько альфа-тестеров дали бесценную информацию, особенно Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn и Mark Eichin.
В конце концов, версия 2.0 была готова. И было много радости по этому поводу. (И у меня опять появилось свободное время. Кажется. Нет, я уверен!)
Go to the first, previous, next, last section, table of contents.