Искусство программирования для Unix
Шрифт:
15.4.4.2. Imake
Утилита Imake была написана в попытке автоматизировать создание make-файлов для системы X Window. Она надстраивается на makedepend для решения как проблемы вывода зависимостей, так и проблемы переносимости.
Imake-система эффективно заменяет традиционные make-файлы 1make-файлами, написанными в более компактной и мощной форме, которая (эффективно) компилируется в make-файлы.
Imake хорошо подходит для разрешения трудностей переносимости и конфигурации, специфических для X, и используется во всех проектах, которые являются частью дистрибутива X Window. Однако за пределами Х-сообщества данная утилита не приобрела большой популярности. Она трудна для изучения, использования и расширения, а кроме того, генерирует make-файлы огромных размеров и сложности.
Тто&е-инструменты доступны на любой Unix-системе, поддерживающей X, включая Linux. Существует один "героический" проект [16], цель которого заключается в "прояснении тайн" Imake для не Х-программистов. Вопросы, освещаемые данным проектом, стоит изучить всем, кто собирается заниматься Х-программированием.
15.4.4.3. autoconf
Утилита autoconf была написана программистами, которые изучили и отклонили подход Imake. Утилита autoconf генерирует для каждого проекта shell-сценарии configure, которые подобны старомодным специальным конфигураторам, conf igure-сценарии способны генерировать make-файлы (в том числе).
Утилита autoconf направлена на разрешение проблемы переносимости и вообще не выполняет встроенного вывода зависимостей. Несмотря на то, что данная программа, вероятно, такая же сложная, как Imake, она является гораздо более гибкой и проще расширяется. Вместо использования базы данных правил в системе, утилита генерирует shell-код configure, который осматривает систему, определяя необходимые параметры.
Каждый conf igure-сценарий создается на основе уникального для проекта шаблона conf igure. in, который должен написать разработчик. Однажды сгенерированный сценарий configure является самодостаточным и способен конфигурировать данный проект на системах, которые не содержат саму утилиту autoconf(1).
Подход к созданию make-файлов, принятый для autoconf, подобен подходу Imake в том, что разработчик начинает с написания шаблона make-файла для своего проекта. Однако файлы Makefile . in, созданные autoconf, по существу являются просто шаке-файлами с метками-заполнителями для простой текстовой замены; не существует второй формы записи, которую требуется изучать. Если требуется осуществить вывод зависимостей, то необходимо предпринять явные шаги для вызова makede-pend(1) или подобного инструмента, или использовать утилиту automake( 1).
Утилита autoconf документирована в руководстве в GNU ш/о-формате. Исходные сценарии autoconf доступны на сайте архива FSF, а кроме того, они предустановлены на многих Unix и Linux-системах. Упомянутое руководство можно просматривать с помощью справочной
Несмотря на отсутствие непосредственной поддержки вывода зависимостей и характерного для autoconf узкоспециального подхода, в середине 2003 года данная утилита, несомненно, была наиболее популярной из всех генераторов make-файлов. Она превзошла Imake и стала причиной выхода из употребления, по крайней мере, одного главного конкурента (metaconfig).
Существует справочник "GNU Autoconf, Automake and Libtool" [86]. Дополнительная информация по утилите autoconf в несколько ином аспекте рассматривается в главе 17.
15.4.4.4. automake
Утилита automake — это попытка добавить make-подобную функцию вывода зависимостей как уровень над autoconf(1). Разработчик пишет шаблоны Makefile.am в форме записи, которая явно подобна Imake-нотации. Затем утилита automake(1) компилирует их в файлы Makefile. in, которыми впоследствии оперируют autoconf-сценарии configure.
automake в середине 2003 года все еще оставалась сравнительно новой технологией. Она используется в нескольких FSF-проектах, но еще не принята широко за пределами FSF-сообщества. Несмотря на то, что ее общий подход выглядит многообещающе, утилита все еще является довольно хрупкой — она работает в стереотипных условиях, но склонна к серьезным сбоям, если попытаться использовать ее необычным путем.
Полная документация поставляется с утилитой automake, которую можно загрузить с сайта архива FSF.
15.5. Системы контроля версий
Как известно, по мере того как проект движется от первого прототипа к распространяемой версии, код проходит через несколько циклов развития, в ходе которых разработчик исследует новые области, отлаживает, а затем стабилизирует достижения.
И такое развитие не прекращается с выходом первой версии продукта. Большинство проектов нуждаются в сопровождении и усовершенствовании после стадии 1.0, и уже впоследствии появляется множество версий. Отслеживание всех деталей этого процесса является той задачей, с которой компьютеры справляются лучше человека.
15.5.1. Для чего используется контроль версий
Развитие кода поднимает несколько практических проблем, которые могут быть основными причинами противоречий и монотонной работы, а следовательно, и серьезного снижения продуктивности. Время, потраченное на разрешение данных проблем, — это время, не уделенное правильной разработке конструкции и функциональности проекта.
Вероятно, наиболее важной проблемой является обратное восстановление. Если разработчик вносит изменение и выясняет, что оно нежизнеспособно, то каким образом можно вернуться к заведомо хорошей версии кода? Если процесс восстановления труден и ненадежен, то разработчику вообще тяжело решиться на внесение изменений (можно испортить весь проект или потратить очень много времени).