makepp_rules - Онлайн в облаке

ПРОГРАММА:

ИМЯ

makepp_rules - Как указать makepp создать что-то

ОПИСАНИЕ

?: &,
-,
@, B: : build_cache,
: build_check, D: :отправлять, E: : env, I: "ignore_error",
:включают, L: :последний шанс, M: мейкперл, N: "ноэхо", P: : парсер,
"перл", S: :подпись

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

Правило имеет общий формат

целевое_выражение: выражение_зависимости [: необязательные аргументы]
действия

Список целей не может содержать никаких автоматических переменных (кроме «$ (foreach)»). В
Список зависимостей может содержать только автоматические переменные, относящиеся к цели (т. е.
«$ (выход)», «$ (выходы)» или их синонимы). Действие может содержать любые автоматические
переменные.

Если makepp решает, что правило необходимо выполнить, выполняется каждая строка правила.
последовательно, и если какой-либо из них возвращает ненулевой статус, остальные не выполняются (и
makepp прерывается с ошибкой, если вы не указали параметр «-k» в командной строке.)
Каждое действие должно быть только одной строкой. Если действие слишком длинное, чтобы удобно писать на
одну строку, вы можете разделить ее на несколько строк и поставить обратную косую черту, чтобы указать, что
несколько строк следует объединить в одну.

Чтобы отличить действия от следующего правила, действие должно быть с отступом больше
чем строка, содержащая цели и зависимости. В отличие от других реализаций
make, makepp на самом деле не волнует, насколько вы отступаете или используете ли вы символы табуляции
а не пробелы. Чтобы сохранить обратную совместимость с традиционными производителями, правила
makepp использует для определения того, когда действия заканчиваются и начинается следующее правило, довольно сложно:

· Первая строка действия должна иметь отступ больше, чем строка, содержащая цель.

· Если строка имеет отступ одним символом табуляции или 8 пробелами или более, то это считается
линия действия.

· Пустая строка или строка комментария с символом «#» на правом поле заканчиваются
правило, если следующая непустая строка не имеет отступа более 8 пробелов (или более одного
вкладка).

· Если строка имеет отступ, равный или большему, чем первая строка действия, то она
считается дополнительной линией действий.

Есть несколько специальных действий:

& За этим символом должно следовать имя команды и любое количество аргументов. Оболочка
синтаксис здесь не полностью понят, только одинарные и двойные кавычки и обратная косая черта
символы внутри, как и во всем makepp. Имя команды либо ведет к функции
"c_имя" для вызова с оставшимися строками в качестве аргументов. Если такая функция может
не может быть найден, это идентично вызову "run" из блока "perl".

Это позволяет эффективно вызывать встроенную команду, команду из файла makefile или внешнюю команду.
Префикс «&» был выбран потому, что это функция, вызывающая функцию в Perl, и потому что
вначале это незаконно в Shell.

$ (КОРЕНЬ) / включить /%. H:% .h
& ln $ (ввод) $ (вывод)

ноэхо
@ Обычно каждая команда оболочки печатается по мере ее выполнения. Однако если первое слово
действия - "noecho" (или если оно начинается с символа "@"), то команда
не печатается. Например,

% .o:% .cxx
noecho $ (LIBTOOL) --mode = компилировать $ (CC) -c $ (ввод)

Это означает, что при выполнении команды libtool она не печатается. (Libtool
сам обычно печатает измененную команду, которую выполняет, поэтому она избыточна для
распечатайте дважды.)

ignore_error
- Обычно, если команда оболочки возвращает ненулевой статус, makepp прерывается, потому что
команда не удалась. Однако некоторые программы неправильно устанавливают статус при выходе, или
может быть ошибка, которая на самом деле не является фатальной и не должна прерывать весь
компиляция. Вы можете заставить makepp игнорировать статус возврата, указав
«ignore_error» в качестве первого слова командной строки (или «-» в качестве первого символа).
Например,

$ (фальшивая раздача):
ignore_error rm -r my_program - $ (VERSION) # Избавиться от предыдущего мусора.
& mkdir my_program - $ (ВЕРСИЯ)
& cp $ (ФАЙЛЫ) my_program - $ (ВЕРСИЯ)
tar cf my_program - $ (ВЕРСИЯ) .tar my_program - $ (ВЕРСИЯ)

Эта команда создает каталог, копирует в него кучу файлов, а затем помещает
все в tar-файл для распространения. Хорошая идея - очистить
предыдущее содержимое каталога, если раньше там что-то было, и это
что делает первая строка. "Rm" может дать сбой, но его статус возврата игнорируется.

Perl
мейкперл
По сути, это то же самое, что и оператор perl, но выполняется каждый раз, когда
выполнение правила, а не при чтении make-файла. Первый вариант - это простой Perl
код, а второй вариант сначала передает оператор через переменную Make-style
расширение.

О двух возможностях установки подтяжек на тело см. Объяснение на
"perl_perlcode" в makepp_statements. Обратите внимание, что третий вариант объяснен там
здесь не имеет значения, потому что все строки действий должны иметь отступ. Вы должны сигнализировать
сбой в операторах Perl, вызвав "die".

По правилу операторы Perl в настоящее время оцениваются в общем подпроцессе, за исключением
Windows. Это означает, что они имеют доступ только для чтения к любым переменным make-файла. Это также
процесс, который выполняет действия, отличные от Perl. Так что вызов exec или exit запутает
makepp. Но это может измениться в будущем. Для эффективного вызова Perl
скрипты, см. предыдущий пункт «&» или «запустить».

$ (фальшивая версия):
noecho perl {{# $ (target) & $ (VERSION) из Perl:
print "Это" .f_target (). "$ VERSION \ n";
}}
echo Вы можете смешивать это с командами Shell
-makeperl {print "Это $ (цель) $ (ВЕРСИЯ) \ n"}

Есть несколько разных видов правил, каждое из которых преследует разные цели.

Явный Правила
цель1 цель2: зависимость1 зависимость2 ...
действия, которые необходимо выполнить

Этот синтаксис указывает, что для того, чтобы сделать либо target1 or target2, все файлы
зависимость1, зависимость2и т. д., должно быть, уже были сделаны. Тогда данные действия
выполняется оболочкой для создания целей.

Первое явное правило в файле является целью по умолчанию и выполняется, если вы не укажете
любые цели в командной строке.

В отличие от традиционных программ make, makepp обычно предполагает, что один вызов действия
делает все цели (если нет зависимостей). Например, один вызов
of yacc создает оба выходных файла для этого правила:

y.tab.c y.tab.h: parser.y
$ (YACC) -d parser.y

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

· В действии правила упоминается автоматическая переменная $ @. (Синонимы «$ (вывод)» или
«$ (target)» не вызывает такого поведения.)

· В действии правила не упоминается автоматическая переменная «$ (output)» (или ее синоним
«$ (цели)»).

· Это не шаблонное правило, и здесь нет предложения foreach.

Например,

вся тестовая установка:
для subdir в $ (SUBDIRS); сделать cd $$ subdir && $ (MAKE) $ @; CD ..; сделано

- это обычная идиома в make-файлах, и makepp ее поддерживает. (Обратите внимание, что вы никогда не должны использовать
рекурсивный make в любых новых make-файлах, которые вы пишете - используйте оператор "load_makefile" или
вместо этого неявная загрузка make-файла.)

Если вы хотите, чтобы одно и то же правило выполнялось один раз для каждой цели (например, потому что цели
имеют похожие команды), предпочтительно использовать либо шаблонное правило (см. ниже), либо
Предложение "foreach". Например, если вы используете традиционную программу make, вы должны написать:

abcd:
do_something для сборки $ @> $ @

в makepp вы, вероятно, захотите написать это так:

$ (foreach):: foreach abcd
do_something для построения $ (вывод)> $ (вывод)

фальшивый направлена против

A фальшивый цель это цель, которая никогда не будет существовать в файловой системе; это просто
способ заставить makepp создать некоторые цели и, возможно, выполнить некоторые дополнительные команды.

Типичной фальшивой целью является "все", которое обычно используется для того, чтобы вызвать все, что может быть
построенный для постройки, вот так:

все: prog1 prog2 subdir / prog3 subdir2 / libmine.a
@ & echo "Все готово!"

Если вы наберете «makepp all» или поместите все в качестве первой явной цели в вашем make-файле
(что типично) и просто введите "makepp", тогда все зависимости будут
построен, то он напечатает «Все готово!». На этом этапе makepp будет искать файл ./все
и обнаружит, что его не существует. Он будет громко жаловаться.

Чтобы makepp не ожидал файл ./все чтобы выйти, вам нужно сказать ему, что это
фальшивая цель. Просто поместите в свой make-файл такую ​​строку (это не имеет значения
куда):

.PHONY: все

Эквивалентная альтернатива, которая иногда более удобна, - использовать "$ (фальшивый)"
функция, например:

$ (фальшивый все): prog1 prog2 subdir / prog3 subdir2 / libmine.a

Фальшивые цели в одном make-файле могут ссылаться на фальшивые цели в другом make-файле. Это
часто делается с "чистой" целью, например:

# Makefile верхнего уровня:
# здесь много правил и прочего
# ....
$ (фиктивная чистка): subdir1 / clean subdir2 / clean
& rm -fm моя_программа

Тогда в подкаталогах make-файлы могут выглядеть так:

# Makefile в подкаталоге
#...
$ (фиктивная чистота):
& rm -fm $ (подстановочный знак * .o * .a)

Но в настоящее время вы бы использовали команду «makeppclean» вместо чистой цели.

Wildcards

Можно безопасно указывать подстановочные знаки в списке зависимостей. Подстановочные знаки соответствуют не только файлам
которые существуют, но файлы, которые могут быть созданы в соответствии с правилами в make-файле. Например,
чтобы создать библиотеку из всех файлов .o в каталоге, вы можете написать это:

libmine.a: * .o
& rm -f $ (вывод)
ar cr $ (выход) $ (входы)

Это будет работать, даже если ни один из файлов ".o" еще не был создан, потому что makepp
символы подстановки соответствуют файлам, которые еще не существуют, но могут быть созданы. Это даже подберет
файлы, правило которых обнаруживается позже (в том же файле makefile или еще не прочитанном). В этом
последний пункт отличается от функции "подстановочный знак", которая ограничена известными правилами,
поскольку он должен возвращать свой результат при расширении.

Makepp поддерживает все обычные символы подстановки оболочки («*», «?» И «[]»). Он также имеет
подстановочный знак «**», который соответствует любому количеству промежуточных каталогов. (Эта идея была украдена
из zsh.) Например, «** / *. c» соответствует всем .c файлы во всем дереве исходных текстов.
"objects / ** / *. o" соответствует всем .o файлы, содержащиеся в любом месте подкаталога объекты
или любой из его подкаталогов или любой из их подкаталогов. Подстановочный знак "**" не будет
переходите по мягким ссылкам на каталоги любого уровня. Он также никогда не вернет фальшивые цели.

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

Первоначальное утверждение заключалось в том, что это безопасно. В том смысле, что работает ли
файлы уже существуют или должны быть созданы в первую очередь. Однако это небезопасно по смыслу.
что он по-прежнему будет соответствовать файлам, которые были созданы makepp, но больше не имеют правила (например,
вы удалили .c файл, но .o файл все еще существует.) Чтобы предотвратить это, используйте
Параметр "--rm-stale".

шаблон условиями,
Правило шаблона - это правило, которое применяется на основе некоторого текстового шаблона. Это используется для
применить то же правило ко всему классу файлов. Синтаксис такой же, как у GNU make
правила шаблона:

% .o:% .c
$ (CC) -c $ (ввод) -o $ (вывод)

Это говорит о том, что любой файл в текущем каталоге, который соответствует "* .c", может быть преобразован в
соответствующий файл .o с помощью данной команды.

Обратите внимание, что может быть предоставлено несколько зависимостей шаблонов. Например, если ваш xyz.o файл
зависит от соответствующего xyz.cpp файл, а также файл с именем moc_xyz.cflags который
содержит параметры компилятора, это можно выразить следующим образом:

% .o:% .cpp% .cflags
$ (CXX) `cat $ (стержень) .cflags` -c $ (входы) -o $ (выход)

У вас также может быть несколько шаблонных целей. Например,

% .tab.h% .tab.c:% .y
yacc -d $ (ввод)
& mv y.tab.h $ (основа) .tab.h
& mv y.tab.c $ (основа) .tab.c

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

makepp_percent_subdirs: = 1

перед первым правилом шаблона в вашем make-файле или, например, в командной строке.

Существует явная разница между "%" и подстановочным знаком "*", хотя оба соответствуют любому
строка: подстановочный знак возвращает список файлов, которые полностью используются в этот момент. Так
это зависит от всего .o файлы, которые можно собрать здесь:

прога: * .o
$ (LD) $ (LDFLAGS) $ (входы) -o $ (выход)

Этого нельзя было достичь, заменив "*" на "%", потому что последний предназначен для поочередного
согласование ввода и вывода, внутреннее создание одного правила для каждой согласованной основы.

статический описания условиями,
Статическое шаблонное правило - это шаблонное правило, которое применяется только к ограниченному набору файлов:

$ (СПЕЦИАЛЬНЫЕ_МОДУЛИ) .o:% .o:% .cpp
$ (CXX) -c $ (ввод) -o $ (вывод)

Это говорит о том, что правило шаблона применяется только к файлам в "$ (SPECIAL_MODULES) .o".

Это в основном для совместимости с GNU make; правила foreach (см. ниже) являются более
мощный способ сделать то же самое.

Для каждого условиями,
Приведенный выше синтаксис шаблонных правил достаточно мощный, чтобы поддерживать почти все сборки, но
иногда необходимо сделать что-нибудь посложнее. Makepp предоставляет больше
мощный синтаксис: предложение ": foreach" для правила.

target_expression: dependency_expression: foreach список файлов
действия

Простейший вид правила foreach - это просто шаблонное правило, применение которого ограничено.
к определенному списку файлов. Например, предположим, что у вас есть шаблонное правило, которое сообщает
makepp как скомпилировать все .c файлы. Однако у вас есть список .c файлы, для которых вы
хочу сделать что-то другое. Вы можете сделать что-то вроде этого:

# Вот правило, применимое ко всему:
% .o:% .c
$ (CC) $ (CFLAGS) -c $ (ввод) -o $ (вывод)

% .o:% .c: foreach $ (SPECIAL_MODULES)
$ (CC) $ (SPECIAL_CFLAGS) -c $ (ввод) -o $ (вывод)

Еще более эффективное использование правил foreach использует тот факт, что переменная
"$ (foreach)" устанавливается по очереди для каждого файла, соответствующего списку файлов и цели, и
Выражения зависимости оцениваются. Список файлов может содержать подстановочные знаки, и эти
сопоставить даже файлы, которые еще не существуют, но которые можно построить (см. «Подстановочные знаки» в
makepp_rules).

Это громоздкий синтаксис, но он чрезвычайно гибкий, поскольку переменная "$ (foreach)"
может появиться в выражении любым образом. Во-первых, обратите внимание, что правила шаблона на самом деле
частный случай правил foreach; правило шаблона

% .o:% .c
$ (CC) $ (CFLAGS) -c $ (ввод) -o $ (вывод)

в точности эквивалентен:

$ (patsubst% .c,% .o, $ (foreach)): $ (foreach): foreach * .c
$ (CC) $ (CFLAGS) -c $ (ввод) -o $ (вывод)

(Фактически, он преобразован примерно в это внутренне.)

В качестве примера того, как вы могли бы использовать предложение ": foreach", где шаблонное правило не
достаточно, предположим, у вас есть .c файлы, созданные с использованием какого-либо препроцессора
который принимает в качестве входных файлов с .k расширение. Вы хотите скомпилировать эти .c файлы с
другой набор параметров компиляции, чем обычно .c файлы, которые являются обычным источником
файлы. Вы можете сделать что-то вроде этого:

# Правило для обычных файлов .c:
% .o:% .c
$ (CC) $ (CFLAGS) -c $ (ввод) -o $ (вывод)

# Правило создания файлов .c из файлов .k:
% .c:% .k
$ (препроцессор) $ (ввод)> $ (вывод)

# Специальные правила сборки для файлов .c, созданных из файлов .k:
$ (foreach:%. k =%. o): $ (foreach:%. c =%. k): foreach * .k
$ (CC) $ (SPECIAL_CFLAGS) -c $ (ввод) -o $ (вывод)

(Здесь используется немного более сжатый синтаксис ссылки на подстановку вместо вызова
"пацубст" явно.)

Обратите внимание: если все, что вам нужно сделать, это изменить значение переменной (в данном случае "CFLAGS"
case) иногда удобнее использовать целевые переменные.

Наследие суффикс условиями,
Для обратной совместимости makepp поддерживает суффиксные правила старого стиля.

.суффикс1.суффикс2:
действия

эквивалентна

% .suffix2:% .suffix1
действия

но запомнить гораздо труднее. (Какой суффикс идет первым?) Обычно появляется правило
в устаревшем make-файле, например:

.co:
$ (CC) $ (CFLAGS) -c $ *. C -o $ *. O

что в точности эквивалентно

% .o:% .c
$ (CC) $ (CFLAGS) -c $ (ввод) -o $ (вывод)

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

· Наличие явно противоречащих друг другу правил построения файла является ошибкой.

· Шаблонные правила и правила foreach с подстановочными знаками никогда не отменяют явные правила. Таким образом
явные правила могут использоваться для указания исключений для шаблонных правил. (Обратите внимание, что просто
использование предложения ": foreach" не превращает что-либо в шаблонное правило. Он должен иметь
подстановочный знак (например, «*» или «?») как часть имени файла в предложении «: foreach». Если это
просто явный список файлов, он рассматривается как явное правило для каждого из них
файлы.)

· Когда конфликтующие шаблонные правила исходят из разных make-файлов, правила из "ближайшего"
make-файлы отменяют правила из «дальнейших» make-файлов. "Ближе" означает, что make-файл
расположен ближе к цели в иерархии каталогов (т. е. имя файла
target относительно каталога, из которого запускается make-файл, короче). Если это
не различает make-файлы, тогда правило из загружаемого make-файла
последний используется.

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

% .o:% .c: foreach ** / *. c
$ (CC) $ (CFLAGS) -c $ (ввод) -o $ (вывод)

и у вас может быть make-файл в одном из подкаталогов, который говорит:

% .o:% .c
$ (CC) $ (SPECIAL_CFLAGS) -c $ (ввод) -o $ (вывод)

· Правила шаблона, которые имеют более короткую цепочку вывода, предпочтительнее других шаблонов
правила. Например, если у вас были следующие правила (на основе примера из
Ядро Linux):

% .s:% .c
$ (CC) -s $ (ввод) -o $ (вывод)

%.Операционные системы
$ (AS) $ (ввод) -o $ (вывод)

% .o:% .c
$ (CC) -c $ (ввод) -o $ (вывод)

Если нам нужно создать «xyz.o», мы могли бы либо создать промежуточный файл «.s», а затем
пропустите это через ассемблер, используя первые два правила, или мы могли бы перейти непосредственно к
".o" файл с использованием последнего правила. Последнее правило предпочтительнее, потому что их меньше
шаги в цепочке вывода (один вместо двух).

· Шаблонные правила позже в make-файле переопределяют предыдущие шаблонные правила. (Это
назад от GNU make.) Это означает, что вы должны поместить свои более общие правила
раньше, а более конкретные правила позже. Например,

% .o:% .c # Общее правило компиляции.
действие

special _%. o: special _%. c # Специальное правило для файлов с
другое действие # префикс "special_".

Правило кредита
Иногда необходимо предоставить дополнительные параметры, чтобы изменить способ выполнения makepp
правило. Эти параметры указываются как ": optionname value" либо в строке, содержащей
зависимости или в следующей строке.

Если вы укажете параметры в отдельных строках, вы сможете использовать один и тот же
makefile с makepp и традиционным make. Например,

цель: зависимости
: подпись target_newer
действия

отлично работает с традиционной программой make для Unix, поскольку интерпретирует строку ": signature"
как команда оболочки, а команда, начинающаяся с двоеточия, ничего не делает.

: build_cache / путь / к / сборке / кешу
цель: зависимости
: build_cache / положить / кеш / файлы / туда / туда
действия

Задает путь к кэшу сборки, который будет использоваться для файлов, созданных этим правилом. Этот
отменяет действие оператора "build_cache" или команды "--build-cache"
вариант линии, если таковой имеется, для этого правила. См. Makepp_build_cache для получения подробной информации о сборке.
тайники.

Если вы укажете «none» вместо пути, вы отключите кеш сборки для этого
особое правило. Это может быть полезно, чтобы не тратить дисковое пространство на файлы, которые вы
знать, что кэшировать не полезно, потому что вы уверены, что они никогда не будут
повторно используются или потому, что они создаются настолько быстро, что их не стоит кэшировать.

: build_check build_check_method
цель: зависимости
: build_check target_newer
действия

Это сообщает makepp, какой алгоритм использовать, чтобы решить, нужно ли перестраивать целевые объекты.
См. Makepp_build_check для более подробной информации. Это отменяет эффект
оператор "build_check" или параметр командной строки "--build-check-method", если есть, для
это правило.

: env ПЕРЕМЕННЫЕ ...
Добавьте зависимость от значений названных переменных среды. Если кто-то из них
отличаются от предыдущей сборки, то цели считаются устаревшими, если
build_check так диктует. (Все встроенные методы проверки сборки, кроме
target_newer уважайте это.)

ПЕРЕМЕННАЯ может иметь форму «имя файла в ПЕРЕМЕННОЙ_ПЕРЕМЕННОЙ_ПУТЬ» (в кавычках), и в этом случае
цели считаются устаревшими, если первый каталог из разделенных двоеточиями
значение PATH_VARIABLE, в котором существует имя файла, отличается от последней сборки.
Это можно использовать, чтобы избежать перестройки целей, когда PATH_VARIABLE изменяется в
неактуальный способ.

:отправлять команду ...
Заключите каждое действие оболочки (но не действия Perl или команды Perl) в "sh -c '...'"
и добавьте к нему префикс command, но предполагайте, что цель не зависит от команды.
Это полезно, если вы хотите отправлять действия в систему очереди заданий, но результат
предполагается, что они не зависят от параметров организации очередей, а также от того,
система используется у всех.

:включают файл_или_шаблон
Правило зависит от компилятора:

% .o:% .c
: включить% .d: подпись C
gcc -MD -c ...

% .o:% .c
: include% .u: signature C # IBM использует другой суффикс
хлк -М -с ...

sub зависимости {# Превратите болтовню Microsoft в полезный формат
s / \ $ / \ $ \ $ / g;
s / (Примечание: включая файл: *)? (. +?) \ r? \ n / $ 1? "'$ 2'": "'" .f_output (). "':" / E;
}
% .o:% .c
: включить% .d: подпись C
cl -showIncludes -c ...> $ (основа) .d
& sed &definityify -o + <$ (основа) .d

Некоторые компиляторы (Intel icc, как gcc выше, или IBM xlc) могут создавать зависимости
файлы на лету. То есть, пока они компилируются, они пишут make-файл, который makepp может
включают. Преимущество перед сканером makepp в том, что он гарантированно на 100%
правильно, где мы можем только приблизиться.

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

ВНИМАНИЕ: это ненадежно по своей природе. Файл зависимостей создается самой
правило, для которого это зависимость. С другой стороны, компилятор знает обо всем
это внутренние подпрограммы, которые makepp обычно игнорирует. Это надежность
Преимущество только для случая, когда патч компилятора исправляет только вложенные включения. В
цена в том, что makepp просматривает намного больше файлов, что требует времени.

Есть загвоздка, когда вы удаляете инструкцию "#include" и соответствующий файл:
Он по-прежнему будет упоминаться в файле зависимостей с прошлого раза, когда он был
нужный. В таком случае вы должны отредактировать файл зависимости, чтобы удалить зависимость.
который больше не выполняется.

Эту функцию нельзя использовать с кешем сборки, потому что получение файла оттуда
требует знания всего о файле. Но файл зависимостей зависит от этих
files makepp узнает о них, прочитав их. Такая круговая зависимость обычно не является
возможно в надежной системе сборки. Это исключение, потому что после перестройки
и перечитывая файл зависимостей, все снова правильно.

Если вы встраиваете свои репозитории, makepp заберет файл зависимостей из
1-й репозиторий, содержащий один. Это не похоже на другие файлы, где требуется 1-й
с ожидаемой подписью. Это лучше, чем для кэшей сборки, где из-за отсутствия
подпись, он даже не может найти файл.

:последний шанс
Включите бессрочное правило, например

% .foo foo% .bar:: last_chance
& echo $ @ -o $ @
& cp $ (выходы)

Поскольку такое правило может генерировать практически бесконечное количество целей,
цель этого правила не будет соответствовать функции или шаблонному правилу $ (подстановочный знак), если только
что-то еще уже создало экземпляр правила, конкретно указав цель.
Кроме того, если указан "--rm-stale", то цель, оставшаяся от предыдущего
makepp run будет выглядеть устаревшим, если единственный способ создать его - использовать правило last_chance
это еще не было создано для цели, что является желательным поведением, потому что
сборка будет терпеть неудачу более последовательно, если она ошибочно полагается на подстановочный знак для
соответствовать целям из предыдущего запуска.

Параметр ": last_chance" предназначен для привлечения внимания к особому поведению
правило в отношении совпадения подстановочных знаков.

: parser синтаксический анализатор
Это сообщает makepp, как анализировать команду для обнаружения (включения) файлов. Как правило,
makepp догадывается, как это сделать, основываясь на словах самой команды (см.
makepp_scanning для подробностей). Однако, если makepp ошибается, вы можете
явно укажите парсер, например:

% .o:% .abc
: парсер c_compilation
действие здесь

Это заставляет makepp выполнять тот же синтаксический анализ и сканирование, что и для C / C ++.
build, даже если он не распознает действие как компиляцию C.

Парсер по умолчанию зависит от команды. Если вы не укажете параметр ": parser",
затем проверяется первое слово каждой команды. Например для компиляции или ссылки
команда makepp будет использовать синтаксический анализатор c_compilation; или если команда выглядит как
Вариант GNU, "gcc_compilation". Если синтаксический анализатор не найден, он использует синтаксический анализатор «нет». Для
подробнее об этом, или если вы хотите написать свой собственный парсер или изменить makepp
парсеры по умолчанию, см. makepp_scanning.

Обратите внимание, что это применимо ко всем командам в правиле, что может быть не тем, что вам нужно:

% .o:% .c: c-компиляция парсера
@echo 'Построение $ (вывод)'
@funny_cc ...

Это также интерпретирует "echo" как компилятор и выводит его аргумент 'Building
mymodule.o 'как неявную зависимость. Это приведет к жалобе на то, что он
не знает, как создать такой файл. В этом случае вам будет лучше с
"register_parser". Там вы найдете объяснение, как синтаксический анализатор можно представить как
имя класса или как имя функции.

:подпись метод_подписи
цель: зависимости
: подпись md5
действия

