Партнёры:
Хостинг:
make(1) |
make(1) |
make - сопровождение, обновление и пересоздание групп программ
Утилита make позволяет программисту сопровождать, обновлять и пересоздавать группы компьютерных программ. make выполняет команды из файла управления проектом (makefile) для обновления одного или нескольких целевых имен (имена обычно представляют собой программы). Если опция -f не указана, последовательно делаются попытки использовать makefile, Makefile и файлы системы управления исходным кодом (Source Code Control System - SCCS) s.makefile и s.Makefile. Если в качестве makefile указан -, берется стандартный входной поток. Можно указывать несколько пар аргументов -f makefile.
make обновляет цель, только если цели, от которых она зависит, более новые, чем сама цель. Все необходимые для построения цели файлы рекурсивно добавляются к списку целей. Отсутствующие файлы предполагаются устаревшими.
В файлы управления проектом можно включать следующий список директив, изменяющих поведение make. Они используются в файлах управления проектами как цели:
| .DEFAULT: | Если файл должен быть сделан, но для этого нет явных команд или соответствующих правил построения, используются команды, ассоциированные с целью .DEFAULT, если она существует. |
| .IGNORE: | Действует так же, как опция -i. |
| .MUTEX: | Устанавливает последовательность обновления указанных целей (см. подраздел "Параллельный make" ниже). |
| .PRECIOUS: | Цели, от которых зависит запись .PRECIOUS, не будут удалены при выходе или нажатии клавиши выхода или прерывания. |
| .SILENT: | Действует так же, как опция -s. |
Опции make перечислены ниже:
| -B | Разбивать результаты выполнения параллельного make на соответствующие блоки для удобства чтения. |
| -e | Переменные среды переопределяют присваивания в файлах управления проектами. |
| -f имя_файла | Указывает имя файла управления проектом. |
| -i | Игнорировать коды ошибок, возвращаемые вызываемыми программами. |
| -k | Отказаться от обработки текущей записи, если она закончилась неудачно, но продолжить обработку других ветвей, не зависящих от этой записи. |
| -n | Режим без выполнения. Команды выдаются, но не выполняются. Печатаются даже командные строки, начинающиеся с @. |
| -p | Выдать полный набор макроопределений и описаний целей. |
| -P | Обновлять одновременно несколько целей. Количество одновременно обновляемых целей определяется переменной среды PARALLEL и наличием директив .MUTEX в файлах управления проектами. |
| -q | Запрос. make возвращает нулевой или ненулевой код возврата в зависимости от того, обновлен или нет целевой файл. |
| -r | Не использовать встроенные правила. |
| -s | "Молчаливый" режим. Не выдавать строки команд перед выполнением. |
| -t | Обновить дату последнего изменения ("затронуть" - touch) у целевых файлов (тем самым они будут считаться обновленными) вместо выполнения обычных команд. |
| -u | Безусловно пересоздать цели, игнорируя все временные отметки. |
| -w | Подавить выдачу предупреждений. Фатальные сообщения по-прежнему будут выдаваться. |
Файл управления проектом, указываемый в опции -f (или используемый по умолчанию), - это файл специальной структуры, содержащий явные инструкции по обновлению и пересозданию программ, а также последовательность записей, определяющих зависимости. Первая строка записи представляет собой непустой список целей через пробел, за которым идет двоеточие (:), а затем (возможно пустой) список требуемых файлов или файлов, от которых зависит цель. Текст после ; и все последующие строки, начинающиеся с символа табуляции, являются командами интерпретатора shell, которые необходимо выполнить для обновления цели. Первая непустая строка, не начинающаяся с символа табуляции или #, задает новую зависимость или определение макроса. Команды интерпретатора shell можно переносить на следующую строку, указывая обратную косую (\) перед переводом строки. Все введенное в команде (за исключением начального символа табуляции) передается непосредственно интерпретатору без изменений. Так,
echo a\ b
выдаст
ab
точно так же, как и в командном интерпретаторе.
Комментарии начинаются со знака # и продолжаются до перевода строки; при этом в них включаются последовательности обратная косая-перевод строки.
Следующий файл управления проектом утверждает, что pgm зависит от двух файлов, a.o и b.o, которые, в свою очередь, зависят от соответствующих файлов с исходным кодом (a.c и b.c) и общего заголовочного файла incl.h:
pgm: a.o b.o cc a.o b.o -o pgm a.o: incl.h a.c cc -c a.c b.o: incl.h b.c cc -c b.c
Строки команд выполняются по очереди, каждая в отдельном командном интерпретаторе. Чтобы указать, какой командный интерпретатор должна использовать утилита make для выполнения команд, можно использовать переменную среды SHELL. По умолчанию используется /usr/bin/sh. Первым одним или двумя символами команды могут быть: @, -, @- или -@. Если указан символ @, выдача команды подавляется. Если указан символ -, make игнорирует ошибку. При выполнении каждая строка печатается, если только не указана опция -s, в файле управления проектом нет директивы .SILENT: и если начальная последовательность символов команды не содержит символа @. Опция -n вызывает печать без выполнения; однако, если командная строка содержит подстроку $(MAKE), она всегда выполняется (см. обсуждение макроса MAKEFLAGS в разделе "Среда" ниже). Опция -t (затронуть) обновляет дату модификации файла, не выполняя никаких команд.
Команды, возвращающие ненулевой код возврата, обычно прерывают работу make. Если указана опция -i, в файле управления проектом имеется запись .IGNORE: или если начальная последовательность символов содержит символ -, ошибка игнорируется. Если указана опция -k, обработка текущей записи прекращается, но продолжается для других ветвей, не зависящих от соответствующей цели.
Прерывание или выход ведет к удалению цели, если только цель не указана в списке зависимостей директивы .PRECIOUS.
Если утилита make вызывается с опцией -P, она путается строить одновременно, параллельно несколько целей. (Это делается с помощью стандартного механизма многозадачности системы UNIX, который позволяет одновременно выполнять несколько процессов.) Для файла управления проектом, показанного в примере в предыдущем разделе, будут созданы процессы для параллельного построения a.o и b.o. После завершения процессов будет построен файл pgm.
Количество целей, которое make попытается построить параллельно, определяется значением переменной среды PARALLEL. Если указана опция -P, но переменная PARALLEL не установлена, make будет пытаться построить не более двух целей одновременно.
Для указания определенной последовательности обновления целей можно использовать директиву .MUTEX. Эта возможность пригодится, когда две или более цели изменяют общий файл вывода, например, при добавлении модулей в библиотеку или при создании промежуточного файла с одним и тем же именем, как делают утилиты lex и yacc. Если бы файл управления проектом в примере из предыдущего раздела содержал директиву .MUTEX вида
.MUTEX: a.o b.o
это не позволило бы make строить a.o и b.o параллельно.
Утилита make читает переменные среды. Предполагается, что все переменные являются определениями макросов, и они обрабатываются соответствующим образом. Переменные среды обрабатываются до любого файла управления проектом и после применения внутренних правил; поэтому определения макросов в файле управления проектом имеют приоритет над переменными среды. При указании опции -e переменные среды имеют приоритет над определениями макросов в файле управления проектом. Суффиксы и связанные с ними правила в файле управления проектом имеют приоритет над соответствующими суффиксами во встроенных правилах.
Переменная среды MAKEFLAGS обрабатывается make как содержащая любые допустимые опции (кроме -f, -p и -r), определяемые в командной строке. Более того, при вызове make проверяет наличие переменной в среде, помещает в нее текущие опции и передает ее в вызовы команд. Таким образом, MAKEFLAGS всегда содержит текущие введенные опции. Эта возможность оказалась очень полезной для "супер-makeов". Фактически, как упоминалось выше, при использовании опции -n команда $(MAKE) все равно выполняется; таким образом, можно выполнить make -n рекурсивно для всей программной системы, чтобы увидеть, что будет выполняться. Такого результата можно достичь потому, что опция -n помещается в MAKEFLAGS и передается последующим вызовам $(MAKE). Такое использование make представляет собой один из способов отладки всех файлов управления для программного проекта без фактического выполнения требуемых действий.
Если в качестве первых семи символов строки в файле управления проектом указана строка include и после нее идет пробел или символ табуляции, предполагается, что остаток строки представляет собой имя файла, который и будет прочитан текущим вызовом после подстановки макросов.
Записи вида строка1 = строка2 являются определениями макросов. строка2 определяется как все символы до символа комментария или незамаскированного перевода строки. Последующие вхождения $(строка1[:подст1=[подст2]]) заменяются строкой2. Скобки необязательны, если используется односимвольное имя макроса и нет последовательности подстановки. Необязательная конструкция :подст1=подст2 является последовательностью подстановки (substitute sequence). Если она указана, все не перекрывающиеся вхождения подст1 в указанном макросе заменяются на подст2. Строки (для подстановки такого рода) ограничиваются пробелами, символами табуляции и перевода строки и началом строк. Пример использования последовательности подстановки показан в разделе " " ниже.
Имеется пять поддерживаемых внутренне макросов, полезных при написании правил построения целей.
| $* | Макрос $* заменяется именем текущего файла из списка зависимостей, от которого отброшен суффикс. Он заменяется только в правилах вывода. |
| $@ | Макрос $@ заменяется на полное имя текущей цели. Он заменяется только для явно указанных зависимостей. |
| $< |
Макрос $< заменяется только для правил вывода или правила
.DEFAULT. Это модуль, устаревший по отношению к цели
(построенное имя файла, от которого зависит цель). Так, в
правиле .c.o макрос будет заменен на файл .c. Вот пример
построения оптимизированных файлов .o из файлов .c:
или:
|
| $? | Макрос $? заменяется при обработке явных правил в файле управления проектом. Это список необходимых файлов, устаревших по отношению к цели, или, по сути, модулей, которые необходимо перестроить. |
| $% | Макрос $% заменяется, только когда цель является элементом архивной библиотеки вида lib(file.o). В этом случае, $@ заменяется на библиотеку (lib), а $% заменяется на элемент библиотеки, file.o. |
Четыре из пяти макросов имеют альтернативные формы. Если к любому из этих четырех макросов добавляется прописная буква D или F, его значение заменяется на полное имя каталога для D и только имя файла для F. Таким образом, $(@D) ссылается на определяющую каталог часть строки $@. Если определяющей каталог части нет, генерируется ./. Альтернативной формы не имеет только макрос $?.
Для определенных имен (например, заканчивающихся на .o) известны типичные файлы, от которых они зависят (исходные файлы), такие как .c, .s и так далее. Если в файле управления проектом нет команд обновления для такого файла и если существует соответствующий исходный файл, он компилируется для создания цели. В этом случае make использует правила вывода, позволяющие строить файлы из других файлов путем проверки суффиксов и определения подходящего внутреннего правила построения. В настоящее время поддерживаются следующие стандартные правила вывода:
| .c | .c~ | .f | .f~ | .s | .s~ | .sh | .sh~ | .C | .C~ |
| .c.a | .c.o | .c~.a | .c~.c | .c~.o | .f.a | .f.o | .f~.a | .f~.f | .f ~.o |
| .h~.h | .l.c | .l.o | .l~.c | .l~.l | .l~.o | .s.a | .s.o | .s~.a | .s ~.o |
| .s~.s | .sh~.sh | .y.c | .y.o | .y~.c | .y~.o | .y~.y | .C.a | .C.o | .C ~.a |
| .C~.C | .C~.o | .L.C | .L.o | .L~.C | .L~.L | .L~.o | .Y.C | .Y.o | .Y ~.C |
| .Y~.o | .Y~.Y |
Внутренние правила make содержатся в исходном файле rules.c программы make. Эти правила можно изменить. Для получения скомпилированных в make правил на любой машине в форме, подходящей для перекомпиляции, используется следующая команда:
make -pf - 2>/dev/null
Тильда в перечисленных выше правилах относится к файлу SCCS (см. sccsfile(4)). Так, правило .c~.o преобразует исходный файл C из SCCS в объектный файл (.o). Поскольку система управления исходным кодом SCCS использует префикс s., она несовместима с подходом make, основанном на суффиксах. Тем не менее, с помощью тильды можно заменить ссылку на файл ссылкой на соответствующий файл SCCS.
Правило с единственным суффиксом (например, .c:) определяет, как построить x из x.c. Фактически, второй суффикс пустой. Эта возможность пригодится для построения целей из одного исходного файла, например, процедур командного интерпретатора или простых программ на C.
Дополнительные суффиксы указываются в виде списка зависимостей для .SUFFIXES. Порядок здесь имеет значение: в качестве исходного файла используется первое возможное имя, для которого существует как файл, так и правило построения. По умолчанию используется список:
.SUFFIXES: .o .c .c~ .y .y~ .l .l~ .s .s~ .sh .sh~ .h .h~ .f .f~ .C .C~ .Y .Y~ .L .L~
И в этом случае приведенная выше команда печати внутренних правил покажет реализованный на данной машине список суффиксов. Несколько списков суффиксов объединяются в один; .SUFFIXES: без списка зависимостей очищает список суффиксов.
Первый пример можно реализовать короче.
pgm: a.o b.o cc a.o b.o -o pgm a.o b.o: incl.h
Такое сокращение возможно, потому что make имеет ряд внутренних правил построения файлов. Пользователь может добавлять правила к этому списку, просто задавая их в файле управления проектом.
Некоторые макросы используются стандартными правилами вывода, чтобы можно было включать дополнительные опции в результирующие команды. Например, CFLAGS, LFLAGS и YFLAGS используются в качестве опций компилятора для cc(1), lex(1) и yacc(1), соответственно. Можно опять порекомендовать описанный выше метод просмотра текущих правил.
Поиском исходных файлов можно управлять. Правило создания файла с суффиксом .o из файла с суффиксом .c задается как запись с .c.o: в качестве цели и с пустым списком зависимостей. Команды интерпретатора shell, связанные с целью, определяют правило создания файла .o из файла .c. Любая цель, не содержащая наклонных и начинающаяся с точки рассматривается как правило, а не как обычная цель.
Если имя цели или одного из элементов списка зависимостей содержит круглые скобки, считается, что это архивная библиотека, а строка в скобках ссылается на элемент библиотеки. Так, lib(file.o) и $(LIB)(file.o) оба ссылаются на архивную библиотеку, содержащую file.o. (В этом примере предполагается, что макрос LIB предварительно определен.) Выражение $(LIB)(file1.o file2.o) недопустимо. Правила, относящиеся к архивным библиотекам, имеют вид .XX.a, где XX - это суффикс, из файла с которым должен строиться элемент архива. Неприятный побочный эффект текущей реализации требует, чтобы XX отличался от суффикса элемента архива. Поэтому нельзя, чтобы lib(file.o) зависел от file.o явно. Чаще всего архивы создаются так, как показано ниже. Предполагается, что все исходные файлы написаны на языке C:
lib: lib(file1.o) lib(file2.o) lib(file3.o) @echo lib is now up-to-date .c.a: $(CC) -c $(CFLAGS) $< $(AR) $(ARFLAGS) $@ $(
Фактически, правило .c.a, указанное выше, встроено в make и в этом примере не обязательно. Ниже приведен более интересный, но и более ограниченный пример конструкции создания архивной библиотеки:
lib: lib(file1.o) lib(file2.o) lib(file3.o) $(CC) -c $(CFLAGS) $(?:.o=.c) $(AR) $(ARFLAGS) lib $? rm $? @echo lib is now up-to-date .c.a:;
Здесь использован режим подстановки при расширении макроса. По определению $? является списком имен объектных файлов (в lib), исходные тексты на C для которых устарели. Подстановка заменяет .o на .c. (К сожалению, нельзя заменить на .c~; однако, такое преобразование может стать возможным в дальнейшем.) Также обратите внимание на отключение правила .c.a:, которое создавало бы объектные файлы один за другим. Эта конструкция существенно ускоряет работу с архивными библиотеками. Такого типа конструкции становятся очень громоздкими, если архивная библиотека содержит смесь программ на ассемблере и на C.
Некоторые команды возвращают ненулевой код не тогда, когда нужно; чтобы обойти это, используйте -i или префикс - в строке команды.
Файлы с именами, содержащими символы =, : и @, не будут правильно обрабатываться. Команды, непосредственно выполняемые командным интерпретатором, в частности cd(1), действуют в make только в пределах строки. Синтаксис lib(file1.o file2.o file3.o) недопустим. Нельзя строить lib(file.o) из file.o.
Copyright 1994 Novell, Inc.
Copyright 2000 В. Кравчук,
OpenXS Initiative, перевод на русский язык
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |