14. История Autoconf

Вы спросите, зачем вообще Autoconf был написан? Как он оказался там, где он сейчас есть? Почему он выглядит подобно плевку гориллы? Если вы не интересуетесь такими вопросами, то в этой главе ничего полезного для вас нет, и вы можете спокойно пропустить ее. Но если вам действительно интересно, то я пролью немного света....

14.1 Бытие		Предыстория и выбор названия configure.
14.2 Исход		Мучения с m4 и Perl.
14.3 Левит
14.4 Числа
14.5 Второзаконие

14.1 Бытие

В июне 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'.

14.2 Исход

По мере получения ответов от пользователей я добавил много улучшений, используя 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, и я был заинтересован в изучении нового языка.

14.3 Левит

Поскольку мои скрипты configure определяли возможности системы автоматически, без интерактивного взаимодействия с пользователем, я решил назвать программу, создающую эти скрипты, именем Autoconfig. Но с добавлением номера версии, это имя было слишком длинным для старых систем UNIX, так что я укоротил имя до Autoconf.

Осенью 1991 я собрал группу товарищей, чтобы начать поиски Чаши Грааля Переносимости (ну, то есть, чтобы они тестировали альфа-версии). Они предоставляли мне обратную связь, а я занимался инкапсуляцией кусочков моих вручную написанных скриптов в макросы m4, добавлял возможности и улучшал технологию проверок.

Franc,ois Pinard выдвинул идею сделать `autoconf' скриптом командного процессора, который запускал бы m4 и проверял, чтобы все макросы были обработаны; Richard Pixley предложил для получения более точных результатов запускать компилятор вместо поиска заголовочных файлов и символов по файловой системе; Karl Berry, использовавший Autoconf для настройки TeX, добавил индекс макросов в документацию; также Ian Taylor добавил поддержку создания заголовочного файла C как альтернативу помещения ключей `-D' в `Makefile', так что он смог использовать Autoconf для пакета UUCP. Люди, тестировавшие альфа-версии, бодро изменяли свои файлы снова и снова, поскольку имена и соглашения о вызовах изменялись от версии к версии Autoconf. Они также предоставили мне множество специфических проверок, отличных идей и исправленных ошибок.

14.4 Числа

В июле 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++. Franc,ois 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.

14.5 Второзаконие

Постепенно накапливался длинный список важных возможностей, которыми хотелось бы пользоваться, а несколько лет, в течение которых множество людей накладывали на 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. С помощью Franc,ois Pinard, я сделал так, чтобы макросы не прерывали другие сообщения других макросов. (Эта возможность вывела на чистую воду некоторые узкие места в производительности GNU m4, которые были поспешно исправлены!) Вместе с тем реорганизовал документацию, чтобы она вращалась вокруг тех самых проблем, которые люди и хотели решить. И начал создавать набор тестов, поскольку опыт показал, что Autoconf имеет ярко выраженную тенденцию к регрессу при изменениях.

Опять же, несколько альфа-тестеров дали бесценную информацию, особенно Franc,ois Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn и Mark Eichin.

В конце концов, версия 2.0 была готова. И было много радости по этому поводу. (И у меня опять появилось свободное время. Кажется. Нет, я уверен!)