Это сообщает makepp, какой алгоритм использовать, чтобы определить, изменились ли зависимости.
См. Makepp_signatures для более подробной информации. Методы подписи, которые включены в
Дистрибутив makepp: "plain", "md5", "C" или "c_compilation_md5" и
"общий_объект". Это отменяет любой метод подписи, указанный с помощью "-m" или
Параметры командной строки "--signature-method" или с помощью оператора "signature".

Особый символы
Makepp может поддерживать имена файлов, в которых есть специальные символы, такие как двоеточие или пробел.
Предположим, например, что вы хотите создать файл с именем «a: thing» из файла «b: thing».
Вы не можете так написать правило:

a: thing: b: thing # Это синтаксическая ошибка
& cat $ (ввод) -o $ (вывод)

потому что makepp не будет знать, какие двоеточия отделяют цели от зависимостей, а какие -
часть имен файлов. Вместо этого просто заключите имя в кавычки, например:

"a: вещь": "b: вещь"
& cat $ (ввод) -o $ (вывод)

Теперь правило однозначное.

Синтаксис цитирования Makepp очень похож на синтаксис оболочки. Вы можете, например, использовать одиночный
кавычки вместо двойных кавычек, или вы можете экранировать специальные символы с помощью обратной косой черты:

а \: вещь: 'б: вещь'
& cat $ (ввод) -o $ (вывод)

Предположим, например, что ваше имя файла - "'"!; \ $ ". Теперь зачем вам такое имя файла?
Я не знаю, но вот несколько способов указать его для makepp (и оболочки):

\ '' "!; \ $$ '
"'\"!; \\ $$ "

Обратите внимание на то, когда makepp выделяет кавычки, а когда оболочка. Макэпп смотрит на
цитирует только в следующих случаях:

· В семействе тестов ifeq

· До и после правила двоеточие

· Во встроенной команде makepp

· В функции, относящейся к файлам

В отличие от оболочки, makepp не расширяет кавычки при присвоении их переменной. Таким образом
следующие правила идентичны:

FILE = 'имя с пробелами'
x: = $ (print $ (FILE)) # просто чтобы проверить, что цитаты все еще там
$ (FILE): # кавычки вокруг одного файла, удаленного makepp
& echo hello -o $ (FILE) # кавычки вокруг одного файла, удаленного makepp
echo there >> $ (FILE) # кавычки вокруг одного файла, удаленного Shell
'имя с пробелами':
& echo hello -o' имя с пробелами '
echo there >> '$ (output)' # цитаты были удалены выше, добавьте их снова

Обратите внимание, что (в отличие от Shell) переменные, начинающиеся с "$", раскрываются даже внутри одиночного
цитаты. Знаки доллара нельзя защитить кавычками или обратной косой чертой. Чтобы получить буквальный
знак доллара, используйте двойной знак доллара, например,

$ (фальшивые все):
@ & echo Это знак доллара: $$
@for val в abcd; делать echo $$ val; сделано

Как правило, вы можете иметь дело практически с любым специальным символом, цитируя его
каким-то образом. Сюда входят пробелы, управляющие символы и т. Д. Однако имейте в виду, что при
в настоящее время удаление комментариев в makepp несколько упрощено, и любые символы "#"
перед пробелом будут интерпретироваться как комментарии независимо от того, как они цитируются.

Когда имя цели или зависимости помещается в автоматическую переменную, например "$ (output)", тогда
кавычки и обратная косая черта удаляются. Это означает, что если вы хотите сослаться на
имя файла в действиях, вам, вероятно, придется снова процитировать его, например:

"имя файла с пробелами":
echo "Особое содержимое"> "$ @"

Если вы не заключите $ @ в кавычки, оболочка увидит команду

echo "Особое содержимое"> имя файла с пробелами

который записывает строку «Имя файла специального содержимого с пробелами» в файл с именем a.
Вероятно, это не то, что вам нужно.

Используйте makepp_rules онлайн с помощью сервисов onworks.net