| Каталог документации / Раздел "Программирование, языки" / Оглавление документа |
| |
|
Правило содержится в make-файле. Оно указывает, когда и как заново порождать определенные файлы, называемые целями правила (чаще всего правилу соответствует только одна цель). В нем перечисляются другие файлы, которые являются зависимостями цели, и команды, используемые для создания или обновления цели.
Порядок правил несущественнен, за исключением определения главной цели по умолчанию: цели, с которой начинается работа make, если вы ее не определили. По умолчанию главной целью make является цель первого правила в первом make-файле. Если в первом правиле есть несколько целей, то только первая цель берется в качестве главной цели по умолчанию. Есть два исключения: цель, начинающаяся с точки, не является главной целью по умолчанию, если она не содержит при этом один или более символа '/'; кроме того, цель, определяющая шаблонное правило, не воздействует на определение главной цели по умолчанию. Смотрите раздел 10.5 [Определение и переопределение шаблонных правил].
Поэтому обычно make-файл пишется так, чтобы первое правило было правилом для компиляции всей программы или всех программ, описываемых make-файлом (часто с именем цели 'all'). Смотрите раздел 9.2 [Аргументы для определения целей].
В общем виде, правило имеет следующий вид:
ЦЕЛИ : ЗАВИСИМОСТИ
КОМАНДА
...
ЦЕЛИ : ЗАВИСИМОСТИ ; КОМАНДА
КОМАНДА
...
Командные строки начинаются с символа табуляции. Первая команда может появится после строки зависимостей, предваренная символом табуляции, или на той же строке, что и зависимости, предваренная символом ';'. Оба способа имеют одинаковый эффект. Смотрите главу 5 [Написание команд в правилах].
Поскольку знак доллара используется в начале переменных, в том случае, если вы хотите поместить сам по себе знак доллара, напишите '$$' (смотрите главу 6 [Как использовать переменные]). Вы можете разбивать длинную строку путем вставки обратной косой чертой, за которой следует перевод строки, однако это не является обязательным требованием, потому что make не устанавливает ограничения на длину строк в make-файле.
Правило несет два вида информации: когда цели находятся в неактуальном состоянии и как, при необходимости, обновить их.
Критерий неактуального состояния определяется в терминах зависимостей, которые состоят из имен файлов, разделенных пробелами. (Допустимы также шаблонные символы и элементы архивов (Смотрите главу 11 [Элементы архива в качестве целей])). Цель считается неактуальной, если она не существует, или она более старая, чем одна из зависимостей (по результатам сревнения времен последних изменений). Идея состоит в том, что содержимое целевого файла вычисляется на основе информации, содержащейся в зависимостях; таким образом, как только любая из зависимостей изменяется, содержимое существующего целевого файла необязательно будет корректнм.
То, как надо обновлять цели, определяется набором команд. Команды представляют собой строки, которые будут выполнены командной оболочкой, но с некоторыми дополнительными возможностями. (Смотрите главу 5 [Написание команд в правилах]).
При использовании шаблонных символов одно имя файла может определять несколько файлов. Шаблонными символами для make являются '*', '?' и '[...]', как и в командной оболочке Bourne shell. Например, '*.c' определяет список всех файлов (в рабочем каталоге), чьи имена заканчиваются на '.c'.
Символ '~' в начале имени файла также имеет специальное значение. Если он один или за ним следует символ '/', он представляет ваш домашний каталог. Например, '~/bin' означает 'home/you/bin'. Если за символом '~' следует слово, строка представляет домашний каталог пользователя, именем которого является это слово. Например, '~john/bin' означает 'home/john/bin'.
Обработка шаблонов автоматически осуществляется в целях, в зависимостях или в командах (где обработку шаблонов осуществляет командная оболочка). В других ситуациях обработка шаблонов производится только тогда, когда явно ее закажете путем использования функции wildcard.
Специальное значение шаблонного символа выключается предшествующей ему обратной косой чертой. Таким образом, 'foo\*bar' ссылается на особый файл, чье имя состоит из 'foo', звездочки и 'bar'.
Шаблоны могут быть использованы в командах правила, где они обрабатываются командной оболочкой. Вот, например, правило для удаления всех объектных файлов:
clean:
rm -f *.o
Шаблоны также полезны в зависимостях правила. При использовании следующего правила в make-файле, 'make print' напечает все '.c'-файлы, которые были изменены с моменты последней их печати:
print: *.c
lpr -p $?
touch print
Обработка шаблонов не осуществляется в момент определения переменной. Таким образом, если вы напишете:
objects = *.o
objects := $(wildcard *.o)
Здесь приводится пример наивного использования обработки шаблонов, при которой делается не то, что вы могли бы предположить. Предположим, вы хотели бы указать, что исполняемый файл 'foo' создается из всех объектных файлов каталога, и вы пишете следующее:
objects = *.o
foo : $(objects)
cc -o foo $(CFLAGS) $(objects)
Но что будет, если вы удалите все '.o'-файлы? Когда шаблону не соответствует ни один файл, он остается в первозданном виде, и, таким образом, 'foo' будет зависеть от файла со странным именем '*.o'. Поскольку, вероятнее всего, такого файла не существует, make выдаст вам ошибку, говорящую о том, что он не может выяснить, как породить '*.o'. Это не то, чего вы хотите!
На самом деле, достичь желаемого результата при помощи обработки шаблонов возможно, но для этого нужны более развитые методы, включающие в себя функцию wildcard и строковые подстановки. Они описываются в следующем разделе.
Обработка шаблонов автоматически осуществляется в правилах. При этом она обычно не производится при установке значения переменной или внутри аргумента функции. Если вы хотите, чтобы в таких ситуациях шаблон был обработан, вам нужно использовать функцию wildcard, например:
$(wildcard ШАБЛОН...)
Одно из использований функции wildcard - получение списка всех исходных C-файлов каталога, что делается следующим образом:
$(wildcard *.c)
$(patsubst %.c,%.o,$(wildcard *.c))
Таким образом, make-файл для компиляции всех исходных C-файлов в каталоге и последующей их компоновки мог бы быть написан следующим образом:
objects := $(patsubst %.c,%.o,$(wildcard *.c))
foo : $(objects)
cc -o foo $(objects)
Для больших систем часто является желательным располагать исходные файлы в отдельных каталогах от двоичных файлов. Возможности поиска по каталогам программы make способствуют этому посредством автоматического поиска в некоторых каталогах для нахождения файла зависимости. Когда вы перераспределяете файлы по каталогам, вам не требуется изменять отдельные правила, достаточно изменить пути поиска.
Значение переменной программы make VPATH определяет список каталогов, в которых следует осуществлять поиск. Чаще всего предполагается, что в этих каталогах содержатся файлы зависимостей, которых нет в текущем каталоге, однако, VPATH определяет список путей поиска, который make применяет ко всем файлам, включая файлы, являющиеся целями правил.
Таким образом, если файл, упомянутый как цель или зависимость, не существует в текущем каталоге, make ищет файл с таким именем в каталогах, перечисленных в VPATH. Если в одном из них такой файл найден, то он становится зависимостью. Таким образом, правила могут указывать среди зависимостей имена исходных файлов, как если бы они они все существовали в текущем каталоге. Смотрите раздел 4.3.3 [Написание команд командной оболочки с учетом поиска по каталогам].
В переменной VPATH имена каталогов разделяются двоеточиями или пробелами. При поиске make перебирает каталоги в том порядке, в котором они перечислены.
Например,
VPATH = src:../headers
При этом значении VPATH следующее правило:
foo.o : foo.c
foo.o : src/foo.c
Средством, аналогичным переменной VPATH, но более гибким, является директива vpath (обратите внимание на маленькие буквы), которая позволяет определить путь поиска для определенного класса имен файлов, удовлетворяющих определенному шаблону. Таким образом, вы можете выделить некоторые каталоги поиска для одного класса имен файлов, а другие (или никаких) - для других имен файлов.
Есть три формы директивы VPATH:
Определяет пути поиска для имен файлов, соответствующих ШАБЛОНу. КАТАЛОГИ представляют собой список каталогов для поиска, разделенный двоеточиями или пробелами, по аналогии с путями поиска, используемыми в переменной VPATH
Очищает пути поиска, связанные с ШАБЛОНом
Очищает все пути поиска, ранее назначенные директивами vpath
Специальное назначение символа '%' в шаблоне директивы vpath может быть отменено предшествующим символом '\'. Специальное назначение символа '\', который в противном случае отменял бы специальное назначение последующего символа '%', может быть отменено еще одним символом '\'. Символы '\', отменяющие специальное назначение символов '%' или других символов '\', удаляются из шаблона перед тем, как ему будут сопоставляться имена файлов. Символы '\', которые заведемо не влияют на трактовку символа '%', остаются нетронутыми.
Если файл зависимости в текущем каталоге не существует, то в том случае, когда его имя соответствует шаблону из директивы vpath, поиск осуществляется в каталогах, указанных в той директиве, как если бы они были упомянуты в переменной VPATH (причем, поиск в этих каталогах осуществляется перед поиском в тех каталогах, которые на самом деле указаны в переменной VPATH).
Например, строка
vpath %.h ../headers
Если имя файла зависимости удовлетворяет нескольким шаблонам vpath, make обрабатывает одну за другой каждую подходящую директиву vpath, осуществляя поиск во всех каталогах, упомянутых в каждой такой директиве. make обрабатывает несколько директив vpath в том порядке, в котором они появляются в make-файле; несколько директив с одинаковым шаблоном не влияют друг на друга.
Таким образом, этот фрагмент
vpath %.c foo
vpath % blish
vpath %.c bar
vpath %.c foo:bar
vpath % blish
Когда зависимость найдена в результате поиска по каталогам в каталоге, отличном от текущего, команды в правиле не изменяются - они будут исполнены так, как они написаны. Поэтому вам следует внимательно писать команды с тем, чтобы они искали зависимости в тех же каталогах, где их находит make.
Это делается с помощью автоматических переменных, таких как '$^' (смотрите раздел 10.5.3 [Автоматические переменные]). Например, значением '$^' является список всех зависимостей правила, включая имена каталогов, в которых они были найдены, а значением '$@ ' - цель. Например:
foo.o : foo.c
cc -c $(CFLAGS) $^ -o $@
Часто зависимости также включают в себя заголовочные файлы, которые вы не хотите упоминать в команде. Автоматическая переменная '$<' является просто первой зависимостью.
VPATH = src:../headers
foo.o : foo.c defs.h hack.h
cc -c $(CFLAGS) $< -o $@
Поиск в каталогах, определенных в переменной VPATH или при помощи директивы vpath происходит также в случае неявных правил (смотрите главу 10 [Использование неявных правил])
Например, если файл 'foo.o' не имеет явных правил, make рассматривает неявные правила, такие как встроенное правило для компиляции 'foo.c', если такой файл существует. Если такого файла нет в текущем каталоге, то он ищется в соответствующих каталогах для поиска. Если файл 'foo.c' существует (или упоминается в make-файле) в любом из каталогов, применяется неявное правило для C-компиляции.
Командам из неявных правил обычно необходимо пользоваться автоматическими переменными; следовательно, они будут использовать имена файлов, найденных в результате поиска по каталогам без каких-либо дополнительных усилий с вашей стороны.
Поиск по каталогам библиотек, используемых компоновщиком, применяется особым образом. Эта специфическая особенность вступает в силу, когда вы пишете зависимость, имя которой имеет форму '-l<имя файла>'. (Вы можете сказать, что здесь происходит что-то странное, поскольку зависимость обычно является именем файла, а имя библиотечного файла имеет вид 'lib<имя файла>.a', а не '-l<имя файла>'.)
Когда имя зависимости имеет форму '-l<имя файла>', make специально обрабатывает его, устраивая поиска файла 'lib<имя файла>.a' в текущем каталоге, в каталогах, определенных путями поиска, соответствующими шаблонам директивы vpath и путями поиска из переменной VPATH, а затем в каталогах '/lib', '/usr/lib' и <префикс>/lib (обычно '/usr/local/lib').
Например, правило
foo : foo.c -lcurses
cc $^ -o $@
Цель-имя действия представляет собой цель, которая на самом деле не является именем файла. Это просто наименование некоторых команд, которые будут исполняться при явном запросе. Есть две причины использования целей-имен действий: для избежания конфликта с файлом, имеющим такое же имя, и для улучшения производительности.
Если вы пишете правило, команды которого не будут создавать целевой файл, команды будут выполняться каждый раз, когда придет время порождать цель. Вот пример:
clean:
rm *.o temp
Цель-имя действия прекратит работу, если кто-нибудь когда-нибудь создаст в этом каталоге файл 'clean'. По причине отсутствия зависимостей, файл 'clean' непременно будет считаться свежим, и команды из соответствующего правила не выполняться не будут. Чтобы избежать этой проблемы, вы можете явно объявить цель как имя действия, используя специальную цель .PHONY (смотрите раздел 4.7 [Специальные встроенные имена целей]), как показано ниже:
.PHONY : clean
Зная, что цель-имя действия не именует настоящий файл, который может быть переделан из других файлов, make пропускает поиск неявного правила для цели-имени действия (смотрите главу 10 [Использование неявных правил]). Именно поэтому объявление цели-имени действия положительно сказывается на производительности, даже если вас не беспокоит возможное существование настоящего файла с таким именем.
Таким образом, вы сначала пишете строку, которая устанавливает clean в качестве цели-имени действия, а затем пишете правило, как показано ниже:
.PHONY: clean
clean:
rm *.o temp
Цели-имена действий могут иметь зависимости. Когда в одном каталоге содержится много программ, наиболее удобно описать все программы в одном make-файле './Makefile'. Поскольку заново порождаемой целью по умолчанию станет первая цель в make-файле, удобно сделать ею цель-имя действия под названием 'all' и дать ей в качестве зависимостей все отдельные программы. Например:
all : prog1 prog2 prog3
.PHONY : all
prog1 : prog1.o utils.o
cc -o prog1 prog1.o utils.o
prog2 : prog2.o
cc -o prog2 prog2.o
prog3 : prog3.o sort.o utils.o
cc -o prog3 prog3.o sort.o utils.o
Теперь вы можете просто набрать в командной строке 'make', чтобы переделать все три программы или определить в качестве аргументов те, что необходимо переделать (например, 'make prog1 prog2').
Когда одна цель-имя действия является зависимостью другой, она служит в качестве ее подпрогораммы. Например, здесь 'make cleanall' удалит объектные файлы, файлы различий и файл 'program'.
.PHONY: cleanall cleanobj cleandiff
cleanall : cleanobj cleandiff
rm program
cleanobj :
rm *.o
cleandiff :
rm *.diff
Если правило не имеет зависимостей или команд, и цель правила - несуществующий файл, то make работает в предположении, что эта цель обновляется всегда, когда правило исполняется. Это подразумевает, что для всех целей, зависящих от нее, всегда будут выполняться команды из соответствующих правил.
Проиллюстрируем это примером:
clean: FORCE
rm $(objects)
FORCE:
Как можно видеть, использование 'FORCE' таким способом дает такой же результат, как и использование '.PHONY : clean'.
Использование '.PHONY' более наглядно и более эффективно. Однако, другие версии make не поддерживают '.PHONY', поэтому 'FORCE' появляется во многих make-файлах. Смотрите раздел 4.4 [Цели-имена действий].
Пустая цель является вариантом цели-имени действия; она используется для того, чтобы хранить набор команд для действий, которые вы время от времени явно запрашиваете. В отличие от цели-имени действия, этот целевой файл может реально существовать, но его содержимое несущественно, и обычно он пуст.
Предназначение пустого целевого файла - зафиксировать, с помощью времени его последней модификации, когда в последний раз исполнялись команды из правила. Это делается при помощи включения в набор команд команды touch для обновления целевого файла.
Пустой целевой файл должен иметь несколько зависимостей. Когда вы заказываете очередное порождение пустой цели, команды будут выполняться, если какая-нибудь из зависимостей более актуальна, чем цель; другими словами, если зависимость была изменена с того момента, как вы в последний раз породили цель. Вот пример:
print: foo.c bar.c
lpr -p $?
touch print
Некоторые имена, появляясь в качестве целей, имеют специальное значение.
Зависимости специальной цели .PHONY рассматриваются как цели-имена действий. Когда придет время рассматривать такую цель, make выполнит команды в безусловном режиме, независимо от того, существует ли такой файл и от того, какого время его последней модификации. Смотрите раздел 4.4 [Цели-имена действий].
Зависимости специальной цели .SUFFIXES представляют собой список суффиксов, которые будут использоваться при проверке суффиксных правил. Смотрите раздел 10.7 [Устаревшие суффиксные правила].
Команды, определенные для .DEFAULT, используются с любыми целями, для которых не найдено правил (как явных, так и неявных). Смотрите раздел 10.6 [Последняя возможность]. Если определены команды для .DEFAULT, то они будут исполняться для каждого файла, упомянутого в качестве зависимости, но не являющегося целью какого-либо правила. Смотрите раздел 10.8 [Алгоритм поиска неявного правила].
Цели, от которых зависит .PRECIOUS, подвергаются специальной обработке: если make уничтожается или прерывается при выполнении соответствующих им команд, цель не удаляется. Смотрите раздел 5.5 [Прерывание или уничтожение программы make]. Кроме того, если цель представляет собой промежуточный файл, он не будет удален после того, как необходимость в нем отпала, как это обычно делается. Смотрите раздел 10.4 [Цепочки неявных правил].
Вы можете также указать шаблон цели неявного правила (как, например, '%.o') в качестве файла зависимости специальной цели .PRECIOUS, чтобы сохранить промежуточные файлы, созданные посредством правил, шаблонам целей которых соответствуют имена этих файлов.
Если вы определяете зависимости для .IGNORE, то make будет игнорировать ошибки при выполнении команд, запускаемых для этих особых файлов. Команды для .IGNORE роли не играют.
Если .IGNORE определяется как цель без зависимостей, это значит, что необходимо игнорировать ошибки при выполнении команд для всех файлов. Такое использование .IGNORE
поддерживается только для исторической совместимости. Этот прием не очень полезен, поскольку он воздействует на любую команду в make-файле; мы рекомендуем вам использовать более гибкие способы игнорирования ошибок в отдельных командах. Смотрите раздел 5.4 [Ошибки в командах].
Если вы определяете зависимости для .SILENT, то make не будет перед выполнением команд, используемых для переделывания этих особых файлов, печатать соответствующие команды. Команды для .SILENT роли не играют.
Если .IGNORE определяется как цель без зависимостей, это значит, что необходимо подавлять печать любой команды перед ее выполнением. Такое использование .SILENT поддерживается только для исторической совместимости. Мы рекомендуем вам использовать более гибкие способы подавления печати перед выполнением отдельных команд. Смотрите раздел 5.1 [Отображение команды]. Если вы хотите подавить печать всех команд при определенном запуске make, используйте опцию '-s' или '--silent' (смотрите раздел 9.7 [Обзор опций]).
Будучи просто упомянутой в качестве цели, указывает программе make по умолчанию экспортировать порожденным процессам все переменные. Смотрите раздел 5.6.2 [Связь порожденным процессом make через переменные].
В качестве специальной цели рассматривается также любой суффикс из определения неявного правила, так же как и конкатенация двух суффиксов, как, например, '.c.o'. Эти цели представляют собой суффиксные правила, устаревший способ определения неявных правил (однако, все еще широко распространенный). В принципе, любое имя цели могло бы таким образом стать специальным, если бы вы разбили его на две части и добавили обе к списку суффиксов. На практике же суффиксы обычно начинаются с '.', поэтому эти специальные имена цели также начинаются с '.'. Смотрите раздел 10.7 [Устаревшие суффиксные правила].
Правило с несколькими целями эквивалентно написанию нескольких правил, каждое из которых имеет одну цель, и идентичных во всем остальном. Ко всем целям применяются одни и те же команды, но их действия могут меняться, поскольку вы можете подставлять в команду конкретное имя цели, используя '$@ '. Правило также распространяет действие всех зависимостей на все цели этого правила.
Это полезно в двух случаях.
kbd.o command.o files.o: command.h
bigoutput littleoutput : text.g
generate text.g -$(subst output,,$@ ) > $@
bigoutput : text.g
generate text.g -big > bigoutput
littleoutput : text.g
generate text.g -little > littleoutput
Один файл может быть целью нескольких правил. Все зависимости, упомянутые во всех таких правилах, образуют общий список зависимости для данной цели. Если цель обновлялась в последний раз раньше, чем какая-либо из зависимостей какого-либо правила, выполняются команды.
Для файла может исполнен только один набор команд. Если более, чем одно правило дает команды для одного и того же файла, make использует последний встретившийся набор команд и выдает сообщение об ошибке. (Как исключение, если имя файла начинается с точки, сообщение об ошибке не печатается. Такое странное поведение поддерживается только для совместимости с другими реализациями make). У вас нет причин писать make-файлы таким образом, поэтому make выдает вам сообщение об ошибке.
Дополнительное правило, содержащее только зависимости, может быть использовано для добавления нескольких дополнительных зависимостей одновременно к нескольким файлам. Например, обычно имеется переменная с именем objects, содержащая список всех файлов, являющихся выходом компилятора в порождаемой системе. Легкий способ указать, что все они должны быть перекомпилированы, если изменился файл 'config.h' - написать следующее :
objects = foo.o bar.o
foo.o : defs.h
bar.o : defs.h test.h
$(objects) : config.h
Еще один полезный совет состоит в том, что дополнительные зависимости могут быть определены при помощи переменной, которую вы устанавливаете в аргументе командной строки для make. (смотрите раздел 9.5 [Перекрывающиеся переменные]). Например, правило
extradeps=
$(objects) : $(extradeps)
Если ни одно из явных правил для цели не имеет команд, то make организует поиск применимого неявного правила, чтобы найти какие-нибудь команды (смотрите главу 10 [Использование неявных правил]).
Статические шаблонные правила - это правила, которые определяют несколько целей и создают имена зависимостей для каждой цели на основе имени цели. Они являются более общими, чем обычные правила с несколькими целями, поскольку цели не должны иметь одинаковые зависимости. Их цели должны быть похожими, но не обязательно одинаковыми.
Здесь приведен синтаксис статического шаблонного правила:
ЦЕЛИ ...: ШАБЛОН ЦЕЛИ: ШАБЛОНЫ ЗАВИСИМОСТЕЙ ...
КОМАНДЫ
...
ШАБЛОН ЦЕЛИ и ШАБЛОНЫ ЗАВИСИМОСТЕЙ указывают, как вычислять зависимости каждой цели. К каждой цели применяется шаблон цели для получения части имени цели, называемой основой. Эта основа подставляется в каждый из шаблонов зависимостей, в результате чего порождаются имена зависимостей (по одному из каждого шаблона зависимости).
Обычно каждый шаблон содержит ровно один символ '%'. Когда цель сопоставляется шаблону цели, символ '%' соответствует незафиксированной части имени цели - эта часть называется основой. Оставшаяся часть шаблона должна точно соответствовать имени цели. Например, цель 'foo.o' удовлетворяет шаблону '%.o', при этом 'foo' является основой. Цели 'foo.c' и 'foo.out' не удовлетворяют шаблону.
Имена зависимостей для каждой цели соэдаются путем подстановки основы вместо символа '%' в каждый шаблон зависимости. Например, если единственный шаблон зависимости - '%.c', то подстановка основы 'foo' дает имя зависимости 'foo.c'. Является законным написание шаблона зависимости, не содержащего '%' - в таком случае данная зависимость одинакова для всех целей.
Специальное назначение символа '%' в шаблоне правила может быть отменено предшествующим символом '\'. Специальное назначение символа '\', который в противном случае отменял бы специальное назначение последующего символа '%', может быть отменено еще одним символом '\'. Символы '\', отменяющие специальное назначение символов '%' или других символов '\', удаляются из шаблона перед тем, как он будет сравниваться с именами файлов или в него будет подставляться основа. Символы '\', которые заведомо не влияют на трактовку символа '%', остаются нетронутыми. Например, в шаблоне 'the\%weird\\%pattern\\', фрагмент 'the%weird\' предшествует действующему символу '%', а фрагмент 'pattern\\' следует за ним. Последние два символа '\' остаются на месте, поскольку они не могут воздействовать ни на какой символ '%'.
Вот пример, который компилирует или 'foo.o' или 'bar.o' из соответствующего '.c'-файла:
objects = foo.o bar.o
$(objects): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@
Каждая специфицированная цель должна соответствовать шаблону цели - для каждой цели, которая не соответствует, выдается предупреждение. Если у вас есть список файлов, из которого только некоторые будут соответствовать шаблону, вы можете использовать функцию filter для отсечения несоответствующих имен файлов (смотрите раздел 8.2 [Функции подстановки и анализа строк]):
files = foo.elc bar.o lose.o
$(filter %.o,$(files)): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@
$(filter %.elc,$(files)): %.elc: %.el
emacs -f batch-byte-compile $<
Еще один пример показывает, как использовать '$*' в статических шаблонных правилах:
bigoutput littleoutput : %output : text.g
generate text.g -$* > $@
Статические шаблонные правила имеют много общего с неявными правилами, определенными как шаблонные правила (смотрите раздел 10.5 [Определение и переопределение шаблонных правил]). В обоих случаях имеется шаблон для цели и шаблоны для построения имен зависимостей. Различие заключается в том, как make определяет, когда применяются правила.
Неявное правило может быть применено к любой цели, которая соответствует его шаблону, но оно применяется только тогда, когда цель не имеет команд, определенных иным способом и когда могут быть найдены зависимости. Если применяемым оказывается более одного неявного правила, применяется только одно - его выбор зависит от порядка правил.
Напротив, статическое шаблонное правило применяется именно к тому списку целей, который вы определяете в правиле. Оно не может применяться ни к какой другой цели и неизменно применяется к каждой из специфицированных целей. Если применимы два конфликтующих правила, и оба имеют команды, это является ошибкой.
Статическое шаблонное правило может быть предпочтительнее неявного правила по следующим причинам:
Правила с двойным двоеточием представляют собой правила, записываемые при помощи '::', а не ':' после имени цели. Их обработка отличается от обработки обработки обычных правил в том случае, когда одна и та же цель появляется более, чем в одном правиле.
Когда цель появляется в нескольких правилах, все правила должны быть одного типа: все обычные или все с двойным двоеточием. Если они с двойным двоеточием, то каждое из них не зависит от других. Команды каждого правила с двойным двоеточием выполняются, если цель обновлялась раньше, чем какая-либо зависимость из этого правила. Это может привести к выполнению любого или всех из правил с двойным двоеточием, а также к невыполнению ни одного такого правила.
Правила с двойным двоеточием, имеющие одну и ту же цель фактически полностью отделены одно от другого. Каждое правило с двойным двоеточием, обрабатывается индивидуально, так же, как обрабатываются правила с с различными целями.
Правила с двойным двоеточием для цели выполняются в том порядке, в котором они появляются в make-файле. Однако, в тех случаях, когда действительно есть смысл в правилах с двойным двоеточием, порядок выполнения команд не играет роли.
Правила с двойным двоеточием являются несколько неяными и нечасто приносят большую пользу - они обеспечивают механизм для тех случаев, в которых метод, используемый для обновления цели, отличается в зависимости от того, какие файлы зависимости вызвали обновление, а такие случаи являются редкими.
Каждое правило с двойным двоеточием должно определять команды - если они не определены, будет использовано неявное правило, в случае его применимости. Смотрите главу 10 [Использование неявных правил].
В make-файле для программы, многие из правил, которые вам приходится писать, указывают только на то, что некоторый объектный файл зависит от некоторого заголовочного файлов. Например, если 'main.c' использует 'defs.h' посредством директивы #include, вы бы написали:
main.o: defs.h
Чтобы избавиться от этого неудобства, большинство современных C-компиляторов могут написать для вас эти правила, просмотрев в исходном файле строки с директивой #include. Обычно это делается при помощи опции компилятора '-M'. Например, команда:
cc -M main.c
main.o : main.c defs.h
Обратите внимание, что такая зависимость порождает упоминание 'main.o' в make-файле, таким образом он впоследствии не может рассматриваться как промежуточный файл при поиске неявного правила. Это означает, что make никогда не будет удалять файл после его использования - смотрите раздел 10.4 [Цепочки неявных правил].
В старых программах make традиционной практикой было использование возможности компилятора генерировать зависимости с помощью команды вида 'make depend'. Эта команда создавала файл 'depend', содержащий все автоматически генерируемые зависимости - в таком случае make-файл мог использовать директиву include для их чтения (смотрите раздел 3.3 [Включение]).
В GNU-версии программы make из-за возможности обновления make-файлов такая практика становится устаревшей - вам никогда не требуется явно указывать программе make перегенерировать зависимости, поскольку она всегда перегенерирует любой make-файл, который является необновленым. Смотрите раздел 3.5 [Как переделываются make-файлы].
Рекомендуемая нами практика автоматической генерации зависимостей заключается в том, чтобы иметь для каждого исходного файла соответствующий make-файл. Для каждого исходного файла '<имя файла>.c' заводится make-файл '<имя файла>.d', в котором перечисляются файлы, от которых зависит объектный файл '<имя файла>.o'. В таком случае для порождения новых зависимостей требуется заново просмотреть только измененный файл.
Вот шаблонное правило для порождения файла зависимостей (т.е. make-файла) с именем '<имя файла>.d' из исходного C-файла с именем '<имя файла>.c':
%.d: %.c
$(SHELL) -ec '$(CC) -M $(CPPFLAGS) $< \
| sed '\''s/$*\\.o[ :]*/& $@/g'\'' > $@'
При использовании компилятора GNU C вы можете захотеть вместо флага '-M' использовать флаг '-MM'. Его использование приводит к пропуску зависимостей от системных заголовочных файлов. Подробности смотрите в разделе "Опции управления препроцессором" руководства по использованию GNU CC.
Предназначением программы sed является преобразование (например):
main.o : main.c defs.h
main.o main.d : main.c defs.h
Это делает каждый '.d'-файл зависимым от всех исходных и заголовочных файлов, от которых зависит соответствующий '.o'-файл. В этом случае make знает, что всегда, когда изменяется любой из исходных или заголовочных файлов, требуется перегенерировать зависимости.
После того, как вы определили правило для обновления '.d'-файлов, вы используете директиву include для чтения их всех. Смотрите раздел 3.3 [Включение]. Например:
sources = foo.c bar.c
include $(sources:.c=.d)
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |