makepp_rules - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

makepp_rules -- Як сказати makepp, щоб щось побудувати

ОПИС

?: &,
-,
@, B: :build_cache,
:build_check, D: :відправка, E: :env, I: "ігнорувати_помилку",
:включати, L: :останній шанс, M: makeperl, N: "ноехо", P: :парсер,
"perl", S: :підпис

Правило – це те, що вказує makepp, як створити файл або клас файлів. Makepp підтримує
той самий синтаксис правила, що й інші реалізації make, плюс деякі власні доповнення.

Правило має загальний формат

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

Список цілей не може містити жодних автоматичних змінних (окрім "$(foreach)"). The
список залежностей може містити лише автоматичні змінні, які посилаються на ціль (тобто,
"$(вихід)", "$(вихід)" або їх синоніми). Дія може містити будь-яку автоматичну
змінні.

Якщо makepp вирішує, що правило потрібно виконати, виконується кожен рядок правила
послідовно, і якщо будь-який повертає ненульовий статус, залишок не виконується (і
makepp перериває роботу з помилкою, якщо ви не вказали параметр «-k» у командному рядку.)
Кожна дія має бути лише одним рядком. Якщо дія занадто довга для зручного запису на a
один рядок, ви можете розділити його на кілька рядків і поставити зворотну косу риску, щоб вказати, що
кілька рядків слід об'єднати в одну.

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

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

· Якщо рядок має відступ на один символ табуляції або 8 або більше пробілів, то він вважається
лінія дії.

· Порожній рядок або рядок коментаря із символом "#" на правому полі закінчується
правило, якщо наступний непорожній рядок не має відступу більше ніж на 8 пробілів (або більше одного
вкладка).

· Якщо рядок має відступ настільки ж або більше, ніж перший рядок дії, то він є
розглядається як додаткова лінія дій.

Є кілька спеціальних дій:

& Після цього символу має бути назва команди та будь-яка кількість аргументів. Shell
синтаксис тут не повністю зрозумілий, лише одинарні та подвійні лапки та зворотний скіс
символи всередині, як і в усьому makepp. Назва команди або веде до функції
"c_ім'я" викликатися з рештою рядків як аргументів. Якщо така функція може
не буде знайдено, це ідентично виклику "run" з блоку "perl".

Це дозволяє ефективно викликати вбудовану, надану make-файлом або зовнішню команду.
Префікс «&» був обраний, оскільки він є засобом виклику функції в Perl, і тому що
спочатку це незаконно в Shell.

$(ROOT)/include/%.h: %.h
&ln $(вхід) $(вихід)

noecho
@ Зазвичай кожна команда оболонки друкується під час її виконання. Однак якщо перше слово
дії «noecho» (або якщо вона починається з символу «@»), то команда
не друкується. Наприклад,

%.o: %.cxx
noecho $(LIBTOOL) --mode=compile $(CC) -c $(вхід)

Це означає, що коли виконується команда libtool, вона не друкується. (Libtool
сам зазвичай друкує змінену команду, яку він виконує, тому це зайве
роздрукувати його двічі.)

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

$(фальшиве розповсюдження):
ignore_error rm -r my_program-$(VERSION) # Позбавтеся від попереднього сміття.
&mkdir my_program-$(VERSION)
&cp $(FILES) my_program-$(VERSION)
tar cf my_program-$(VERSION).tar my_program-$(VERSION)

Ця команда створює каталог, копіює в нього купу файлів, а потім поміщає
все в файл tar для розповсюдження. Це гарна ідея очистити
попередній вміст каталогу, якщо там щось було раніше, і це
що робить перший рядок. "rm" може бути невдалим, але його статус повернення ігнорується.

Perl
makeperl
Це, по суті, те саме, що оператор perl, але виконується щоразу, коли
запуск правила, а не під час читання make-файлу. Перший варіант — звичайний Perl
коду, тоді як другий варіант спочатку передає оператор через змінну стилю Make
розширення.

Для двох можливостей встановлення дужок тіла див. пояснення на
"perl_perlcode" в makepp_statements. Зверніть увагу, що там пояснюється третій варіант
тут немає сенсу, оскільки всі рядки дій мають бути з відступом. Ви повинні подати сигнал
помилка в операторах Perl, викликаючи "die".

Згідно з правилом, оператори Perl зараз оцінюються в загальному підпроцесі, за винятком on
Windows. Це означає, що вони мають доступ лише для читання будь-яких змінних makefile. Це також
процес, який виконує дії, відмінні від Perl. Тому виклик exec або exit збиває з пантелику
makepp. Але це може змінитися в майбутньому. Для ефективного способу виклику Perl
сценаріїв, див. попередній пункт "&" або "виконати".

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

Існує кілька різних видів правил, кожне з яких має різну мету.

Явне Правила
target1 target2: залежність1 залежність2 ...
дії, які необхідно виконати

Цей синтаксис визначає, що для того, щоб зробити будь-який target1 or target2, всі файли
залежність1, залежність2, тощо, вже має бути зроблено. Тоді дані дії є
виконується снарядом для створення цілей.

Перше явне правило у файлі є цільовим призначенням за замовчуванням і створюється, якщо ви не вказуєте
будь-які цілі в командному рядку.

На відміну від традиційних програм make, makepp зазвичай припускає один виклик дії
створює всі цілі (якщо немає залежностей). Наприклад, один заклик
yacc створює обидва вихідні файли для цього правила:

y.tab.c y.tab.h : парсер.y
$(YACC) -d парсер.y

Зауважте, що інші реалізації make не мають концепції єдиної команди
створення кількох вихідних файлів, і тому, коли ви вкажете кілька цілей, вони будуть
виконувати правило один раз для кожної цілі. Makepp повернеться до такої поведінки, якщо вона виглядає так
це старий make-файл. Зокрема, воно виконуватиме правило один раз для кожної цілі,
замість одного разу загалом, якщо все з наступного вірно:

· Дія правила згадує автоматичну змінну $@. (Синоніми "$(вихід)" або
"$(target)" не викликає таку поведінку.)

· Дія правила не згадує автоматичну змінну "$(outputs)" (або її синонім
"$(цілі)").

· Це не шаблонне правило і немає речення foreach.

Наприклад,

вся тестова установка:
для підкаталогу в $(SUBDIRS); do cd $$subdir && $(MAKE) $@; компакт-диск ..; зроблено

це поширена ідіома в make-файлах, і makepp її підтримує. (Зверніть увагу, що ви ніколи не повинні використовувати
рекурсивне make в будь-яких нових файлах make-файлів, які ви пишете - використовуйте оператор load_makefile або
Натомість неявне завантаження make-файлу.)

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

а Б В Г:
do_something to build $@ > $@

у makepp ви, ймовірно, захочете написати це так:

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

Фальшиві цілі

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

Типовою фальшивою метою є «все», що зазвичай використовується, щоб викликати все, що може бути
будується, щоб будувати, ось так:

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

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

Щоб makepp не очікував файлу ./все щоб вийти, вам потрібно сказати йому, що це a
фальшива ціль. Просто вставте рядок, подібний до цього, у свій make-файл (це не має значення
де):

.PHONY: все

Еквівалентною альтернативою, яка іноді є більш зручною, є використання "$(phony)"
функція, така:

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

Фальшиві цілі в одному make-файлі можуть посилатися на фальшиві цілі в іншому make-файлі. Це
часто виконується з "чистою" метою, наприклад:

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

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

# Makefile у підкаталозі
# ...
$(фальшивий чистий):
&rm -fm $(підстановка *.o *.a)

Але в наш час замість чистої мети можна використовувати команду makeppclean.

Символи

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

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

