Imake хорошо подходит для разрешения трудностей переносимости и конфигурации, специфических для X, и используется во всех проектах, которые являются частью дистрибутива X Window. Однако за пределами X-сообщества данная утилита не приобрела большой популярности. Она трудна для изучения, использования и расширения, а кроме того, генерирует make-файлы огромных размеров и сложности.

Imake– инструменты доступны на любой Unix-системе, поддерживающей X, включая Linux. Существует один "героический" проект [16], цель которого заключается в "прояснении тайн" Imake для не X-программистов. Вопросы, освещаемые данным проектом, стоит изучить всем, кто собирается заниматься X-программированием.

Утилита autoconf была написана программистами, которые изучили и отклонили подход Imake. Утилита autoconf генерирует для каждого проекта shell-сценарии

, которые подобны старомодным специальным конфигураторам, – сценарии способны генерировать make-файлы (в том числе).

Утилита autoconf направлена на разрешение проблемы переносимости и вообще не выполняет встроенного вывода зависимостей. Несмотря на то, что данная программа, вероятно, такая же сложная, как Imake, она является гораздо более гибкой и проще расширяется. Вместо использования базы данных правил в системе, утилита генерирует shell-код configure, который осматривает систему, определяя необходимые параметры.

Каждый

– сценарий создается на основе уникального для проекта шаблона , который должен написать разработчик. Однажды сгенерированный сценарий является самодостаточным и способен конфигурировать данный проект на системах, которые не содержат саму утилиту autoconf(1).

Подход к созданию make-файлов, принятый для autoconf, подобен подходу Imake в том, что разработчик начинает с написания шаблона make-файла для своего проекта. Однако файлы

, созданные autoconf, по существу являются просто make-файлами с метками-заполнителями для простой текстовой замены; не существует второй формы записи, которую требуется изучать. Если требуется осуществить вывод зависимостей, то необходимо предпринять явные шаги для вызова makedepend(1) или подобного инструмента, или использовать утилиту automake(1).

Утилита autoconf документирована в руководстве в GNU info– формате. Исходные сценарии autoconf доступны на сайте архива FSF, а кроме того, они предустановлены на многих Unix и Linux-системах. Упомянутое руководство можно просматривать с помощью справочной системы Emacs.

Несмотря на отсутствие непосредственной поддержки вывода зависимостей и характерного для autoconf узкоспециального подхода, в середине 2003 года данная утилита, несомненно, была наиболее популярной из всех генераторов make-файлов. Она превзошла Imake и стала причиной выхода из употребления, по крайней мере, одного главного конкурента (metaconfig).

Существует справочник "GNU Autoconf Automake and Libtool" [86]. Дополнительная информация по утилите autoconf в несколько ином аспекте рассматривается в главе 17.

Утилита automake — это попытка добавить Imake-подобную функцию вывода зависимостей как уровень над autoconf(1). Разработчик пишет шаблоны

в форме записи, которая явно подобна Imake-нотации. Затем утилита automake(1) компилирует их в файлы , которыми впоследствии оперируют autoconf-сценарии .

automake в середине 2003 года все еще оставалась сравнительно новой технологией. Она используется в нескольких FSF-проектах, но еще не принята широко за пределами FSF-сообщества. Несмотря на то, что ее общий подход выглядит многообещающе, утилита все еще является довольно хрупкой — она работает в стереотипных условиях, но склонна к серьезным сбоям, если попытаться использовать ее необычным путем.

Полная документация поставляется с утилитой automake, которую можно загрузить с сайта архива FSF.

Как известно, по мере того как проект движется от первого прототипа к распространяемой версии, код проходит через несколько циклов развития, в ходе которых разработчик исследует новые области, отлаживает, а затем стабилизирует достижения.

И такое развитие не прекращается с выходом первой версии продукта. Большинство проектов нуждаются в сопровождении и усовершенствовании после стадии 1.0, и уже впоследствии появляется множество версий. Отслеживание всех деталей этого процесса является той задачей, с которой компьютеры справляются лучше человека.

Развитие кода поднимает несколько практических проблем, которые могут быть основными причинами противоречий и монотонной работы, а следовательно, и серьезного снижения продуктивности. Время, потраченное на разрешение данных проблем, — это время, не уделенное правильной разработке конструкции и функциональности проекта.

Вероятно, наиболее важной проблемой является обратное восстановление. Если разработчик вносит изменение и выясняет, что оно нежизнеспособно, то каким образом можно вернуться к заведомо хорошей версии кода? Если процесс восстановления труден и ненадежен, то разработчику вообще тяжело решиться на внесение изменений (можно испортить весь проект или потратить очень много времени).