makepp_rules - Online în cloud

PROGRAM:

NUME

makepp_rules -- Cum să îi spui lui makepp să construiască ceva

DESCRIERE

?: &,
-,
@, B: :build_cache,
:build_check, D: :expediere, E: :env, I: "ignore_error",
:include, L: :ultima sansa, M: Makeperl, N: "noecho", P: :parser,
"perl", S: :semnătură

O regulă este ceea ce spune makepp cum să construiască un fișier sau o clasă de fișiere. Makepp acceptă
aceeași sintaxă a regulilor ca și alte implementări ale make, plus unele completări proprii.

O regulă are formatul general

target_expression : dependency_expression [ : argumente opționale]
acțiuni

Lista țintelor nu poate conține variabile automate (cu excepția „$(foreach)”). The
Lista de dependențe poate conține doar variabile automate care se referă la țintă (de exemplu,
„$(ieșire)”, „$(ieșiri)”, sau sinonimele acestora). Acțiunea poate conține orice automată
variabile.

Dacă makepp decide că regula trebuie executată, fiecare linie a regulii este executată
secvenţial, iar dacă oricare returnează o stare diferită de zero, restul nu sunt executate (şi
makepp se anulează cu o eroare dacă nu ați specificat opțiunea „-k” pe linia de comandă.)
Fiecare acțiune ar trebui să aibă o singură linie. Dacă o acțiune este prea lungă pentru a fi scrisă convenabil pe a
o singură linie, o puteți împărți în mai multe linii și puteți pune o bară oblică inversă pentru a indica faptul că
mai multe linii ar trebui combinate într-una singură.

Pentru a distinge acțiunile de următoarea regulă, acțiunea ar trebui să fie indentată mai mult
decât linia care conține țintele și dependențele. Spre deosebire de alte implementări ale
make, makepp nu prea îi pasă cât de mult îl indentați sau dacă folosiți caractere de tabulatură
mai degrabă decât spații. Pentru a păstra compatibilitatea cu produsele tradiționale, regulile
makepp folosește pentru a decide când se termină acțiunile și începe următoarea regulă sunt oarecum complicate:

· Prima linie de acțiune trebuie să fie indentată mai mult decât linia care conține ținta.

· Dacă o linie este indentată cu un caracter tabulator sau 8 spații sau mai mult, atunci este luată în considerare
o linie de acțiune.

· O linie goală sau o linie de comentariu cu caracterul „#” în marginea dreaptă se termină
regulă, cu excepția cazului în care următoarea linie neblankă este indentată mai mult de 8 spații (sau mai mult de unul
filă).

· Dacă o linie este indentată la fel de mult sau mai mult decât prima linie de acțiune, atunci este
considerată o linie de acţiune suplimentară.

Există câteva elemente speciale de acțiune:

& Acest simbol va fi urmat de un nume de comandă și orice număr de argumente. Coajă
sintaxa nu este înțeleasă pe deplin aici, doar ghilimele simple și duble și cu bară oblică inversă
personajele din interior, ca și în întreaga makepp. Numele comenzii fie duce la o funcție
"c_Nume" pentru a fi apelat cu șirurile rămase drept argumente. Dacă o astfel de funcție poate
nu poate fi găsit, aceasta este identică cu apelarea „run” dintr-un bloc „perl”.

Acest lucru permite apelarea eficientă a unei comenzi încorporate, furnizate de makefile sau externe.
Prefixul „&” a fost ales pentru că este invocatorul funcției în Perl și pentru că
la început este ilegal în Shell.

$(ROOT)/include/%.h: %.h
&ln $(intrare) $(ieșire)

noecho
@ În mod normal, fiecare comandă shell este tipărită pe măsură ce este executată. Cu toate acestea, dacă primul cuvânt
a acțiunii este „noecho” (sau dacă începe cu caracterul „@”), atunci comanda
nu este tipărită. De exemplu,

%.o: %.cxx
noecho $(LIBTOOL) --mode=compilare $(CC) -c $(intrare)

Aceasta înseamnă că atunci când comanda libtool este executată, aceasta nu este tipărită. (Libtool
însuși, de obicei, imprimă comanda modificată pe care o execută, deci este redundantă
tipăriți-l de două ori.)

ignore_error
- În mod normal, dacă comanda shell returnează o stare diferită de zero, atunci makepp anulează deoarece
comanda a eșuat. Cu toate acestea, unele programe setează incorect starea la ieșire sau
poate exista o eroare care într-adevăr nu este fatală și nu ar trebui să anuleze întregul
compilare. Puteți determina makepp să ignore starea de returnare specificând
„ignore_error” ca prim cuvânt al liniei de comandă (sau „-” ca prim caracter).
De exemplu,

$(distribuție falsă):
ignore_error rm -r my_program-$(VERSION) # Scapa de nedoriturile anterioare.
&mkdir programul_meu-$(VERSIUNE)
&cp $(FILES) my_program-$(VERSION)
tar cf my_program-$(VERSION).tar my_program-$(VERSION)

Această comandă face un director, copiază o grămadă de fișiere în el și apoi pune
totul într-un fișier tar pentru distribuire. Este o idee bună să curățați
conținutul anterior al directorului, dacă a existat ceva acolo anterior și asta este
ce face prima linie. „rm” ar putea eșua, dar starea sa de returnare este ignorată.

perl
makeperl
Aceasta este în esență aceeași cu instrucțiunea perl, dar este efectuată de fiecare dată când
rulează regula, nu când citești makefile. Prima variantă este Perl simplu
cod, în timp ce a doua variantă trece mai întâi declarația prin variabila Make-style
expansiune.

Pentru cele două posibilități de a pune bretele corpului, vezi explicația la
„perl_perlcode” în makepp_statements. Rețineți că a treia variantă este explicată acolo
nu are sens aici, deoarece toate liniile de acțiune trebuie să fie indentate. Trebuie să semnalezi
eșec în instrucțiunile Perl, prin numirea „die”.

În funcție de regulă, instrucțiunile Perl sunt evaluate în prezent într-un subproces comun, cu excepția on
Windows. Asta înseamnă că au doar acces de citire la orice variabile makefile. Este, de asemenea
procesul care execută acțiuni non-Perl. Deci, apelarea exec sau exit va deruta
makepp. Dar acest lucru se poate schimba în viitor. Pentru o modalitate eficientă de a apela Perl
scripturi, vedeți articolul anterior „&” sau „run”.

$(versiunea falsă):
noecho perl {{ # $(țintă) și $(VERSIUNE) din Perl:
print "Acesta este ".f_target()." $VERSIUNE\n";
}}
echo Puteți combina acest lucru cu comenzile Shell
-makeperl { print "Acesta este $(țintă) $(VERSIUNE)\n" }

Există mai multe tipuri diferite de reguli, fiecare cu scopuri diferite.

Explicit Reguli
target1 target2: dependency1 dependency2 ...
acțiunile de efectuat

Această sintaxă specifică că pentru a face fie tinta1 or tinta2, toate fișierele
dependenta1, dependenta2, etc., trebuie să fi fost deja făcute. Atunci acțiunile date sunt
executat de shell pentru a face ținte.

Prima regulă explicită dintr-un fișier este ținta implicită și este făcută dacă nu specificați
orice ținte de pe linia de comandă.

Spre deosebire de programele tradiționale make, makepp presupune de obicei că o invocare a acțiunii
face toate țintele (cu excepția cazului în care nu există dependențe). De exemplu, o invocare
of yacc creează ambele fișiere de ieșire pentru această regulă:

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

Rețineți că alte implementări ale make nu au conceptul unei singure comenzi
producând mai multe fișiere de ieșire, așa că atunci când specificați mai multe ținte, o vor face
executați regula o dată pe țintă. Makepp va reveni la acest comportament dacă arată
acesta este un makefile de stil vechi. Mai exact, va executa regula o dată pe țintă,
în loc de o singură dată în general, dacă toate următoarele sunt adevărate:

· Acțiunea de regulă menționează variabila automată $@. (Sinonimele „$(ieșire)” sau
„$(target)” nu declanșează acest comportament.)

· Acțiunea de regulă nu menționează variabila automată „$(ieșiri)” (sau sinonimul acesteia
„$(ținte)”).

· Aceasta nu este o regulă de tipar și nu există o clauză pentru fiecare.

De exemplu,

toate instalările de testare:
pentru subdir în $(SUBDIRS); face cd $$subdir && $(MAKE) $@; cd ..; Terminat

este un limbaj comun în fișierele make și makepp îl acceptă. (Rețineți că nu ar trebui să utilizați niciodată
make recursiv în orice makefile nou pe care îl scrieți - utilizați instrucțiunea „load_makefile” sau
În schimb, se încarcă implicit makefile.)

Dacă doriți ca aceeași regulă să fie executată o dată pentru fiecare țintă (de exemplu, deoarece țintele
au comenzi similare), este de preferat să folosiți fie o regulă de tipar (vezi mai jos), fie a
clauza „foreach”. De exemplu, dacă cu un program tradițional make ai scrie:

abcd:
fă_ceva pentru a construi $@ > $@

în makepp, probabil că ați dori să o scrieți astfel:

$(foreach) : : foreach abcd
fă_ceva pentru a construi $(ieșire) > $(ieșire)

Fals obiective

A fals ţintă este o țintă care nu va exista niciodată în sistemul de fișiere; este doar o
modalitate de a face makepp să construiască niște ținte și, eventual, să execute niște comenzi suplimentare.

O țintă falsă tipică este „toate”, care de obicei este folosită pentru a provoca tot ceea ce poate fi
construit pentru a fi construit, astfel:

toate: prog1 prog2 subdir/prog3 subdir2/libmine.a
@&echo "Totul este gata!"

Dacă tastați „makepp all” sau dacă puneți all ca primă țintă explicită în makefile
(ceea ce este tipic) și doar tastați „makepp”, atunci va face ca toate dependențele să fie
construit, apoi va tipări „Totul gata!”. În acest moment, makepp va căuta fișierul ./toate
și va descoperi că nu există. Se va plânge cu voce tare.

Pentru a împiedica makepp să aștepte fișierul ./toate pentru a ieși, trebuie să-i spui că este a
țintă falsă. Doar puneți o linie ca următoarea în fișierul dvs. make (nu are nicio diferență
Unde):

.FONICE: toate

O alternativă echivalentă care este uneori mai convenabilă este să folosiți „$(phony )”
functie, asa:

$(foane toate): prog1 prog2 subdir/prog3 subdir2/libmine.a

Țintele false dintr-un fișier make se pot referi la ținte false dintr-un alt fișier make. Aceasta este
des făcut cu ținta „curată”, astfel:

# Makefile de nivel superior:
# o mulțime de reguli și chestii aici
# ....
$(curățare falsă): subdir1/clean subdir2/clean
&rm -fm programul_meu

Apoi, în subdirectoare, makefile-urile ar putea citi astfel:

# Makefile într-un subdirector
#...
$(curat fals):
&rm -fm $(caracter metalic *.o *.a)

Dar în zilele noastre ai folosi comanda „makeppclean”, în loc de o țintă curată.

metacaractere

Este sigur să specificați wildcards în lista de dependențe. Wildcard-urile se potrivesc nu numai cu fișierele
care există, dar fișiere care pot fi create având în vedere regulile din makefile. De exemplu,
pentru a construi o bibliotecă din toate fișierele .o dintr-un director, puteți scrie asta:

libmine.a: *.o
&rm -f $(ieșire)
ar cr $(ieșire) $(intriri)

Acest lucru va funcționa chiar dacă niciunul dintre fișierele „.o” nu a fost încă creat, deoarece makepp’s
metacaracterele se potrivesc cu fișiere care nu există încă, dar care pot fi construite. Acest lucru chiar va relua
fișiere a căror regulă este descoperită mai târziu (în același makefile sau unul necitit încă). In acest
ultimul punct diferă de funcția „wildcard”, care este limitată la regulile cunoscute,
deoarece trebuie să-și returneze rezultatul atunci când este extins.

Makepp acceptă toate metacaracterele obișnuite de shell ("*", "?" și "[]"). Are si o
wildcard „**” care se potrivește cu orice număr de directoare intervenite. (Această idee a fost furată
de la zsh.) De exemplu, „**/*.c” se potrivește cu toate .c fișiere din întreg arborele sursă.
„obiecte/**/*.o” se potrivește cu toate .o fișierele conținute oriunde în subdirector obiecte
sau oricare dintre subdirectoarele sale sau oricare dintre subdirectoarele acestora. Caracterul „**” nu va fi
urmați link-uri soft către directoare la orice nivel. De asemenea, nu va returna niciodată ținte false.

Caracterele de tipul Makepp vor ignora fișierele sau directoarele care există, dar care nu pot fi citite. După
toate, astfel de fișiere nu pot fi folosite oricum în procesul de construire. Punerea fișierelor care nu pot fi citite într-un
directorul este util în primul rând pentru a inhiba importul automat al fișierului dat din a
repertoriu.

Afirmația inițială a fost că acest lucru este sigur. Aceasta este în sensul că funcționează dacă
fișierele există deja sau trebuie construite mai întâi. Cu toate acestea, este nesigur în propoziție
că se va potrivi în continuare cu fișierele care au fost create de makepp, dar nu mai au o regulă (de ex
ai eliminat .c dosar, dar .o fișierul este încă acolo.) Pentru a preveni acest lucru, utilizați
Opțiunea „--rm-stale”.

Model norme
O regulă de tipar este o regulă care este aplicată pe baza unui model textual. Aceasta este obișnuită
aplică aceeași regulă unei întregi clase de fișiere. Sintaxa este aceeași cu cea a lui GNU
reguli de tipar:

%.o: %.c
$(CC) -c $(intrare) -o $(ieșire)

Aceasta spune că orice fișier din directorul curent care se potrivește cu „*.c” poate fi convertit în
fișierul .o corespunzător folosind comanda dată.

Rețineți că pot fi furnizate mai multe dependențe de model. De exemplu, dacă dvs xyz.o fişier
depinde de corespunzătoare xyz.cpp fișier și, de asemenea, pe un fișier numit moc_xyz.cflags care
conține opțiunile compilatorului, aceasta ar putea fi exprimată cu:

%.o: %.cpp %.cflags
$(CXX) `cat $(stem).cflags` -c $(intrări) -o $(ieșire)

Este posibil să aveți, de asemenea, mai multe ținte de tipar. De exemplu,

%.tab.h %.tab.c : %.a
yacc -d $(input)
&mv y.tab.h $(stem).tab.h
&mv y.tab.c $(stem).tab.c

De obicei, regulile de tipar caută numai fișierele din directoarele curente. Poți forța
ei să caute în directorul curent și în toate directoarele de sub acesta prin setare

makepp_percent_subdirs := 1

înainte de prima regulă de model din makefile sau pe linia de comandă, de exemplu.

Există o diferență clară între „%” și wildcard „*”, deși ambele se potrivesc cu oricare
șir: wildcardul returnează o listă de fișiere care este complet utilizată în acel moment. Asa de
asta depinde de toate .o fișiere care se pot construi aici:

prog: *.o
$(LD) $(LDFLAGS) $(intrări) -o $(ieșire)

Acest lucru nu a putut fi realizat prin înlocuirea „*” cu „%”, deoarece acesta din urmă este pentru unul câte unul
potrivirea intrării cu ieșirea, producând intern o regulă pentru fiecare tulpină potrivită.

Static model norme
O regulă de model static este o regulă de model care se aplică numai unui set limitat de fișiere:

$(SPECIAL_MODULES).o : %.o : %.cpp
$(CXX) -c $(intrare) -o $(ieșire)

Aceasta spune că regula modelului se aplică numai fișierelor din „$(SPECIAL_MODULES).o”.

Acest lucru este mai ales pentru compatibilitatea cu GNU make; regulile foreach (a se vedea mai jos) sunt mai multe
mod puternic de a face același lucru.

Pentru fiecare norme
Sintaxa regulilor de model de mai sus este suficient de puternică pentru a suporta aproape toate versiunile, dar
ocazional este necesar să facem ceva mai complicat. Makepp oferă mai mult
sintaxă puternică: clauza „:foreach” pentru regulă.

target_expression : dependency_expression : pentru fiecare listă de fișiere
acțiuni

Cel mai simplu tip de regulă pentru fiecare este doar o regulă tip model a cărei aplicare este restricționată
la o listă specifică de fișiere. De exemplu, să presupunem că aveți o regulă de tipar care spune
makepp cum să compilați toate .c fișiere. Cu toate acestea, aveți o listă de .c fișierele pentru care dvs
vrei să faci ceva diferit. Ai putea face ceva de genul asta:

# Iată regula care se aplică tuturor:
%.o : %.c
$(CC) $(CFLAGS) -c $(intrare) -o $(ieșire)

%.o : %.c : foreach $(SPECIAL_MODULES)
$(CC) $(SPECIAL_CFLAGS) -c $(intrare) -o $(ieșire)

O utilizare și mai puternică a regulilor foreach profită de faptul că variabila
„$(foreach)” este setat pe rând pentru fiecare fișier care se potrivește cu lista de fișiere și cu ținta și
sunt evaluate expresiile de dependență. Lista de fișiere poate conține metacaractere și acestea
potrivește chiar și fișierele care nu există încă, dar care pot fi construite (consultați „Caratele metalice” în
makepp_rules).

Aceasta este o sintaxă grea, dar este extrem de flexibilă, deoarece variabila „$(foreach)”.
poate apărea în orice fel în expresie. În primul rând, rețineți că regulile tiparului sunt de fapt a
caz special al regulilor foreach; regula tiparului

%.o : %.c
$(CC) $(CFLAGS) -c $(intrare) -o $(ieșire)

este exact echivalent cu:

$(patsubst %.c, %.o, $(foreach)): $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(intrare) -o $(ieșire)

(De fapt, este convertit în aproximativ aceea în interior.)

Ca exemplu despre cum ați folosi o clauză „:foreach” în cazul în care o regulă de tipar nu este
suficient, să presupunem că ai ceva .c fișiere care sunt construite folosind un fel de preprocesor
care ia ca fișiere de intrare cu a .k extensie. Vrei să le compilați .c fișiere cu a
set diferit de opțiuni de compilare decât cel obișnuit .c fișiere care sunt surse obișnuite
fișiere. Ai putea face ceva de genul asta:

