Эрик Реймонд - Искусство программирования для Unix

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

all

Правило all должно создавать все выполняемые файлы проекта. Обычно в all нет явного критерия. Вместо этого правило ссылается на все цели верхнего уровня в проекте (и, вовсе неслучайно, документирует, каковы они). Традиционно all должно быть первым правилом make-файла, так чтобы оно было единственным правилом, которое выполняется, когда разработчик вводит команду makeбез аргументов.

test

Запуск автоматизированного тестового пакета для программы, обычно состоящего из набора блочных тестов (unit tests) [132] Блочный тест представляет собой тестовый код, прикрепленный к модулю для проверки корректности представления. Использование термина "блочный тест" подразумевает, что тест написан разработчиком одновременно с основным кодом и означает порядок, при котором версии модуля не считаются завершенными до тех нор, пока к ним не прикреплен тестовый код. Данный термин и идея возникли в методологии "Экстремального программирования", популяризированной Кентом Беком (Kent Beck), но получили широкое распространение среди Unix-программистов примерно с 2001 года. для поиска регрессий, ошибок или других отклонений от ожидаемого поведения во время процесса разработки. Правило "test" также могут использовать конечные пользователи программы, для того чтобы убедиться, что их инсталляция функционирует корректно.

clean

Удаление всех файлов (таких как бинарные исполняемые и объектные файлы), которые обычно создаются во время выполнения команды make all. Команда make cleanдолжна вернуть процесс сборки программного обеспечения в исходное состояние.

dist

Создание архива исходного кода (обычно с помощью программы tar(1) ), который можно распространять как единое целое и использовать для сборки программы заново на другой машине. Целью данной директивы является создание эквивалентного кода, зависящего от allтаким образом, чтобы правило make distавтоматически заново собирало целый проект, прежде чем создать его дистрибутивный архив. Это хороший способ избежать ошибок, в результате которых в дистрибутив не включаются действительно необходимые производные файлы (например, простой текстовый файл READMEв fetchmail , который фактически генерируется из HTML-файла).

distclean

Отбрасывает все, кроме того, что разработчик включил бы в случае упаковки исходного кода с помощью команды make dist. Действие может быть аналогичным команде make clean, но distclean следует в любом случае включать как отдельное правило для документирования происходящего. Если действие отличается, то обычно оно отличается отбрасыванием локальных конфигурационных файлов, которые не являются частью обычной последовательности сборки make all(такой как последовательность, сгенерированная утилитой autoconf(1)\autoconf(1) рассматривается в главе 17).

realclean

Отбрасывает все, что может быть заново собрано с помощью данного make-файла. Действие может быть таким же, как make distclean, но realclean следует в любом случае включать как отдельное правило для документирования происходящего. Если действие отличается, то обычно оно отличается отбрасыванием файлов, которые являются производными, но (по какой-либо причине), так или иначе поставляются с исходными кодами проекта.

install

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

uninstall

Удаление файлов, установленных в системные каталоги командой make install(обычно данная операция требует полномочий администратора). Эта операция должна быть полностью противоположной make install. Это правило означает подчинение соглашениям, которые ищут опытные пользователи Unix, так как для них они являются подтверждением продуманной конструкции. Напротив, его отсутствие является в лучшем случае небрежностью и (например, когда в ходе инсталляции создаются большие файлы базы данных) может рассматриваться как некомпетентность и невнимательность.