Программист-прагматик. Путь от подмастерья к мастеру

СодержаниеГлава 8 Прагматические проекты 42 Вездесущая автоматизация Компилирование проекта → Часть 1

Глава 117

Часть 1

Компилирование проекта – это работа, которая должна быть надежной и повторяемой. Обычно проекты компилируются с помощью файлов сборки даже в интегрированной среде разработчика. В использовании файлов сборки есть ряд преимуществ. Это подготовленная по сценарию автоматическая процедура. Можно добавлять специальные программные процедуры для генерации текста программы и запускать регрессионные тесты в автоматическом режиме. Интегрированные среды имеют свои преимущества, но, пользуясь только ими, бывает трудно добиться нужного уровня автоматизации. Мы хотим осуществлять проверку, сборку, тестирование и передачу программы заказчику с помощью одной-единственной команды.

В разделе "Пороки дублирования" мы призываем к генерированию текстов программ для получения знания из обычных источников. Для облегчения этого процесса мы можем задействовать механизм анализа зависимости в программе make. Добавление правил в файл сборки для автоматической генерации файла из некоего другого источника не представляет особой сложности. Предположим, что есть некий файл XML, из которого необходимо сгенерировать файл Java, а результат скомпилировать.

. SUFFIXES:. Java. class. xml divhome.ru

. xml. java:

    perl convert. pl $$@

. java. class:

   $(JAVAC) $(JAVAC_FLAGS) $

Наберем make test. class, и программа make автоматически найдет файл с именем test. XML, сформирует файл. Java, выполнив сценарий Perl, а затем скомпилирует этот файл, создав test. class.

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

Можно воспользоваться файлом сборки для прогона либо регрессионных тестов, либо отдельного модуля, либо подсистемы в целом. Вы легко можете протестировать весь проект целиком при помощи одной-единственной команды на вершине исходного дерева или же протестировать отдельный модуль, воспользовавшись той же командой в единственном каталоге. Более подробно регрессионное тестирование рассматривается в разделе "Безжалостное тестирование".

Многие проекты устанавливают специальные рекурсивные иерархические файлы для сборки проектов и тестирования. Но не забывайте о некоторых потенциальных проблемах.

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

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

Навигация

Hosted by uCoz