makepp_rules - Online w chmurze

PROGRAM:

IMIĘ

makepp_rules -- Jak powiedzieć makeppowi, żeby coś zbudował

OPIS

?: &,
-,
@, B: :buduj_cache,
:sprawdzanie_kompilacji, D: :załatwić, E: :śr., I: "ignoruj_błąd",
:włączać, L: :Ostatnia szansa, M: twórca, N: „noecho”, P: :parser,
"perl", S: :podpis

Reguła mówi makepp, jak zbudować plik lub klasę plików. Makepp wspiera
ta sama składnia reguł, co inne implementacje make, plus kilka własnych dodatków.

Reguła ma format ogólny

wyrażenie_docelowe : wyrażenie_zależności [ : argumenty opcjonalne]
działania

Lista celów nie może zawierać żadnych zmiennych automatycznych (z wyjątkiem „$(foreach)”). ten
lista zależności może zawierać tylko automatyczne zmienne odnoszące się do celu (tj.
„$(wyjście)”, „$(wyjścia)” lub ich synonimy). Akcja może zawierać dowolne automatyczne
zmiennych.

Jeśli makepp zdecyduje, że reguła musi zostać wykonana, wykonywany jest każdy wiersz reguły
sekwencyjnie, a jeśli jakikolwiek zwraca niezerowy status, reszta nie jest wykonywana (i
makepp przerywa działanie z błędem, chyba że określiłeś opcję "-k" w wierszu poleceń.)
Każda akcja powinna mieć tylko jedną linię. Jeśli akcja jest zbyt długa, aby wygodnie pisać na
pojedynczą linię, możesz podzielić ją na kilka linii i umieścić odwrotny ukośnik, aby wskazać, że
kilka linii należy połączyć w jedną.

Aby odróżnić akcje od następnej reguły, akcja powinna mieć większe wcięcie
niż wiersz zawierający cele i zależności. W przeciwieństwie do innych wdrożeń
make, makepp tak naprawdę nie dba o to, jak bardzo je wcięłeś i czy używasz znaków tabulacji
zamiast spacji. Aby zachować zgodność wsteczną z tradycyjnymi markami, zasady
makepp używa do decydowania, kiedy akcja się kończy, a zaczyna następna reguła, są nieco skomplikowane:

· Pierwsza linia akcji musi być wcięta bardziej niż linia zawierająca cel.

· Jeśli linia jest wcięta o jeden znak tabulacji lub o 8 lub więcej spacji, uważa się, że
linia działania.

· Pusta linia lub linia komentarza ze znakiem „#” na prawym marginesie kończy
reguły, chyba że kolejny niepusty wiersz jest wcięty na więcej niż 8 spacji (lub więcej niż jeden)
patka).

· Jeśli linia jest wcięta tak samo lub bardziej niż pierwsza linia akcji, to jest
uznano za dodatkowy kierunek działań.

Istnieje kilka specjalnych elementów akcji:

& Po tym symbolu powinna następować nazwa polecenia i dowolna liczba argumentów. Powłoka
składnia nie jest tutaj w pełni zrozumiała, tylko pojedyncze i podwójne cudzysłowy i odwrotny ukośnik
znaków wewnątrz, jak w całym makepp. Nazwa polecenia albo prowadzi do funkcji
"C_Nazwa" do wywołania z pozostałymi ciągami jako argumentami. Jeśli taka funkcja może:
nie można znaleźć, jest to identyczne z wywołaniem "run" z bloku "perl".

Pozwala to na wydajne wywoływanie poleceń wbudowanych, dostarczonych przez makefile lub zewnętrznych.
Przedrostek „&” został wybrany, ponieważ jest to wywołanie funkcji w Perlu, a ponieważ
na początku jest to nielegalne w Shell.

$(ROOT)/włącz/%.h: %.h
&ln $(wejście) $(wyjście)

nieecho
@ Normalnie każde polecenie powłoki jest wypisywane podczas wykonywania. Jeśli jednak pierwsze słowo
akcji to „noecho” (lub jeśli zaczyna się od znaku „@”), to polecenie
nie jest drukowany. Na przykład,

%.o: %.cxx
noecho $(LIBTOOL) --mode=kompilacja $(CC) -c $(wejście)

Oznacza to, że gdy wykonywane jest polecenie libtool, nie jest ono drukowane. (Libtool
samo zwykle wypisuje zmodyfikowane polecenie, które wykonuje, więc jest to zbędne
wydrukuj go dwukrotnie.)

ignorować_błąd
- Normalnie, jeśli polecenie powłoki zwraca stan niezerowy, wtedy makepp przerywa, ponieważ
polecenie nie powiodło się. Jednak niektóre programy błędnie ustawiają status przy wyjściu lub
może wystąpić błąd, który tak naprawdę nie jest krytyczny i nie powinien przerywać całości
kompilacja. Możesz spowodować, że makepp zignoruje status powrotu, określając
"ignore_error" jako pierwsze słowo wiersza poleceń (lub "-" jako pierwszy znak).
Na przykład,

$(dystrybucja fałszywa):
ignore_error rm -r mój_program-$(WERSJA) # Pozbądź się poprzednich śmieci.
&mkdir mój_program-$(WERSJA)
&cp $(PLIKI) my_program-$(WERSJA)
tar cf mój_program-$(WERSJA).tar mój_program-$(WERSJA)

To polecenie tworzy katalog, kopiuje do niego kilka plików, a następnie umieszcza
wszystko do pliku tar do dystrybucji. Dobrym pomysłem jest oczyszczenie
poprzednia zawartość katalogu, jeśli coś tam było wcześniej, i to
co robi pierwsza linia. "rm" może się nie powieść, ale jego status powrotu jest ignorowany.

Perl
makeperl
Jest to zasadniczo to samo co instrukcja perl, ale jest wykonywane za każdym razem, gdy
uruchamianie reguły, a nie odczytywanie pliku makefile. Pierwszy wariant to zwykły Perl
kod, podczas gdy drugi wariant najpierw przekazuje instrukcję przez zmienną Make-style
ekspansja.

Dwie możliwości założenia szelek tułowia znajdują się w wyjaśnieniu na
"perl_perlcode" w makepp_statements. Zwróć uwagę, że wyjaśniono tam trzeci wariant
nie ma tu sensu, ponieważ wszystkie linie działania muszą być wcięte. Musisz zasygnalizować
niepowodzenie w instrukcjach Perla, wywołując "die".

Na regułę instrukcje Perla są obecnie oceniane we wspólnym podprocesie, z wyjątkiem on
Okna. Oznacza to, że mają dostęp tylko do odczytu do dowolnych zmiennych makefile. To jest również
proces, który wykonuje akcje inne niż Perl. Więc wywołanie exec lub exit będzie mylące
makepp. Ale to może się zmienić w przyszłości. Aby wydajnie dzwonić do Perl
skryptów, patrz poprzedni element „&” lub „uruchom”.

$(wersja fałszywa):
noecho perl {{ # $(target) & $(VERSION) z Perla:
print "To jest ".f_target()." $VERSION\n";
}}
echo Możesz to mieszać z poleceniami powłoki
-makeperl { print "To jest $(docelowa) $(WERSJA)\n" }

Istnieje kilka różnych rodzajów zasad, z których każda ma inny cel.

Wyraźny Zasady
cel1 cel2: zależność1 zależność2 ...
czynności do wykonania

Ta składnia określa, że ​​aby wykonać albo target1 or target2, wszystkie pliki
zależność1, zależność2itp. musiały już być wykonane. Wtedy podane działania są
wykonywane przez powłokę, aby stworzyć cele.

Pierwsza wyraźna reguła w pliku jest domyślnym celem i jest tworzona, jeśli nie określisz
dowolne cele w wierszu poleceń.

W przeciwieństwie do tradycyjnych programów make, makepp zwykle zakłada, że ​​jedno wywołanie akcji
tworzy wszystkie cele (chyba że nie ma zależności). Na przykład jedna inwokacja
yacc tworzy oba pliki wyjściowe dla tej reguły:

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

Zauważ, że inne implementacje make nie mają koncepcji pojedynczego polecenia
tworzenie wielu plików wyjściowych, więc jeśli określisz wiele celów, będą
wykonaj regułę raz na cel. Makepp powróci do tego zachowania, jeśli wygląda na to
to jest plik makefile w starym stylu. W szczególności wykona regułę raz na cel,
zamiast tylko raz ogólnie, jeśli wszystkie z poniższych warunków są prawdziwe:

· Akcja reguły wspomina o zmiennej automatycznej $@. (Synonimy „$(wyjście)” lub
„$(target)” nie wywołują tego zachowania).

· Akcja reguły nie wspomina o automatycznej zmiennej "$(wyjścia)" (ani jej synonimie)
„$(cele)”).

· Nie jest to reguła wzorcowa i nie ma klauzuli foreach.

Na przykład,

cała instalacja testowa:
dla podkatalogu w $(SUBDIRS); wykonaj cd $$subdir && $(MAKE) $@; Płyta CD ..; Gotowe

jest powszechnym idiomem w plikach makefile i makepp go obsługuje. (Pamiętaj, że nigdy nie powinieneś używać
rekursywne make w każdym nowym pliku makefile, który piszesz -- użyj instrukcji "load_makefile" lub
zamiast tego niejawne ładowanie pliku makefile.)

Jeśli chcesz, aby ta sama reguła została wykonana raz dla każdego celu (np. ponieważ cele
mają podobne polecenia), lepiej jest użyć reguły wzorca (patrz poniżej) lub a
klauzula „foreach”. Na przykład, jeśli za pomocą tradycyjnego programu make napisałbyś:

abcd:
zrób_coś do zbudowania $@ > $@

w makepp prawdopodobnie chciałbyś napisać to tak:

$(foreach) : : foreach abcd
zrób_coś do zbudowania $(wyjście) > $(wyjście)

Fałszywy cele

A fałszywy cel jest celem, który nigdy nie będzie istniał w systemie plików; to tylko
sposób na zmuszenie makepp do zbudowania niektórych celów i ewentualnego wykonania dodatkowych poleceń.

Typowym fałszywym celem jest „wszystko”, które zwykle służy do spowodowania wszystkiego, co może być
zbudowany do zbudowania, tak:

wszystkie: prog1 prog2 podkatalog/prog3 podkatalog2/libmine.a
@&echo „Wszystko gotowe!”

Jeśli wpiszesz „makepp all”, lub jeśli umieścisz all jako pierwszy cel w swoim pliku makefile
(co jest typowe) i po prostu wpisz „makepp”, wtedy spowoduje to, że wszystkie zależności będą
zbudowany, to wypisze "Wszystko gotowe!". W tym momencie makepp będzie szukał pliku ./wszystko
i odkryje, że nie istnieje. Będzie głośno narzekać.

Aby makepp nie oczekiwał pliku ./wszystko aby wyjść, musisz powiedzieć, że to
fałszywy cel. Po prostu umieść linię podobną do poniższej w swoim pliku makefile (nie ma to żadnego znaczenia)
gdzie):

.FONIA: wszystkie

Równoważną alternatywą, która czasami jest wygodniejsza, jest użycie „$(phony )”
funkcja, tak:

$(fałszywe wszystko): prog1 prog2 subdir/prog3 subdir2/libmine.a

Fałszywe cele w jednym pliku makefile mogą odnosić się do fałszywych celów w innym pliku makefile. To jest
często robi się to z „czystym” celem, tak jak to:

# Makefile najwyższego poziomu:
# dużo zasad i innych rzeczy tutaj
#....
$(fałszywe czyste): subdir1/clean subdir2/clean
&rm -fm mój_program

Następnie w podkatalogach pliki makefile mogą wyglądać tak:

# Makefile w podkatalogu
#...
$(fałszywie czysty):
&rm -fm $(wieloznaczne *.o *.a)

Ale w dzisiejszych czasach używałbyś polecenia "makeppclean" zamiast czystego celu.

Symbole wieloznaczne

Na liście zależności można bezpiecznie określić symbole wieloznaczne. Symbole wieloznaczne pasują nie tylko do plików
które istnieją, ale pliki, które można utworzyć zgodnie z regułami w pliku makefile. Na przykład,
aby zbudować bibliotekę ze wszystkich plików .o w katalogu, możesz napisać tak:

libmine.a: *.o
&rm -f $(wyjście)
ar cr $(wyjście) $(wejścia)

To zadziała, nawet jeśli żaden z plików ".o" nie został jeszcze utworzony, ponieważ makepp's
symbole wieloznaczne odpowiadają plikom, które jeszcze nie istnieją, ale można je zbudować. To się nawet odbierze
pliki, których reguła zostanie później odkryta (w tym samym pliku makefile lub jeszcze nieprzeczytanym). W tym
ostatni punkt różni się od funkcji „wildcard”, która ogranicza się do znanych reguł,
ponieważ musi zwrócić swój wynik po rozwinięciu.

Makepp obsługuje wszystkie zwykłe symbole wieloznaczne powłoki ("*", "?" i "[]"). Posiada również
symbol wieloznaczny „**”, który pasuje do dowolnej liczby interweniujących katalogów. (Ten pomysł został skradziony
z zsh.) Na przykład „**/*.c” pasuje do wszystkich .c pliki w całym drzewie źródłowym.
"objects/**/*.o" pasuje do wszystkich .o pliki zawarte w dowolnym miejscu podkatalogu obiekty
lub którykolwiek z jego podkatalogów lub którykolwiek z ich podkatalogów. Symbol wieloznaczny „**” nie będzie
podążaj za miękkimi linkami do katalogów na dowolnym poziomie. Nigdy też nie zwróci fałszywych celów.

Symbole wieloznaczne Makepp zignorują pliki lub katalogi, które istnieją, ale nie można ich odczytać. Później
w sumie takie pliki i tak nie mogą być użyte w procesie budowania. Umieszczanie nieczytelnych plików w
katalog jest przydatny przede wszystkim do blokowania automatycznego importu danego pliku z
magazyn.

Początkowe twierdzenie było takie, że jest to bezpieczne. To w tym sensie, że działa, czy
pliki już istnieją lub muszą zostać najpierw zbudowane. Jednak w tym sensie jest to niebezpieczne
że nadal będzie pasował do plików zbudowanych przez makepp, ale nie ma już reguły (np
usunąłeś .c plik, ale .o plik nadal tam jest). Aby temu zapobiec, użyj
Opcja „--rm-stale”.

Wzór reguły
Reguła wzorca to reguła stosowana na podstawie pewnego wzorca tekstowego. Służy do
zastosować tę samą regułę do całej klasy plików. Składnia jest taka sama jak w przypadku GNU make
zasady wzoru:

%.o: %.c
$(CC) -c $(wejście) -o $(wyjście)

Oznacza to, że każdy plik w bieżącym katalogu, który pasuje do "*.c", może zostać przekonwertowany na
odpowiedni plik .o za pomocą podanego polecenia.

Należy zauważyć, że może być dostarczonych kilka zależności wzorcowych. Na przykład, jeśli twój xyz.o filet
zależy od odpowiedniego xyz.cpp pliku, a także w pliku o nazwie moc_xyz.cflags który
zawiera opcje kompilatora, można to wyrazić za pomocą:

%.o: %.cpp %.cflags
$(CXX) `kot $(pień).cflags` -c $(wejścia) -o $(wyjście)

Możesz także mieć kilka wzorców docelowych. Na przykład,

%.tab.h %.tab.c : %.y
yacc -d $(wejście)
&mv y.tab.h $(rdzeń).tab.h
&mv y.tab.c $(rdzeń).tab.c

Zwykle reguły wzorców szukają tylko plików w bieżących katalogach. Możesz wymusić
je do wyszukiwania w bieżącym katalogu i wszystkich katalogach pod nim, ustawiając

makepp_percent_subdirs := 1

na przykład przed pierwszą regułą wzorca w twoim pliku makefile lub w wierszu poleceń.

Istnieje wyraźna różnica między „%” a symbolem wieloznacznym „*”, chociaż oba pasują do dowolnego
ciąg: symbol wieloznaczny zwraca listę plików, które są w tym momencie całkowicie używane. Więc
to zależy od wszystkiego .o pliki do zbudowania tutaj:

prog: *.o
$(LD) $(LDFLAGS) $(wejścia) -o $(wyjścia)

Nie można tego osiągnąć, zastępując „*” znakiem „%”, ponieważ ten ostatni jest przeznaczony dla jednego po drugim
dopasowanie wejścia do wyjścia, tworząc wewnętrznie jedną regułę dla każdego dopasowanego rdzenia.

Statyczny wzorzec reguły
Statyczna reguła wzorca to reguła wzorca stosowana tylko do ograniczonego zestawu plików:

$(SPECIAL_MODULES).o: %.o: %.cpp
$(CXX) -c $(wejście) -o $(wyjście)

To mówi, że reguła wzorca dotyczy tylko plików w "$(SPECIAL_MODULES).o".

Dotyczy to głównie zgodności z GNU make; Foreach zasady (patrz poniżej) są bardziej
potężny sposób robienia tego samego.

Dla każdego reguły
Powyższa składnia reguł wzorców jest wystarczająco potężna, aby obsługiwać prawie wszystkie kompilacje, ale
czasami trzeba zrobić coś bardziej skomplikowanego. Makepp zapewnia więcej
rozbudowana składnia: klauzula ":foreach" dla reguły.

wyrażenie_docelowe : wyrażenie_zależności : foreach lista plików
działania

Najprostszym rodzajem reguły foreach jest reguła wzorca, której zastosowanie jest ograniczone
do określonej listy plików. Załóżmy na przykład, że masz regułę wzorca, która mówi:
makepp jak skompilować wszystko .c pliki. Masz jednak listę .c pliki, dla których ty
chcesz zrobić coś innego. Możesz zrobić coś takiego:

# Oto zasada, która dotyczy wszystkiego:
%.o: %.c
$(CC) $(CFLAGS) -c $(wejście) -o $(wyjście)

%.o : %.c : dla każdego $(SPECIAL_MODULES)
$(CC) $(SPECIAL_CFLAGS) -c $(wejście) -o $(wyjście)

Jeszcze bardziej wydajne użycie reguł foreach wykorzystuje fakt, że zmienna
"$(foreach)" jest ustawiane po kolei dla każdego pliku pasującego do listy plików i celu oraz
wyrażenia zależności są oceniane. Lista plików może zawierać symbole wieloznaczne, a te
dopasuj nawet pliki, które jeszcze nie istnieją, ale które można zbudować (zobacz "Wildcards" w
zasady_makepp).

Jest to nieporęczna składnia, ale jest niezwykle elastyczna, ponieważ zmienna „$(foreach)”
mogą pojawić się w dowolny sposób w wyrażeniu. Po pierwsze, zauważ, że reguły wzorców są w rzeczywistości a
szczególny przypadek zasad foreach; zasada wzoru

%.o: %.c
$(CC) $(CFLAGS) -c $(wejście) -o $(wyjście)

jest dokładnie odpowiednikiem:

$(patsubst %.c, %.o, $(foreach)): $(foreach): foreach *.c
$(CC) $(CFLAGS) -c $(wejście) -o $(wyjście)

(W rzeczywistości jest konwertowany w przybliżeniu na to wewnętrznie).

Jako przykład tego, jak można użyć klauzuli „:foreach”, w której reguła wzorca nie jest
wystarczy, załóżmy, że masz trochę .c pliki zbudowane przy użyciu pewnego rodzaju preprocesora
który przyjmuje jako pliki wejściowe z .k rozbudowa. Chcesz je skompilować .c pliki z
inny zestaw opcji kompilacji niż zwykle .c pliki będące zwykłym źródłem
pliki. Możesz zrobić coś takiego:

# Reguła dla zwykłych plików .c:
%.o: %.c
$(CC) $(CFLAGS) -c $(wejście) -o $(wyjście)

# Reguła tworzenia plików .c z plików .k:
%.c: %.k
$(preprocesor) $(wejście) > $(wyjście)

# Specjalne zasady budowania dla plików .c, które są tworzone z plików .k:
$(foreach:%.k=%.o): $(foreach:%.c=%.k) : foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(wejście) -o $(wyjście)

(Użyto nieco bardziej zwięzłej składni odniesienia do podstawienia zamiast wywołania
"patsubst" jawnie).

Zauważ, że jeśli wszystko, co chcesz zrobić, to zmienić wartość zmiennej ("CFLAGS" w tym)
przypadku) czasami wygodniej jest użyć zmiennych specyficznych dla celu.

Dziedzictwo przyrostek reguły
Aby zapewnić zgodność wsteczną, makepp obsługuje reguły sufiksów w starym stylu.

.przyrostek1.przyrostek2:
działania

odpowiada

%.sufiks2: %.sufiks1
działania

ale o wiele trudniejsze do zapamiętania. (Który przyrostek jest pierwszy?) Zazwyczaj pojawi się reguła
w starszym pliku makefile takim jak ten:

.współ:
$(CC) $(CFLAGS) -c $*.c -o $*.o

co jest dokładnie równoważne

%.o: %.c
$(CC) $(CFLAGS) -c $(wejście) -o $(wyjście)

Sprzeczny reguły
Gdy istnieje więcej niż jeden sposób utworzenia pliku, makepp używa prostej procedury, aby:
określić, której reguły użyć.

· Błędem jest posiadanie sprzecznych, wyraźnych reguł tworzenia pliku.

· Reguły wzorcowe i reguły foreach z symbolami wieloznacznymi nigdy nie zastępują wyraźnych reguł. Zatem
jawne reguły mogą być użyte do określenia wyjątków dla reguł wzorcowych. (Zauważ, że po prostu
użycie klauzuli ":foreach" nie czyni czegoś regułą wzorca. Musi mieć
symbol wieloznaczny (np. „*” lub „?”) jako część nazwy pliku w klauzuli „:foreach”. Jeśli to jest
tylko wyraźna lista plików, traktowana jest jako wyraźna reguła dla każdego z nich
pliki.)

· Gdy sprzeczne reguły wzorców pochodzą z różnych plików makefile, reguły z „bliższego”
makefile przesłaniają reguły z „dalszych” plików makefile. „Bliżej” oznacza, że ​​plik makefile
znajduje się bliżej celu w hierarchii katalogów (tj. nazwa pliku
cel względem katalogu, z którego wykonywany jest plik makefile, jest krótszy). Jeśli to
nie rozróżnia plików makefile, to reguła od pliku makefile, który jest ładowany
używany jest najnowszy.

Oznacza to, że możesz określić regułę wzorca, która dotyczy wszystkich plików w twoim
całe drzewo katalogów tylko w pliku makefile najwyższego poziomu, ale możesz je zastąpić w
plik makefile niższego poziomu. Na przykład plik makefile najwyższego poziomu może zawierać:

%.o: %.c: foreach **/*.c
$(CC) $(CFLAGS) -c $(wejście) -o $(wyjście)

i możesz mieć plik makefile w jednym z podkatalogów, który mówi:

%.o: %.c
$(CC) $(SPECIAL_CFLAGS) -c $(wejście) -o $(wyjście)

· Reguły wzorców, które mają krótszy łańcuch wnioskowania, są preferowane w stosunku do innych wzorców
zasady. Na przykład, jeśli miałeś następujące zasady (na podstawie przykładu z
Jądro Linuksa):

%.s: %.c
$(CC) -s $(wejście) -o $(wyjście)

%.o: %.s
$(AS) $(wejście) -o $(wyjście)

%.o: %.c
$(CC) -c $(wejście) -o $(wyjście)

Jeśli musimy zbudować „xyz.o”, możemy albo zbudować pośredni plik „.s”, a następnie
przeprowadź to przez asembler, używając dwóch pierwszych reguł, lub możemy przejść bezpośrednio do a
plik ".o" przy użyciu ostatniej reguły. Preferowana jest ostatnia zasada, ponieważ jest ich mniej
kroki w łańcuchu wnioskowania (jeden zamiast dwóch).

· Reguły wzorców później w pliku makefile przesłaniają reguły wzorców, które są wcześniejsze. (To jest
wstecz od GNU make.) Oznacza to, że powinieneś umieścić swoje bardziej ogólne zasady
wcześniej, a bardziej szczegółowe zasady później. Na przykład,

%.o: %.c # Ogólna reguła kompilacji.
akcja

special_%.o: special_%.c # Specjalna reguła dla plików z
inna akcja # prefiks "specjalny_".

Zasada Opcje
Czasami konieczne jest dostarczenie dodatkowych opcji, aby zmodyfikować sposób, w jaki makepp wykonuje
reguła. Te opcje są określone jako ":optionname value", albo w wierszu zawierającym
zależności lub w następnym wierszu.

Podanie opcji w osobnych liniach może umożliwić korzystanie z tego samego
makefile z makepp i tradycyjnym make. Na przykład,

cel : zależności
: podpis docelowy_nowszy
działania

będzie działać dobrze z tradycyjnymi markami uniksowymi, ponieważ interpretuje linię „: Signature”
jako polecenie powłoki, a polecenie rozpoczynające się od dwukropka nic nie robi.

:buduj_cache /ścieżka/do/budowania/pamięci podręcznej
cel : zależności
: build_cache /put/cache/files/over/tam
działania

Określa ścieżkę do pamięci podręcznej kompilacji, która ma być używana dla plików utworzonych przez tę regułę. Ten
zastępuje efekt instrukcji „build_cache” lub polecenia „--build-cache”
opcja linii, jeśli istnieje, dla tej reguły. Zobacz makepp_build_cache, aby uzyskać szczegółowe informacje na temat budowania
pamięci podręczne.

Jeśli podasz „brak” zamiast ścieżki, wyłączysz w tym celu pamięć podręczną kompilacji
szczególna zasada. Może to być przydatne, aby uniknąć marnowania miejsca na dysku na pliki, które
wiem, że nie są przydatne do buforowania, ponieważ jesteś pewien, że nigdy nie będą
ponownie użyte lub dlatego, że są zbudowane tak szybko, że nie warto ich buforować.

:sprawdzanie_kompilacji metoda_sprawdzania_konstrukcji
cel : zależności
: build_check target_newer
działania

To mówi makepp, jakiego algorytmu użyć, aby zdecydować, czy cele wymagają przebudowy.
Zobacz makepp_build_check, aby uzyskać więcej informacji. Zastępuje to efekt
Instrukcja „build_check” lub opcja wiersza poleceń „--build-check-method”, jeśli istnieje, dla
ta reguła.

:środowisko ZMIENNA ...
Dodaj zależność od wartości nazwanych zmiennych środowiskowych. Jeśli któryś z nich
różnią się od poprzedniej kompilacji, cele są uważane za nieaktualne, jeśli
tak nakazuje metoda build_check. (Wszystkie wbudowane metody sprawdzania kompilacji z wyjątkiem
target_newer uszanuj to.)

ZMIENNA może mieć postać „nazwa pliku w PATH_VARIABLE” (w cudzysłowie), w takim przypadku
cele są uważane za nieaktualne, jeśli pierwszy katalog od rozdzielany dwukropkiem
wartość PATH_VARIABLE, w której istnieje nazwa pliku, jest inna niż w ostatniej kompilacji.
Można tego użyć, aby uniknąć odbudowy celów, gdy PATH_VARIABLE zmienia się w
nieistotny sposób.

:załatwić komenda ...
Ujmij każdą akcję powłoki (ale nie akcje Perla ani polecenia Perla) w "sh -c '...'"
i poprzedź go poleceniem, ale załóż, że cel nie zależy od polecenia.
Jest to przydatne, jeśli chcesz wysłać akcje do systemu kolejkowania zadań, ale rezultatem jest
zakłada się, że jest niezależna od parametrów kolejkowania, a także od tego, czy kolejkowanie
system jest w ogóle używany.

:włączać plik_lub_wzór
Reguła różni się w zależności od kompilatora:

%.o: %.c
: dołącz %.d : podpis C
gcc -MD -c ...

%.o: %.c
: include %.u : podpis C # IBM używa innego przyrostka
xlc -M -c ...

sub dependify { # Zmień pogawędkę Microsoftu w użyteczny format
s/\$/\$\$/g;
s/(Uwaga: w tym plik: *)?(.+?)\r?\n/$1 ? "'$2' " : "'".f_output()."': "/e;
}
%.o: %.c
: dołącz %.d : podpis C
cl -show Zawiera -c ... >$(rdzeń).d
&sed &dependify -o +<$(rdzeń).d

Niektóre kompilatory (Intel icc, podobnie jak gcc powyżej lub IBM xlc) mogą generować zależność
pliki w locie. Oznacza to, że podczas kompilacji piszą plik makefile, który makepp może
włączać. Zaletą nad skanerem makepp jest to, że gwarantuje 100%
poprawne, gdzie możemy się tylko zbliżyć.

Ta opcja wykorzystuje to w specjalny sposób: Jeśli plik nie istnieje, tj
zwykle przy pierwszej kompilacji następuje normalne skanowanie. Ale jeśli plik jest obecny, nie
następuje skanowanie (dlatego podajemy powyżej inteligentny podpis -- skanowanie nie spada
z powrotem do głupich domyślnych znaczników czasu i rozmiaru). Zamiast tego zawiera plik, przed
wykonanie reguły. Po pomyślnym wykonaniu reguły zapomina o wszystkim
przeczytaj po raz pierwszy, biorąc pod uwagę, że plik mógł być nieaktualny. Zamiast tego czyta
plik ponownie, jeśli się zmienił, aby mieć aktualne informacje o kompilacji.

OSTRZEŻENIE: Jest to z natury niewiarygodne. Plik zależności jest wytwarzany przez bardzo
reguła, dla której jest to zależność. Z drugiej strony kompilator wie o wszystkim
to wewnętrzne elementy podrzędne, które makepp zwykle ignoruje. To jest niezawodność
korzyść tylko w przypadku, gdy poprawka kompilatora naprawia tylko elementy podrzędne. ten
cena jest taka, że ​​makepp przegląda znacznie więcej plików, co wymaga czasu.

Jest pewien haczyk, gdy usuniesz stwierdzenie „#include” i odpowiedni plik:
Będzie on nadal wymieniony w pliku zależności z ostatniego razu, kiedy był
potrzebne. W takim przypadku musisz edytować plik zależności, aby usunąć zależność
co nie jest już możliwe do spełnienia.

Tej funkcji nie można używać z pamięcią podręczną kompilacji, ponieważ pobieram stamtąd plik
wymaga wiedzy o pliku. Ale plik zależności zależy od nich
pliki, o których makepp uczy się czytając je. Taka cykliczna zależność nie jest normalnie
możliwe w niezawodnym systemie kompilacji. To wyjątek, ponieważ po przebudowie
i ponowne odczytanie pliku zależności wszystko jest w porządku.

Jeśli wbudujesz swoje repozytoria, makepp pobierze plik zależności z
Pierwsze repozytorium, które je zawiera. To różni się od innych plików, w których zajmuje 1.
z oczekiwanym podpisem. Jest to lepsze niż w przypadku budowania pamięci podręcznych, gdzie z braku
podpis, nie może nawet znaleźć pliku.

:Ostatnia szansa
Włącz regułę otwartą, taką jak

%.foo foo%.bar: :ostatnia_szansa
&echo $@ -o $@
&cp $(wyjścia)

Ponieważ reguła taka jak ta może generować zasadniczo nieskończoną liczbę celów,
cel tej reguły nie będzie pasował do funkcji $(wildcard) lub reguły wzorca, chyba że
coś innego już zainicjowało regułę, odwołując się konkretnie do celu.
Co więcej, jeśli podano "--rm-stale", to cel pozostały z poprzedniego
makepp run będzie wyglądał na przestarzały, jeśli jedynym sposobem na jego zbudowanie jest użycie reguły ostatniej szansy
który nie został jeszcze użyty dla celu, co jest pożądanym zachowaniem, ponieważ
kompilacja będzie kończyć się niepowodzeniem bardziej konsekwentnie, gdy błędnie opiera się na symbolu wieloznacznym, aby
dopasuj cele z poprzedniego biegu.

Opcja ":last_chance" ma na celu zwrócenie uwagi na specjalne zachowanie
reguła w odniesieniu do pasujących symboli wieloznacznych.

:parser parser
To mówi makepp, jak przeanalizować polecenie do wykrywania (include) plików. Zwykle,
makepp zgaduje, jak to zrobić na podstawie słów w samym poleceniu (zobacz
makepp_scanning, aby uzyskać szczegółowe informacje). Jeśli jednak makepp odgadnie źle, możesz chcieć
wyraźnie wskaż parser, w ten sposób:

%.o: %.abc
: parser c_kompilacja
akcja tutaj

Powoduje to, że makepp wykonuje to samo parsowanie i skanowanie, co w przypadku C/C++
polecenia kompilacji, nawet jeśli nie rozpoznaje akcji jako kompilacji C.

Domyślny parser zależy od polecenia. Jeśli nie określisz opcji ":parser",
następnie sprawdzane jest pierwsze słowo każdego polecenia. Na przykład dla kompilacji lub linku
polecenie, makepp użyje parsera "c_compilation"; lub jeśli polecenie wygląda tak:
Wariant GNU, „gcc_compilation”. Jeśli nie zostanie znaleziony żaden parser, używa parsera „none”. Do
więcej szczegółów na ten temat, lub jeśli chcesz napisać własny parser lub zmienić makepp
domyślne parsery, zobacz makepp_scanning.

Zauważ, że dotyczy to każdego polecenia w regule, które może nie być tym, czego chcesz:

%.o: %.c : parser c-kompilacja
@echo 'Budynek $(wyjście)'
@zabawne_c...

To również zinterpretuje „echo” jako kompilator i wydedukuje jego argument „Budowanie”
mymodule.o' jako niejawna zależność. Doprowadzi to do skargi, że to
nie wie, jak zbudować taki plik. W takim przypadku lepiej byłoby z
„parser_rejestru”. Tam znajdziesz wyjaśnienie jak parser można podać jako a
nazwa klasy lub jako nazwa funkcji.

:podpis podpis_metoda
cel : zależności
: podpis md5
działania

To mówi makepp, jakiego algorytmu użyć do określenia, czy zależności uległy zmianie.
Zobacz makepp_signatures, aby uzyskać więcej informacji. Metody podpisu zawarte w
dystrybucje makepp to „zwykły”, „md5”, „C” lub „c_compilation_md5”, a
„udostępniony_obiekt”. Zastępuje to każdą metodę podpisu określoną przez "-m" lub
Opcje wiersza poleceń „--signature-method” lub z instrukcją „signature”.

Specjalny znaków
Makepp może obsługiwać nazwy plików zawierające znaki specjalne, takie jak dwukropek lub spacja.
Załóżmy na przykład, że chcesz utworzyć plik o nazwie „a:thing” z pliku „b:thing”.
Nie możesz napisać reguły w ten sposób:

a: rzecz : b: rzecz # To jest błąd składni
&cat $(wejście) -o $(wyjście)

ponieważ makepp nie będzie wiedział, które dwukropki oddzielają cele od zależności, a które są
część nazw plików. Zamiast tego po prostu umieść nazwę w cudzysłowie, w ten sposób:

"a:rzecz" : "b:rzecz"
&cat $(wejście) -o $(wyjście)

Teraz zasada jest jednoznaczna.

Składnia cytowania Makeppa jest bardzo podobna do składni powłoki. Możesz na przykład użyć pojedynczego
cudzysłowy zamiast podwójnych cudzysłowów lub możesz zmienić znaki specjalne za pomocą odwrotnego ukośnika:

a\:rzecz : 'b:rzecz'
&cat $(wejście) -o $(wyjście)

Załóżmy na przykład, że nazwa twojego pliku to „”!;\$”. Teraz dlaczego chcesz mieć taką nazwę pliku
Nie wiem, ale oto kilka sposobów na określenie go w makepp (i powłoce):

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

Zwróć uwagę, kiedy makepp usuwa cudzysłowy, a kiedy robi to powłoka. Makepp patrzy na
cytaty tylko w następujących przypadkach:

· w rodzinie testów „ifeq”

· przed i po regule dwukropek

· we wbudowanym poleceniu makepp

· w funkcji dotyczącej plików

W przeciwieństwie do powłoki, makepp nie rozszerza cudzysłowów podczas przypisywania ich do zmiennej. Zatem
następujące zasady są identyczne:

PLIK = 'nazwa ze spacjami'
x := $(print $(FILE)) # tylko po to, by sprawdzić, czy cudzysłowy nadal tam są
$(FILE): # cudzysłowy wokół pojedynczego pliku usuniętego przez makepp
&echo hello -o$(PLIK) # cudzysłowy wokół pojedynczego pliku usuniętego przez makepp
echo tam >>$(PLIK) # cudzysłowy wokół pojedynczego pliku usuniętego przez powłokę
„nazwa ze spacjami”:
&echo cześć -o'imię ze spacjami'
echo there >>'$(wyjście)' # cytaty zostały usunięte powyżej, dodaj je ponownie

Zauważ, że (w przeciwieństwie do powłoki) zmienne zaczynające się od "$" są rozwijane nawet wewnątrz pojedynczego
cytaty. Znaki dolara nie mogą być chronione cudzysłowami ani ukośnikami odwrotnymi. Aby uzyskać dosłowne
znak dolara, użyj podwójnego znaku dolara, np.

$(fałszywi wszystko):
@&echo To jest znak dolara: $$
@for val w abcd; wykonaj echo $$val; Gotowe

Ogólnie rzecz biorąc, powinieneś być w stanie poradzić sobie z niemal każdym znakiem specjalnym, cytując go
w pewnym sensie. Obejmuje to spacje, znaki sterujące itp. Należy jednak pamiętać, że w
obecny, usuwanie komentarzy makepp jest nieco uproszczone, a wszelkie znaki „#”
poprzedzone spacją będą interpretowane jako komentarze bez względu na to, jak są cytowane.

Kiedy nazwa celu lub zależności jest umieszczana w zmiennej automatycznej, takiej jak „$(wyjście)”, wtedy
cudzysłowy i wszelkie odwrotne ukośniki są usuwane. Oznacza to, że jeśli chcesz odwołać się do
nazwę pliku w akcjach, prawdopodobnie będziesz musiał zacytować go ponownie, w ten sposób:

"nazwa pliku ze spacjami":
echo „Treści specjalne” > „$@”

Jeśli nie umieścisz cudzysłowów wokół $@, powłoka zobaczy polecenie

echo "Zawartość specjalna" > nazwa pliku ze spacjami

który zapisuje ciąg "Nazwa pliku z zawartością specjalną ze spacjami" do pliku o nazwie a.
To prawdopodobnie nie jest to, czego chcesz.

Korzystaj z makepp_rules online za pomocą usług onworks.net