# Regulă pentru fișierele .c obișnuite:
%.o : %.c
$(CC) $(CFLAGS) -c $(intrare) -o $(ieșire)

# Regulă pentru a face fișiere .c din fișiere .k:
%.c: %.k
$(preprocesor) $(intrare) > $(ieșire)

# Reguli speciale de construire pentru fișierele .c care sunt făcute din fișiere .k:
$(foreach:%.k=%.o) : $(foreach:%.c=%.k) : foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(intrare) -o $(ieșire)

(Acest lucru folosește sintaxa de referință de substituție puțin mai concisă, mai degrabă decât apelarea
„patsubst” în mod explicit.)

Rețineți că, dacă tot ceea ce doriți să faceți este să schimbați valoarea unei variabile ("CFLAGS" în aceasta
caz) uneori este mai convenabil să folosiți variabile specifice țintei.

Moştenire sufix norme
Pentru compatibilitate inversă, makepp acceptă regulile de sufix în stil vechi.

.sufix1.sufix2:
acțiuni

este echivalent cu

%.sufix2: %.sufix1
acțiuni

dar mult mai greu de reținut. (Care sufix este primul?) De obicei, va apărea o regulă
într-un makefile moștenit ca acesta:

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

care este exact echivalent cu

%.o : %.c
$(CC) $(CFLAGS) -c $(intrare) -o $(ieșire)

În conflict norme
Când există mai multe moduri de a crea un fișier, makepp folosește o procedură simplă pentru a
stabiliți ce regulă să utilizați.

· Este o eroare să existe reguli explicite conflictuale pentru construirea unui fișier.

· Regulile de tipar și regulile foreach cu caractere metalice nu înlocuiesc niciodată regulile explicite. Prin urmare
regulile explicite pot fi folosite pentru a specifica excepții pentru regulile de tipar. (Rețineți că pur și simplu
folosirea unei clauze „:foreach” nu face din ceva o regulă de tipar. Trebuie să aibă o
wildcard (cum ar fi „*” sau „?”) ca parte a numelui fișierului din clauza „:foreach”. Dacă este
doar o listă explicită de fișiere, este tratată ca o regulă explicită pentru fiecare dintre acestea
fișiere.)

· Când regulile de model conflictuale provin din diferite makefiles, regulile de la „mai aproape”
makefiles anulează regulile de la "mai departe" makefiles. „Mai aproape” înseamnă că fișierul make
este situat mai aproape de țintă în ierarhia directoarelor (adică, numele fișierului
ținta în raport cu directorul din care rulează makefile este mai scurtă). Dacă aceasta
nu distinge fișierele make, apoi regula de fișierul make care este încărcat
cel mai recent este folosit.

Aceasta înseamnă că puteți specifica o regulă de model care se aplică tuturor fișierelor din dvs
întregul arbore de directoare doar în fișierul makefile de nivel superior, dar apoi îl puteți suprascrie în
un makefile de nivel inferior. De exemplu, makefile de nivel superior ar putea conține:

%.o : %.c : foreach **/*.c
$(CC) $(CFLAGS) -c $(intrare) -o $(ieșire)

și ați putea avea un makefile într-unul dintre subdirectoarele care spune:

%.o : %.c
$(CC) $(SPECIAL_CFLAGS) -c $(intrare) -o $(ieșire)

· Regulile de tipar care au un lanț de inferență mai scurt sunt preferate față de alte modele
reguli. De exemplu, dacă ați avut următoarele reguli (pe baza unui exemplu din
Nucleul Linux):

%.s: %.c
$(CC) -s $(intrare) -o $(ieșire)

%.o: %.s
$(AS) $(intrare) -o $(ieșire)

%.o: %.c
$(CC) -c $(intrare) -o $(ieșire)

Dacă trebuie să construim „xyz.o”, am putea fie să construim fișierul intermediar „.s” și apoi
rulați asta prin asamblator folosind primele două reguli, sau am putea merge direct la a
Fișierul „.o” folosind ultima regulă. Ultima regulă este de preferat pentru că sunt mai puține
pași în lanțul de inferență (unul în loc de doi).

· Regulile de tipar mai târziu într-un makefile înlocuiesc regulile de model care sunt anterioare. (Aceasta este
înapoi de la GNU make.) Aceasta înseamnă că ar trebui să vă puneți regulile mai generale
mai devreme, iar regulile dvs. mai specifice mai târziu. De exemplu,

%.o: %.c # Regula generală de compilare.
acțiune

special_%.o: special_%.c # Regulă specială pentru fișierele cu a
acțiune diferită # prefix „special_”.

Regula Opțiuni
Uneori este necesar să furnizați opțiuni suplimentare pentru a modifica modul în care makepp execută
regulă. Aceste opțiuni sunt specificate ca „:optionname value”, fie pe linia care conține
dependențe sau pe linia următoare.

Furnizarea opțiunilor pe linii separate vă poate face posibil să le utilizați
makefile cu makepp și o marca tradițională. De exemplu,

țintă: dependențe
: semnătură target_newer
acțiuni

va funcționa bine cu o marcă tradițională Unix, deoarece interpretează linia „: semnătură”.
ca o comandă shell, iar o comandă care începe cu două puncte nu face nimic.

:build_cache /cale/la/build/cache
țintă: dependențe
: build_cache /put/cache/files/over/there
acțiuni

Specifică calea către un cache de compilare care va fi utilizat pentru fișierele produse de această regulă. Acest
suprascrie efectul instrucțiunii „build_cache” sau al comenzii „--build-cache”.
opțiune de linie, dacă există, pentru această regulă. Consultați makepp_build_cache pentru detalii despre build
cache-urile.

Dacă specificați „niciunul” în loc de o cale, dezactivați memoria cache de compilare pentru aceasta
regula speciala. Acest lucru poate fi util pentru a evita pierderea spațiului pe disc pe fișierele pe care le aveți
Știu că nu sunt utile pentru cache, fie pentru că ești foarte sigur că nu vor fi niciodată
reutilizate sau pentru că sunt construite atât de repede încât nu merită să le păstrați în cache.

:build_check build_check_method
țintă: dependențe
: build_check target_newer
acțiuni

Acest lucru îi spune lui makepp ce algoritm să folosească pentru a decide dacă țintele trebuie reconstruite.
Consultați makepp_build_check pentru mai multe detalii. Aceasta anulează efectul
Declarația „build_check” sau opțiunea de linie de comandă „--build-check-method”, dacă există, pentru
această regulă.

:env VARIABIL ...
Adăugați o dependență de valorile variabilelor de mediu numite. Dacă vreuna dintre ele
diferă de versiunea anterioară, atunci țintele sunt considerate învechite, dacă
metoda build_check așa dictează. (Toate metodele de verificare a construcției încorporate, cu excepția
target_newer respect asta.)

VARIABLE poate avea forma „nume fișier în PATH_VARIABLE” (între ghilimele), caz în care
țintele sunt considerate învechite dacă primul director delimitat de două puncte
valoarea PATH_VARIABLE în care există numele fișierului este diferită de ultima versiune.
Acest lucru poate fi folosit pentru a evita reconstruirea țintelor atunci când PATH_VARIABLE se modifică într-un
mod irelevant.

:expediere comandă ...
Închideți fiecare acțiune shell (dar nu acțiunile Perl sau comenzile Perl) într-un „sh -c '...'”
și prefixați-o cu comandă, dar să presupunem că ținta nu depinde de comandă.
Acest lucru este util dacă doriți să trimiteți acțiuni către un sistem de așteptare a joburilor, dar rezultatul este
presupusă a fi independentă de parametrii de așteptare, precum și de starea de așteptare
sistemul este folosit deloc.

:include fișier_sau_model
Regula variază în funcție de compilator:

%.o : %.c
: include %.d : semnătura C
gcc -MD -c ...

%.o : %.c
: include %.u : semnătura C # IBM folosește un sufix diferit
xlc -M -c...

sub dependify { # Transformă conversația Microsoft într-un format util
s/\$/\$\$/g;
s/(Notă: inclusiv fișierul: *)?(.+?)\r?\n/$1 ? "'$2' ": "'".f_output()."': "/e;
}
%.o : %.c
: include %.d : semnătura C
cl -showInclude -c ... >$(stem).d
&sed &depende -o +<$(stem).d

Unele compilatoare (icc-ul Intel la fel ca gcc de mai sus sau xlc-ul IBM) pot produce dependențe
fișiere din mers. Adică, în timp ce compilează, ei scriu un makefile pe care makepp îl poate
include. Avantajul față de scanerul makepp este că este garantat 100%
corect, unde ne putem apropia doar.

Această opțiune valorifică într-un mod special: Dacă fișierul nu este prezent, de exemplu
de obicei, la prima versiune, are loc scanarea normală. Dar dacă dosarul este prezent, nu
are loc scanarea (de aceea specificăm o semnătură inteligentă mai sus -- nu cade scanarea
înapoi la valoarea implicită stupidă de marcaj de timp și dimensiune). În schimb, include fișierul, înainte
executarea regulii. După ce a executat cu succes regula, uită orice ar fi
citit prima dată, având în vedere că fișierul ar fi putut fi depășit. În schimb se citește
fișierul din nou, dacă s-a schimbat, pentru a avea informații actualizate de construcție.

AVERTISMENT: Acest lucru este în mod inerent nesigur. Fișierul de dependență este produs de foarte
regula pentru care este dependenta. Pe de altă parte, compilatorul știe despre toate
este sub-include interne, pe care makepp le ignoră de obicei. Aceasta este o fiabilitate
avantaj numai pentru cazul în care un patch al compilatorului fixează doar sub-includele. The
prețul este că makepp ajunge să se uite la mai multe fișiere, ceea ce necesită timp.

Există o problemă când eliminați o declarație „#include”. și fisierul corespunzator:
Va fi menționat în continuare în fișierul de dependență de ultima dată, când a fost
Necesar. Într-un astfel de caz, trebuie să editați fișierul de dependență pentru a elimina dependența
care nu mai este indeplinita.

Această caracteristică nu poate fi utilizată cu un cache de compilare, deoarece preia un fișier de acolo
necesită știi totul despre fișier. Dar un fișier de dependență depinde de acestea
fișierele despre care makepp învață citindu-l. O astfel de dependență circulară nu este în mod normal
posibil într-un sistem de construcție fiabil. Aceasta este o excepție deoarece după reconstrucție
și recitind un fișier de dependență totul este corect din nou.

Dacă construiți în depozitele dvs., makepp va prelua fișierul de dependență din
Primul depozit care conține unul. Acesta este spre deosebire de alte fișiere, unde este nevoie de primul
cu semnătura aşteptată. Acest lucru este mai bun decât pentru construirea cache-urilor, unde din lipsă
semnătură, nici nu găsește fișierul.

:ultima sansa
Activați o regulă deschisă, cum ar fi

%.foo foo%.bar: :last_chance
&echo $@ -o $@
&cp $(ieșiri)

Deoarece o astfel de regulă ar putea genera un număr esențial infinit de ținte,
o țintă a acestei reguli nu se va potrivi cu o funcție $(wildcard) sau cu o regulă de tipar decât dacă
altceva a instaurat deja regula făcând referire în mod specific la țintă.
În plus, dacă este specificat „--rm-stale”, atunci o țintă rămasă dintr-o țintă anterioară
rularea makepp va apărea învechită dacă singura modalitate de a o crea este printr-o regulă de ultima șansă
care nu a fost încă prezentat pentru țintă, ceea ce este un comportament dezirabil deoarece
build-ul va eșua mai consecvent atunci când se bazează în mod eronat pe un wildcard la
potriviți ținte dintr-o rundă anterioară.

Opțiunea „:last_chance” este menită să atragă atenția asupra comportamentului special al
regulă cu privire la potrivirea wildcards.

:parser analizor
Aceasta îi spune lui makepp cum să analizeze comanda pentru detectarea (includerea) fișierelor. De obicei,
makepp ghicește cum să facă acest lucru pe baza cuvintelor din comanda în sine (vezi
makepp_scanning pentru detalii). Cu toate acestea, dacă makepp ghicește greșit, poate doriți
indicați în mod explicit analizatorul, astfel:

%.o: %.abc
: parser c_compilation
acțiune aici

Acest lucru face ca makepp să efectueze aceeași analiză și scanare ca și pentru C/C++
build comenzi, chiar dacă nu recunoaște acțiunea ca o compilație C.

Analizatorul implicit depinde de comandă. Dacă nu specificați o opțiune „:parser”,
apoi se examinează primul cuvânt al fiecărei comenzi. De exemplu, pentru o compilare sau o legătură
comanda, makepp va folosi parserul „c_compilation”; sau dacă comanda arată ca
Varianta GNU, „gcc_compilation”. Dacă nu se găsește niciun analizator, folosește analizatorul „niciun”. Pentru
mai multe detalii despre asta sau dacă doriți să vă scrieți propriul parser sau să schimbați makepp-urile
analizoare implicite, vezi makepp_scanning.

Rețineți că acest lucru se aplică fiecărei comenzi din regulă, care poate să nu fie ceea ce doriți:

%.o: %.c: parser c-compilation
@echo „Clădire $(ieșire)”
@funny_cc...

Acest lucru va interpreta, de asemenea, „echo” ca un compilator și va deduce argumentul său „Clădire
mymodule.o' ca o dependenţă implicită. Acest lucru va duce la plângerea că acesta
nu știe cum să construiască un astfel de fișier. În acest caz, ți-ar fi mai bine
„register_parser”. Acolo gasesti o explicatie cum analizor poate fi dat fie ca a
classname sau ca nume de funcție.

:semnătură semnătură_method
țintă: dependențe
: semnatura md5
acțiuni

Aceasta îi spune lui makepp ce algoritm să folosească pentru a determina dacă dependențele s-au schimbat.
Consultați makepp_signatures pentru mai multe detalii. Metode de semnătură care sunt incluse cu
Distribuțiile makepp sunt „plain”, „md5”, „C” sau „c_compilation_md5” și
„obiect_partajat”. Aceasta anulează orice metodă de semnătură specificată cu „-m” sau
Opțiunile din linia de comandă „--signature-method” sau cu instrucțiunea „semnătură”.

Special caractere
Makepp poate suporta nume de fișiere care au caractere speciale, cum ar fi două puncte sau spațiu.
Să presupunem, de exemplu, că doriți să creați un fișier numit „a:thing” din fișierul „b:thing”.
Nu poți scrie regula astfel:

a:thing : b:thing # Aceasta este o eroare de sintaxă
&cat $(intrare) -o $(ieșire)

pentru că makepp nu va ști ce puncte separă ținte de dependențe și care sunt
parte a numelor de fișiere. În schimb, introduceți pur și simplu numele între ghilimele, astfel:

"a:thing": "b:thing"
&cat $(intrare) -o $(ieșire)

Acum regula este lipsită de ambiguitate.

Sintaxa de citare a lui Makepp este destul de asemănătoare cu cea a shell-ului. Puteți, de exemplu, să utilizați single
ghilimele în loc de ghilimele duble sau puteți scăpa de caractere speciale cu o bară oblică inversă:

a\:thing: 'b:thing'
&cat $(intrare) -o $(ieșire)

Să presupunem, de exemplu, că numele tău de fișier este „'"!;\$". Acum de ce ai dori un astfel de nume de fișier
Nu știu, dar iată mai multe moduri în care ați putea specifica acest lucru pentru makepp (și shell):

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

Acordați atenție când makepp scoate ghilimele și când face shell-ul. Makepp se uită la
citează numai în următoarele cazuri:

· în familia de teste „ifeq”.

· înainte și după colonul regulii

· într-o comandă încorporată makepp

· într-o funcție care se referă la fișiere

Spre deosebire de shell, makepp nu extinde ghilimele în timp ce le atribuie unei variabile. Prin urmare
următoarele reguli sunt identice:

FILE = „nume cu spații”
x := $(printează $(FIȘIER)) # doar pentru a verifica dacă ghilimele sunt încă acolo
$(FILE): # ghilimele în jurul unui singur fișier eliminate de makepp
&echo salut -o$(FIȘIER) # ghilimele în jurul unui singur fișier eliminat de makepp
ecou acolo >>$(FIȘIER) # ghilimele în jurul unui singur fișier eliminat de Shell
„nume cu spații”:
&echo salut -o'nume cu spatii'
echo there >>'$(output)' # ghilimele au fost eliminate mai sus, adăugați-le din nou

Rețineți că (spre deosebire de Shell) variabilele care încep cu „$” sunt extinse chiar și în interiorul single
citate. Semnele dolarului nu pot fi protejate prin ghilimele sau barele oblice inverse. Pentru a obține un literal
semn dolar, utilizați un semn dublu dolar, de exemplu,

$(fals toate):
@&echo Acesta este un semn de dolar: $$
@for val in abcd; do echo $$val; Terminat

În general, ar trebui să puteți face față aproape oricărui personaj special citându-l
într-un fel. Aceasta include spații, caractere de control etc. Cu toate acestea, rețineți că la
prezent, eliminarea comentariilor de la makepp este oarecum simplistă și orice caractere „#”.
precedate de spații albe vor fi interpretate ca comentarii indiferent de modul în care sunt citate.

Când o țintă sau un nume de dependență este introdus într-o variabilă automată precum „$(output)”, atunci
ghilimele și orice bară oblică inversă sunt eliminate. Aceasta înseamnă că, dacă doriți să faceți referire la
nume de fișier în acțiuni, probabil va trebui să-l citați din nou, astfel:

„un nume de fișier cu spații”:
echo „Conținut special” > „$@”

Dacă nu puneți ghilimele în jurul $@, atunci shell-ul va vedea comanda

echo „Conținut special” > un nume de fișier cu spații

care scrie șirul „Nume fișier cu conținut special cu spații” în fișierul numit a.
Probabil că nu este ceea ce îți dorești.

Utilizați makepp_rules online folosind serviciile onworks.net