Це працюватиме, навіть якщо жоден із файлів ".o" ще не створено, оскільки makepp's
символи підстановки відповідають файлам, які ще не існують, але можуть бути створені. Це навіть підніметься
файли, правило яких буде виявлено пізніше (в тому самому файлі make-файлу або ще не прочитаному). У цьому
останнім пунктом вона відрізняється від функції підстановки, яка обмежена відомими правилами,
оскільки він повинен повернути свій результат, коли він розгортається.

Makepp підтримує всі звичайні символи підстановки оболонки ("*", "?" і "[]"). Він також має a
символ підстановки "**", який відповідає будь-якій кількості проміжних каталогів. (Цю ідею вкрали
від zsh.) Наприклад, "**/*.c" відповідає всім .c файлів у всьому дереві джерел.
"objects/**/*.o" відповідає всім .o файли, що містяться в будь-якому місці підкаталогу об'єкти
або будь-який з його підкаталогів або будь-який з їх підкаталогів. Підстановка "**" не буде
переходьте за програмними посиланнями на каталоги будь-якого рівня. Він також ніколи не поверне фальшиві цілі.

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

Початкове твердження було, що це безпечно. Це в тому сенсі, що це працює чи
файли вже існують або їх потрібно створити спочатку. Однак це небезпечно в сенсі
що він усе одно відповідатиме файлам, створеним 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 $(stem).cflags` -c $(входи) -o $(вихід)

Ви також можете мати кілька цільових шаблонів. Наприклад,

%.tab.h %.tab.c : %.y
yacc -d $(вхід)
&mv y.tab.h $(stem).tab.h
&mv y.tab.c $(stem).tab.c

Зазвичай шаблонні правила шукають файли лише в поточних каталогах. Можна змусити
їх для пошуку в поточному каталозі та всіх каталогах під ним за допомогою налаштування

makepp_percent_subdirs := 1

перед першим шаблонним правилом у вашому make-файлі або, наприклад, у командному рядку.

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

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

Цього не можна було досягти, замінивши «*» на «%», оскільки останній призначений для поодинокого
узгодження вхідних даних і вихідних даних, створюючи внутрішньо одне правило для кожного відповідного стовбура.

Статичний модель Правила
Статичне шаблонне правило — це правило шаблону, яке застосовується лише до обмеженого набору файлів:

$(SPECIAL_MODULES).o : %.o : %.cpp
$(CXX) -c $(вхід) -o $(вихід)

Це говорить про те, що правило шаблону застосовується лише до файлів у "$(SPECIAL_MODULES).o".

Це в основному для сумісності з GNU make; правила foreach (див. нижче) є більше
потужний спосіб зробити те саме.

Проповідувати Правила
Наведений вище синтаксис шаблону є достатньо потужним, щоб підтримувати майже всі збірки, але
іноді доводиться робити щось більш складне. Makepp надає більше
потужний синтаксис: речення ":foreach" для правила.

target_expression : залежність : foreach file-list
дії

Найпростіший тип правила 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)"
може бути будь-яким чином у виразі. По-перше, зауважте, що шаблонні правила насправді є a
окремий випадок правил foreach; правило шаблону

%.o : %.c
$(CC) $(CFLAGS) -c $(вхід) -o $(вихід)

еквівалентно:

$(patsubst %.c, %.o, $(foreach)) : $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(вхід) -o $(вихід)

(Насправді, він перетворюється приблизно на це внутрішньо.)

Як приклад того, як ви можете використовувати речення ":foreach", де шаблонного правила немає
достатньо, припустимо, у вас є .c файли, створені за допомогою якогось препроцесора
який приймає як вхідні файли з a .k розширення. Ви хочете їх зібрати .c файли з a
інший набір параметрів компіляції, ніж звичайний .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 $(вихід)

(Це використовує трохи більш стислий синтаксис посилань на заміну, а не виклик
"patsubst" явно.)

Зауважте, що якщо все, що ви хочете зробити, це змінити значення змінної («CFLAGS» у цьому
case) іноді зручніше використовувати специфічні для цілі змінні.

Legacy Суфікс Правила
Для зворотної сумісності makepp підтримує старі правила суфіксів.

.суфікс1.суфікс2:
дії

еквівалентна

%.суфікс2: %.суфікс1
дії

але запам'ятати набагато важче. (Який суфікс стоїть першим?) Зазвичай з’являється правило
у застарілому make-файлі, як це:

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

що точно еквівалентно

%.o : %.c
$(CC) $(CFLAGS) -c $(вхід) -o $(вихід)

Конфлікти Правила
Якщо існує кілька способів створити файл, makepp використовує просту процедуру
визначити, яке правило використовувати.

· Помилкою є суперечливі явні правила для створення файлу.

· Шаблонні правила та правила foreach із підстановочними знаками ніколи не замінюють явні правила. Таким чином
явні правила можна використовувати для визначення винятків для шаблонних правил. (Зверніть увагу, що просто
використання речення ":foreach" не робить щось шаблонним правилом. Воно повинно мати a
символ підстановки (наприклад, "*" або "?") як частина імені файлу в пункті ":foreach". Якщо це
просто явний список файлів, він розглядається як явне правило для кожного з них
файли.)

· Коли суперечливі правила шаблону надходять з різних make-файлів, правила з "ближче"
make-файли замінюють правила з "дальших" make-файлів. «Ближче» означає, що make-файл
знаходиться ближче до цілі в ієрархії каталогів (тобто ім'я файлу
ціль відносно каталогу, з якого запускається 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 $(вихід)

%.o: %.s
$(AS) $(вхід) -o $(вихід)

%.o: %.c
$(CC) -c $(вхід) -o $(вихід)

Якщо нам потрібно створити "xyz.o", ми можемо створити проміжний файл ".s", а потім
запустіть це через асемблер, використовуючи перші два правила, або ми могли б перейти безпосередньо до a
".o" за допомогою останнього правила. Краще останнє правило, оскільки їх менше
кроки в ланцюжку висновку (один замість двох).

· Правила шаблону пізніше у make-файлі замінюють правила шаблону, які були раніше. (Це
назад від GNU make.) Це означає, що ви повинні встановити свої більш загальні правила
раніше, а конкретніші правила пізніше. Наприклад,

%.o: %.c # Загальне правило компіляції.
дію

special_%.o: special_%.c # Спеціальне правило для файлів з a
інша дія # префікс "спеціальний_".

Правило опції
Іноді необхідно надати додаткові параметри, щоб змінити те, як makepp виконує файл
правило. Ці параметри вказуються як значення ":optionname" або в рядку, що містить
залежностях або в наступному рядку.

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

ціль: залежності
: підпис target_newer
дії

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

:build_cache /path/to/build/cache
ціль: залежності
: build_cache /put/cache/files/over/there
дії

Вказує шлях до кешу збірки, який буде використовуватися для файлів, створених цим правилом. Це
перевизначає ефект оператора "build_cache" або команди "--build-cache".
параметр рядка, якщо є, для цього правила. Дивіться makepp_build_cache, щоб дізнатися більше про збірку
кеші.

Якщо замість шляху ви вкажете "none", ви вимкнете для цього кеш збірки
конкретне правило. Це може бути корисно, щоб не витрачати місце на диску на ваші файли
know також не корисні для кешування, тому що ви впевнені, що вони ніколи не будуть корисними
повторно або тому, що вони створюються настільки швидко, що не варто їх кешувати.

:build_check build_check_method
ціль: залежності
: build_check target_newer
дії

Це вказує makepp, який алгоритм використовувати, щоб вирішити, чи потрібно перебудовувати цілі.
Дивіться makepp_build_check для отримання додаткової інформації. Це перекреслює ефект
Оператор "build_check" або параметр командного рядка "--build-check-method", якщо є, для
це правило.

: env ЗМІННИЙ ...
Додайте залежність від значень названих змінних середовища. Якщо хтось із них
відрізняються від попередньої збірки, то цілі вважаються застарілими, якщо
Так диктує метод build_check. (Усі вбудовані методи перевірки збірки, крім
target_newer поважайте це.)

VARIABLE може мати вигляд "ім'я файлу в PATH_VARIABLE" (в лапках), у цьому випадку
цілі вважаються застарілими, якщо перший каталог із роздільниками двокрапки
значення PATH_VARIABLE, в якому існує ім'я файлу, відрізняється від останньої збірки.
Це можна використовувати, щоб уникнути перебудови цілей, коли PATH_VARIABLE змінюється в файлі
невідповідний спосіб.

:відправка команда ...
Укласти кожну дію оболонки (але не дії Perl чи команди Perl) у "sh -c...'"
і додайте до нього префікс команди, але припустимо, що ціль не залежить від команди.
Це корисно, якщо ви хочете надіслати дії в систему черги завдань, але результат є
вважається незалежним від параметрів черги, а також від того, чи черга
система використовується взагалі.

:включати файл_або_шаблон
Правило залежить від компілятора:

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

%.o : %.c
: include %.u : підпис C # IBM використовує інший суфікс
xlc -M -c ...

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

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

Ця опція використовує це особливим чином: якщо файлу немає, тобто
зазвичай у першій збірці відбувається нормальне сканування. Але якщо файл присутній, ні
відбувається сканування (саме тому ми вказуємо розумний підпис вище – не сканування падає
повернутися до безглуздого за замовчуванням позначки часу та розміру). Замість цього він включає файл раніше
виконання правила. Після успішного виконання правила воно забуває про все
прочитати вперше, враховуючи, що файл міг бути застарілим. Замість цього читається
файл знову, якщо він змінився, щоб мати актуальну інформацію про збірку.

ПОПЕРЕДЖЕННЯ: це за своєю суттю ненадійно. Файл залежностей створює дуже
правило, від якого воно залежить. З іншого боку, компілятор знає про все
це внутрішній під-включає, що makepp зазвичай ігнорує. Це надійність
перевага лише у випадку, коли виправлення компілятора виправляє лише підгрупи. The
ціна полягає в тому, що makepp в кінцевому підсумку переглядає набагато більше файлів, на що потрібен час.

Під час видалення оператора "#include" є загвоздка та відповідний файл:
Він все ще згадуватиметься у файлі залежностей з минулого разу, коли це було
необхідний. У такому випадку ви повинні відредагувати файл залежності, щоб видалити залежність
який більше не виконується.

Цю функцію не можна використовувати з кешем збірки, оскільки звідти можна отримати файл
вимагає знати все про файл. Але файл залежностей залежить від них
файли, про які makepp дізнається, читаючи їх. Така кругова залежність не є нормальною
можливо в надійній системі побудови. Це виняток, оскільки після перебудови
і перечитавши файл залежностей, все знову правильно.

Якщо ви вбудуєте свої репозиторії, makepp забере файл залежностей з файлу
1-е сховище, яке містить один. Це на відміну від інших файлів, де він займає 1-е місце
з очікуваним підписом. Це краще, ніж для побудови кешів, де за браком
підпис, він навіть не може знайти файл.

:останній шанс
Увімкнути відкрите правило, наприклад

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

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

Параметр ":last_chance" призначений для привернення уваги до особливої ​​поведінки
правило щодо відповідності підстановочних знаків.

:парсер аналізатор
Це вказує makepp, як проаналізувати команду для виявлення (включення) файлів. Зазвичай,
makepp здогадується, як це зробити на основі слів у самій команді (див
makepp_scanning для деталей). Однак, якщо makepp здогадується неправильно, ви можете це зробити
явно вказати парсер, наприклад:

%.o: %.abc
: парсер c_compilation
дії тут

Це змушує makepp виконувати той самий аналіз і сканування, що й для C/C++
команди build, навіть якщо він не розпізнає дію як компіляцію C.

Синтаксичний аналізатор за замовчуванням залежить від команди. Якщо ви не вкажете параметр ":parser",
потім перевіряється перше слово кожної команди. Наприклад, для компіляції або посилання
команда makepp використовуватиме парсер "c_compilation"; або якщо команда виглядає як
Варіант GNU, "gcc_compilation". Якщо синтаксичний аналізатор не знайдено, він використовує аналізатор "none". Для
докладніше про це, або якщо ви хочете написати свій власний парсер або змінити makepp
парсери за замовчуванням, див. makepp_scanning.

Зауважте, що це стосується кожної команди в правилі, що може бути не тим, що вам потрібно:

%.o: %.c : c-компіляція аналізатора
@echo 'Побудова $(output)'
@funny_cc ...

Це також інтерпретує "echo" як компілятор і виводить його аргумент "Building
mymodule.o' як неявна залежність. Це призведе до скарги, що це
не знає, як створити такий файл. У цьому випадку вам буде краще
"парсер_реєстру". Там ви знайдете пояснення, як аналізатор може бути подано як a
ім'я класу або як ім'я функції.

:підпис метод_підпису
ціль: залежності
: підпис md5
дії

Це вказує makepp, який алгоритм використовувати, щоб визначити, чи змінилися залежності.
Дивіться makepp_signatures для більш детальної інформації. Методи підпису, які включені в
дистрибутив makepp — це «звичайний», «md5», «C» або «c_compilation_md5», і
"спільний_об'єкт". Це замінює будь-який метод підпису, зазначений за допомогою «-m» або
параметри командного рядка «--signature-method» або оператор «signature».

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

a:thing : b:thing # Це синтаксична помилка
&cat $(вхід) -o $(вихід)

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

"a:thing" : "b:thing"
&cat $(вхід) -o $(вихід)

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

Синтаксис цитування Makepp дуже схожий на синтаксис оболонки. Можна, наприклад, використовувати одиночний
лапки замість подвійних, або ви можете екранувати спеціальні символи за допомогою зворотної косої риски:

a\:thing : 'b:thing'
&cat $(вхід) -o $(вихід)

Припустимо, наприклад, що ваше ім’я файлу – «'»!;\$. Тепер, чому вам потрібна така назва файлу
Я не знаю, але ось кілька способів, як ви можете вказати це для makepp (і оболонки):

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

Зверніть увагу на те, коли makepp знімає лапки, а коли оболонка. Мейкпп дивиться
цитати лише в таких випадках:

· у сімействі тестів «ifeq».

· перед і після двокрапки правила

· у вбудованій команді makepp

· у функції, яка стосується файлів

На відміну від оболонки, makepp не розширює лапки, призначаючи їх змінній. Таким чином
наступні правила ідентичні:

FILE = 'ім'я з пробілами'
x := $(друк $(FILE)) # просто для того, щоб перевірити, чи все ще є лапки
$(FILE): # лапки навколо окремого файлу, вилученого makepp
&echo hello -o$(FILE) # лапки навколо окремого файлу, вилученого makepp
echo there >>$(FILE) # лапки навколо окремого файлу, вилученого Shell
"ім'я з пробілами":
&echo hello -o'name з пробілами'
echo there >>'$(output)' # лапки вилучено вище, додайте їх знову

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

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

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

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

"ім'я файлу з пробілами":
echo "Спеціальний вміст" > "$@"

Якщо ви не помістите лапки навколо $@, оболонка побачить команду

echo "Спеціальний вміст" > ім'я файлу з пробілами

який записує рядок "Ім'я файлу спеціального вмісту з пробілами" у файл, що викликається a.
Це, мабуть, не те, що ви хочете.

Використовуйте makepp_rules онлайн за допомогою служб onworks.net