Алексей Махоткин

домашняя страница

Autoconf

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


Почему не используется 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.


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

Comments