Go to the first, previous, next, last section, table of contents.

Вопросы об Autoconf

@anchor{Questions}

Раз за разом задаются одни и те же вопросы об Autoconf. Вот некоторые из них.

Распространение скриптов `configure`

@anchor{Distributing}

Какие ограничения существуют на распространение скриптов configure,
созданных Autoconf?  Как могут затронуть они мою программу, которая
использует эти скрипты?

На использование или распространение скриптов настройки, созданных Autoconf, не накладывается никаких ограничений. В Autoconf версии 1, они подпадали под действие GNU General Public License. Мы все еще поощряем авторов к распространению их работ под действием лицензий, сходных с GPL, но это не обязательно при использовании Autoconf.

По поводу других файлов, которые могут быть использованы с configure: `config.h.in' находятся под теми авторскими правами, которые используются для вашего `configure.in', поскольку эти файлы являются производными этого файла и свободно доступного файла `acconfig.h'. `config.sub' и `config.guess' не подпадают под GPL в том случае, когда они используются со скриптами configure, созданными с помощью Autoconf: в этом случае вы можете распространять их под той же лицензией, что и остальной пакет. `install-sh' получен от X Consortium и не защищен авторскими правами.

Почему требуется GNU `m4`?

@anchor{Why GNU m4}

Почему Autoconf требует наличия GNU m4?

Многие из реализаций m4 имеют зашитые в программу ограничения на размер и количество макросов, которые Autoconf не может преодолеть. В них также отсутствуют некоторые встроенные макросы, без которых было бы трудно создать такое сложное приложение, как Autoconf, включая:

builtin
indir
patsubst
__file__
__line__

Поскольку Autoconf нужен только людям, сопровождающим программное обеспечение, и поскольку GNU m4 прост в настройке и установке, то кажется вполне естественным, что также требуется установить GNU m4. Многие люди, сопровождающие программное обеспечение GNU и другое свободное ПО, уже установили у себя большинство утилит GNU, потому что предпочитают именно их.

Как я могу начать работу?

@anchor{Bootstrapping}

Если Autoconf требует GNU m4, а GNU m4 имеет скрипт
Autoconf configure, то как я могу начать работу? Это похоже на
проблему яйца и курицы!

Вы неправильно поняли. Хотя GNU m4и поставляется со скриптом configure, созданным Autoconf, сам Autoconf не требуется для запуска скрипта и установки GNU m4. Autoconf требуется только если вы хотите изменить скрипт configure для m4, а это требуется немногим (в основном тем, кто сопровождает данный пакет).

Почему не используется Imake?

@anchor{Why Not Imake}

Почему не используется Imake вместо скриптов configure?

Разные люди писали ответы на этот вопрос, так что я приведу здесь переделанный вариант их объяснений.

Следующий ответ основан на материале, написанном Richard Pixley:

Скрипты, созданные Autoconf, часто работают на машинах, для которых они не были предназначены. То есть они хорошо работают, когда нужно создать конфигурацию для совершенно новой системы. Imake такого не умеет.

Imake использует общую базу данных, специфических для конкретных систем. Для X11 этого достаточно, потому что этот пакет делается одной организацией, которая имеет централизованный контроль над этой базой данных.

Утилиты GNU выпускаются не так. Каждую утилиту GNU сопровождает отдельный человек, и эти люди разбросаны по всему миру. Использование общей базы данных будет просто кошмаром при сопровождении пакета. Autoconf может показаться неким подобием базы данных, но на самом деле это не так. Вместо перечисления зависимостей от машины, он перечисляет требования программ.

Если вы рассматриваете набор GNU как набор отдельных утилит, то возникают сходные проблемы. Но утилиты разработки GNU могут быть настроены как кросс-утилиты в почти любом сочетании машина+цель. Все эти конфигурации могут быть установлены одновременно. Она даже могут делить между собой не зависящие от машины файлы. Imake не позволяет сделать этого.

Шаблоны Imake являются формой стандартизации. Стандарты кодирования GNU позволяют сделать это без ненужного наложения тех же самых ограничений.

Вот дополнительные объяснения, написанные Per Bothner:

Одним из преимуществ Imake является то, что он легко создает большие файлы Makefile, используя директивы препроцессора cpp `#include' и механизм макросов. Однако на cpp невозможно программировать: у него ограниченные возможности условных операторов и нет операторов циклов. Помимо того, cpp не имеет доступа к переменным среды.

Все эти проблемы решаются использованием командного процессора sh вместо cpp. Командный процессор предоставляет полные возможности программирования, имеет подстановку макросов, может выполнять или создавать другие скрипты командного процессора и может пользоваться переменными среды.

Paul Eggert развил эту тему дальше:

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

Также Imake часто страдает от неожиданного взаимодействия между make и препроцессором C. Фундаментальной проблемой является то, что препроцессор C был создан для обработки программ на языке C, а не файлов `Makefile'. Это является менее значимой проблемой при использовании Autoconf, который использует препроцессор общего назначения m4, а автор пакета (а не установщик пакета) выполняет обработку стандартным способом.

В заключение, Mark Eichin замечает:

Imake, в конце концов, не такой уж и расширяемый. Для того, чтобы добавить к Imake новую возможность, вам необходимо создать собственный шаблон для проекта и сдублировать большинство возможностей существующего шаблона. Это означает, что для сложного проекта использование поставляемых производителем шаблонов Imake приведет к сбою --- поскольку они не предоставляют возможностей, в которых нуждается ваш проект (если только он не является программой для X11).

Однако с другой стороны:

Одно из преимуществ Imake по сравнению с configure: файлы `Imakefile' оказываются значительно меньше (более того, они менее многословны), чем файлы `Makefile.in'. Однако существуют решения этой проблемы--- по крайней мере для исходных текстов Kerberos V5, мы изменили файлы для вызова общих частей: фрагментов `Makefile' для всего дерева каталогов, которые находятся в файлах `post.in' и `pre.in'. Это означает, что часть общей функциональности не дублируется, даже хотя они будут находиться в скриптах configure.