makepp_rules - Online in de cloud

PROGRAMMA:

NAAM

makepp_rules -- Hoe je makepp vertelt iets te bouwen

PRODUCTBESCHRIJVING

?: &,
-,
@, B: :build_cache,
:build_check, D: :verzenden, E: :env, I: "negeer_fout",
:erbij betrekken, L: :laatste kans, M: makeperl, N: "noecho", P: :parseer,
"perl", S: :handtekening

Een regel vertelt makepp hoe een bestand of een klasse bestanden moet worden opgebouwd. Makepp ondersteunt de
dezelfde regelsyntaxis als andere implementaties van make, plus enkele eigen toevoegingen.

Een regel heeft het algemene formaat

doel_expressie: afhankelijkheid_expressie [: optionele argumenten]
acties

De lijst met doelen mag geen automatische variabelen bevatten (behalve "$(foreach)"). De
afhankelijkheidslijst mag alleen automatische variabelen bevatten die naar het doel verwijzen (dat wil zeggen
"$(output)", "$(outputs)", of hun synoniemen). De actie kan een automatische actie bevatten
variabelen.

Als makepp besluit dat de regel moet worden uitgevoerd, wordt elke regel van de regel uitgevoerd
opeenvolgend, en als een status een niet-nul-status retourneert, wordt de rest niet uitgevoerd (en
makepp wordt afgebroken met een fout, tenzij u de optie "-k" op de opdrachtregel hebt opgegeven.)
Elke actie mag slechts één regel bevatten. Als een actie te lang is om gemakkelijk op a te schrijven
enkele regel, kunt u deze in meerdere regels splitsen en een backslash plaatsen om aan te geven dat de
meerdere regels moeten worden gecombineerd tot één.

Om acties te onderscheiden van de volgende regel, moet de actie meer ingesprongen zijn
dan de regel met de doelen en afhankelijkheden. In tegenstelling tot andere implementaties van
make, het maakt makepp niet zoveel uit hoeveel je het inspringt of dat je tabtekens gebruikt
in plaats van spaties. Om achterwaartse compatibiliteit met traditioneel merk te behouden, zijn de regels
makepp gebruikt om te beslissen wanneer acties eindigen en de volgende regel begint, zijn enigszins ingewikkeld:

· De eerste actielijn moet meer ingesprongen zijn dan de lijn met het doel.

· Als een regel is ingesprongen met één tabteken of acht spaties of meer, wordt deze in aanmerking genomen
een actielijn.

· Een lege regel of een commentaarregel met het teken "#" in de rechtermarge beëindigt de
regel, tenzij de volgende niet-lege regel meer dan 8 spaties inspringt (of meer dan één
tabblad).

· Als een regel evenveel of meer ingesprongen is dan de eerste actieregel, dan is dat ook zo
beschouwd als een extra actielijn.

Er zijn een paar speciale actiepunten:

& Dit symbool wordt gevolgd door een opdrachtnaam en een willekeurig aantal argumenten. Schelp
De syntaxis wordt hier niet volledig begrepen, alleen enkele en dubbele aanhalingstekens en backslashed
karakters binnen, zoals overal in makepp. De opdrachtnaam leidt ofwel naar een functie
"C_naam" die moet worden aangeroepen met de resterende tekenreeksen als argumenten. Als zo'n functie dat kan
niet gevonden worden, is dit identiek aan het aanroepen van "run" vanuit een "perl"-blok.

Hierdoor kunt u op efficiënte wijze een ingebouwde, door een makefile geleverde of externe opdracht aanroepen.
Het voorvoegsel "&" is gekozen omdat dit de functie-aanroeper in Perl is, en omdat
in het begin is het illegaal in Shell.

$(ROOT)/include/%.h: %.h
&ln $(invoer) $(uitvoer)

neecho
@ Normaal gesproken wordt elk shell-commando afgedrukt terwijl het wordt uitgevoerd. Echter, als het eerste woord
van de actie is "noecho" (of als het begint met het teken "@"), dan het commando
wordt niet afgedrukt. Bijvoorbeeld,

%.o: %.cxx
noecho $(LIBTOOL) --mode=compileren $(CC) -c $(invoer)

Dit betekent dat wanneer het libtool-commando wordt uitgevoerd, het niet wordt afgedrukt. (Libtool
zelf drukt meestal de gewijzigde opdracht af die het uitvoert, dus het is overbodig
druk het twee keer af.)

negeer_fout
- Normaal gesproken, als het shell-commando een status anders dan nul retourneert, wordt makepp afgebroken omdat
de opdracht is mislukt. Sommige programma's stellen de status echter verkeerd in bij afsluiten, of
er kan een fout optreden die in werkelijkheid niet fataal is en die het geheel niet mag afbreken
compilatie. U kunt ervoor zorgen dat makepp de retourstatus negeert door op te geven
"ignore_error" als het eerste woord van de opdrachtregel (of "-" als het eerste teken).
Bijvoorbeeld

$(nepdistributie):
negeer_error rm -r my_program-$(VERSION) # Verwijder eerdere rommel.
&mkdir mijn_programma-$(VERSIE)
&cp $(BESTANDEN) mijn_programma-$(VERSIE)
tar cf mijn_programma-$(VERSIE).tar mijn_programma-$(VERSIE)

Deze opdracht maakt een map, kopieert er een aantal bestanden naartoe en plaatst vervolgens
alles in een tar-bestand voor distributie. Het is een goed idee om de boel schoon te maken
vorige inhoud van de map, als er eerder iets was, en dat is
wat de eerste regel doet. De "rm" mislukt mogelijk, maar de retourstatus ervan wordt genegeerd.

perl
maakperl
Dit is in wezen hetzelfde als de perl-instructie, maar wordt elke keer uitgevoerd
het uitvoeren van de regel, niet bij het lezen van het makefile. De eerste variant is gewoon Perl
code, terwijl de tweede variant de instructie eerst doorgeeft via de Make-style-variabele
uitbreiding.

Voor de twee mogelijkheden om de beugels van het lijf te zetten, zie de uitleg op
"perl_perlcode" in makepp_statements. Merk op dat de derde variant daar wordt uitgelegd
heeft hier geen zin, omdat alle actielijnen ingesprongen moeten zijn. Je moet signaleren
falen in Perl-instructies, door "die" aan te roepen.

Per regel worden de Perl-statements momenteel geëvalueerd in een gemeenschappelijk subproces, behalve op
Ramen. Dat betekent dat ze alleen leestoegang hebben tot eventuele makefile-variabelen. Het is ook
het proces dat niet-Perl-acties uitvoert. Dus het bellen van exec of exit zal verwarrend zijn
makepp. Maar dit kan in de toekomst veranderen. Voor een efficiënte manier om Perl aan te roepen
scripts, zie het vorige item "&" of "uitvoeren".

$(nepversie):
noecho perl {{ # $(doel) & $(VERSIE) van Perl:
print "Dit is ".f_target()." $VERSION\n";
}}
echo Je kunt dit combineren met Shell-opdrachten
-makeperl { print "Dit is $(doel) $(VERSIE)\n" }

Er zijn verschillende soorten regels, elk met verschillende doeleinden.

Uitdrukkelijk Reglement
doel1 doel2: afhankelijkheid1 afhankelijkheid2 ...
uit te voeren acties

Deze syntaxis specificeert dat om een ​​van beide te maken target1 or target2, alle bestanden
afhankelijkheid1, afhankelijkheid2, enz., moeten al gemaakt zijn. Dan zijn de gegeven acties
uitgevoerd door de granaat om de doelen te maken.

De eerste expliciete regel in een bestand is het standaarddoel en wordt gemaakt als u dit niet opgeeft
alle doelen op de opdrachtregel.

In tegenstelling tot traditionele make-programma's gaat makepp er meestal van uit dat er sprake is van één aanroep van de actie
maakt alle doelen (tenzij er geen afhankelijkheden zijn). Eén aanroep bijvoorbeeld
van yacc maakt beide uitvoerbestanden voor deze regel:

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

Merk op dat andere implementaties van make geen concept van een enkele opdracht hebben
het produceren van meerdere uitvoerbestanden, en dus als u meerdere doelen opgeeft, zullen ze dat ook doen
voer de regel eenmaal per doel uit. Makepp zal naar dit gedrag terugkeren als het erop lijkt
dit is een makefile in oude stijl. Concreet zal het de regel eenmaal per doel uitvoeren,
in plaats van slechts één keer in totaal, als al het volgende waar is:

· De regelactie vermeldt de automatische variabele $@. (De synoniemen "$(output)" of
'$(target)' activeert dit gedrag niet.)

· De regelactie vermeldt niet de automatische variabele "$(outputs)" (of het synoniem ervan
"$(doelen)").

· Dit is geen patroonregel en er is geen foreach-clausule.

Bijvoorbeeld

alle testinstallaties:
voor submap in $(SUBDIRS); do cd $$subdir && $(MAKE) $@; cd..; klaar

is een veelgebruikt idioom in makefiles, en makepp ondersteunt het. (Merk op dat u dit nooit mag gebruiken
recursieve make in alle nieuwe makefiles die u schrijft - gebruik de instructie "load_makefile", of
in plaats daarvan impliciet makefile laden.)

Als u dezelfde regel één keer voor elk doel wilt laten uitvoeren (bijvoorbeeld omdat de targets
vergelijkbare commando's hebben), verdient het de voorkeur om een ​​patroonregel te gebruiken (zie hieronder) of een
"foreach"-clausule. Als u bijvoorbeeld met een traditioneel make-programma zou schrijven:

abcd:
doe_iets om $@ > $@ te bouwen

in makepp zou je het waarschijnlijk zo willen schrijven:

$(foreach) : : foreach abcd
doe_iets om $(output) > $(output) te bouwen

onecht doelen

A onecht doel is een doel dat nooit daadwerkelijk in het bestandssysteem zal bestaan; het is maar een
manier om makepp enkele doelen te laten bouwen en mogelijk enkele extra opdrachten uit te voeren.

Een typisch nepdoelwit is 'alles', dat meestal wordt gebruikt om alles te veroorzaken wat kan zijn
gebouwd om gebouwd te worden, zoals dit:

alles: prog1 prog2 subdir/prog3 subdir2/libmine.a
@&echo "Alles klaar!"

Als u "makepp all" typt, of als u all als het eerste expliciete doel in uw makefile plaatst
(wat typisch is) en typ gewoon "makepp", dan zullen alle afhankelijkheden worden weergegeven
gebouwd, dan wordt "All done!" afgedrukt. Op dit punt zal makepp naar het bestand zoeken ./alle
en zal ontdekken dat het niet bestaat. Het zal luid klagen.

Om te voorkomen dat makepp het bestand verwacht ./alle om af te sluiten, moet je vertellen dat het een
vals doelwit. Plaats gewoon een regel zoals de volgende in je makefile (het maakt geen verschil
waar):

.PHONY: allemaal

Een gelijkwaardig alternatief dat soms handiger is, is het gebruik van de "$(phony)"
functie, zoals deze:

$(nep alles): prog1 prog2 subdir/prog3 subdir2/libmine.a

Valse doelen in het ene make-bestand kunnen verwijzen naar valse doelen in een ander make-bestand. Dit is
vaak gedaan met het "schone" doel, zoals dit:

# Makefile op het hoogste niveau:
# veel regels en zo hier
# ....
$(nep-schoon): subdir1/schoon submap2/schoon
&rm -fm mijn_programma

In de submappen kunnen de makefiles er dan als volgt uitzien:

# Makefile in een submap
#...
$(nepschoon):
&rm -fm $(wildcard *.o *.a)

Maar tegenwoordig zou je het commando "makeppclean" gebruiken in plaats van een schoon doel.

wildcards

Het is veilig om jokertekens op te geven in de afhankelijkheidslijst. Wildcards komen niet alleen overeen met bestanden
die bestaan, maar bestanden die kunnen worden gemaakt op basis van de regels in het makefile. Bijvoorbeeld,
om een ​​bibliotheek te bouwen van alle .o-bestanden in een map, zou je dit kunnen schrijven:

libmine.a: *.o
&rm -f $(uitvoer)
ar cr $(uitvoer) $(invoer)

Dit werkt zelfs als er nog geen ".o"-bestanden zijn gemaakt, omdat makepp's
jokertekens komen overeen met bestanden die nog niet bestaan, maar wel kunnen worden gebouwd. Dit zal zelfs toenemen
bestanden waarvan de regel later wordt ontdekt (in hetzelfde makefile, of een die nog niet is gelezen). In deze
op het laatste punt verschilt het van de "wildcard"-functie, die beperkt is tot de bekende regels,
omdat het zijn resultaat moet retourneren wanneer het wordt uitgebreid.

Makepp ondersteunt alle gebruikelijke shell-jokertekens ("*", "?" en "[]"). Het heeft ook een
jokerteken "**" dat overeenkomt met een willekeurig aantal tussenliggende mappen. (Dit idee is gestolen
van zsh.) "**/*.c" komt bijvoorbeeld overeen met alle .c bestanden in de gehele bronboom.
"objects/**/*.o" komt overeen met alle .o bestanden die zich overal in de submap bevinden objecten
of een van zijn submappen of een van hun submappen. Het jokerteken "**" zal dat niet doen
volg zachte links naar mappen op elk niveau. Het zal ook nooit valse doelen retourneren.

De jokertekens van Makepp negeren bestanden of mappen die bestaan ​​maar niet kunnen worden gelezen. Na
Dergelijke bestanden kunnen sowieso niet in het bouwproces worden gebruikt. Onleesbare bestanden in een
directory is vooral nuttig om de automatische import van het gegeven bestand uit een
repository.

De eerste bewering was dat dit veilig is. Dit is in de zin dat het werkt
de bestanden bestaan ​​al, of moeten eerst worden gebouwd. In die zin is het echter onveilig
dat het nog steeds bestanden zal matchen die door makepp zijn gebouwd, maar geen regel meer hebben (bijv
jij hebt de verwijderd .c bestand, maar de .o bestand is er nog steeds.) Om dit te voorkomen, gebruikt u de
"--rm-verouderde" optie.

Patronen reglement
Een patroonregel is een regel die wordt toegepast op basis van een tekstueel patroon. Dit is gewend
pas dezelfde regel toe op een hele klasse bestanden. De syntaxis is hetzelfde als die van GNU
patroonregels:

%.o: %.c
$(CC) -c $(invoer) -o $(uitvoer)

Dit zegt dat elk bestand in de huidige map dat overeenkomt met "*.c" kan worden geconverteerd naar
het overeenkomstige .o-bestand met behulp van de gegeven opdracht.

Houd er rekening mee dat er verschillende patroonafhankelijkheden kunnen worden opgegeven. Als uw xyz.o filet
hangt af van het overeenkomstige xyz.cpp bestand, en ook op een bestand genaamd moc_xyz.cflags welke
bevat de compileropties, dit kan worden uitgedrukt met:

%.o: %.cpp %.cflags
$(CXX) `cat $(stem).cflags` -c $(invoer) -o $(uitvoer)

Mogelijk hebt u ook meerdere patroondoelen. Bijvoorbeeld,

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

Normaal gesproken zoeken patroonregels alleen naar bestanden in de huidige mappen. Je kunt forceren
hen om te zoeken in de huidige map en alle mappen eronder door in te stellen

makepp_percent_subdirs := 1

vóór de eerste patroonregel in uw makefile of bijvoorbeeld op de opdrachtregel.

Er is een duidelijk verschil tussen "%" en het jokerteken "*", hoewel beide overeenkomen
string: Het jokerteken retourneert een lijst met bestanden die op dat moment volledig worden gebruikt. Dus
dit hangt van alles af .o bestanden die hier kunnen worden gebouwd:

prog: *.o
$(LD) $(LDFLAGS) $(invoer) -o $(uitvoer)

Dit kon niet worden bereikt door "*" te vervangen door "%", omdat dit laatste één voor één is
het matchen van input met output, waarbij intern één regel voor elke gematchte stam wordt geproduceerd.

Statisch patroon reglement
Een statische patroonregel is een patroonregel die alleen op een beperkte set bestanden wordt toegepast:

$(SPECIAL_MODULES).o: %.o: %.cpp
$(CXX) -c $(invoer) -o $(uitvoer)

Dit zegt dat de patroonregel alleen van toepassing is op de bestanden in "$(SPECIAL_MODULES).o".

Dit is vooral bedoeld voor compatibiliteit met GNU-merken; foreach-regels (zie hieronder) zijn meer
krachtige manier om hetzelfde te doen.

foreach reglement
De bovenstaande patroonregelsyntaxis is krachtig genoeg om bijna alle builds te ondersteunen, maar
af en toe is het nodig om iets ingewikkelders te doen. Makepp biedt meer
krachtige syntaxis: de ":foreach"-clausule voor de regel.

target_expression: dependency_expression: fore elke bestandslijst
acties

De eenvoudigste soort foreach-regel is slechts een patroonregel waarvan de toepassing beperkt is
naar een specifieke lijst met bestanden. Stel dat u bijvoorbeeld een patroonregel heeft die dit aangeeft
makepp hoe je alles compileert .c bestanden. Je hebt echter een lijst met .c bestanden waarvoor u
wil iets anders doen. Je zou zoiets als dit kunnen doen:

# Dit is de regel die op alles van toepassing is:
%.o: %.c
$(CC) $(CFLAGS) -c $(invoer) -o $(uitvoer)

%.o: %.c: foreach $(SPECIAL_MODULES)
$(CC) $(SPECIAL_CFLAGS) -c $(invoer) -o $(uitvoer)

Een nog krachtiger gebruik van foreach-regels maakt gebruik van het feit dat de variabele
"$(foreach)" wordt op zijn beurt ingesteld op elk bestand dat overeenkomt met de bestandslijst en het doel- en
afhankelijkheidsuitdrukkingen worden geëvalueerd. De bestandslijst kan jokertekens bevatten, en deze
match zelfs bestanden die nog niet bestaan ​​maar die wel kunnen worden gebouwd (zie "Wildcards" in
makepp_rules).

Dit is een logge syntaxis, maar uiterst flexibel, omdat de variabele "$(foreach)" aanwezig is
kan op welke manier dan ook in de uitdrukking voorkomen. Merk allereerst op dat patroonregels in feite a zijn
speciaal geval van foreach-regels; de patroonregel

%.o: %.c
$(CC) $(CFLAGS) -c $(invoer) -o $(uitvoer)

is precies gelijk aan:

$(patsubst %.c, %.o, $(foreach)) : $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(invoer) -o $(uitvoer)

(In feite wordt het intern naar ongeveer dat omgezet.)

Als voorbeeld van hoe u een ":foreach"-clausule zou gebruiken waar dat niet het geval is met een patroonregel
voldoende, stel dat je er een paar hebt .c bestanden die zijn gebouwd met behulp van een soort preprocessor
die als invoerbestanden met a .k verlenging. Die wil je compileren .c bestanden met een
andere set compilatie-opties dan gebruikelijk .c bestanden die een gewone bron zijn
bestanden. Je zou zoiets als dit kunnen doen:

# Regel voor gewone .c-bestanden:
%.o: %.c
$(CC) $(CFLAGS) -c $(invoer) -o $(uitvoer)

# Regel om .c-bestanden te maken van .k-bestanden:
%.c : %.k
$(preprocessor) $(invoer) > $(uitvoer)

# Speciale bouwregels voor .c-bestanden die zijn gemaakt van .k-bestanden:
$(foreach:%.k=%.o) : $(foreach:%.c=%.k) : foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(invoer) -o $(uitvoer)

(Hierbij wordt de iets beknoptere syntaxis van de vervangingsreferentie gebruikt in plaats van aanroepen
"patsubst" expliciet.)

Houd er rekening mee dat als u alleen maar de waarde van een variabele wilt wijzigen ("CFLAGS" in deze
geval) is het soms handiger om doelspecifieke variabelen te gebruiken.

Nalatenschap achtervoegsel reglement
Voor achterwaartse compatibiliteit ondersteunt makepp de ouderwetse achtervoegselregels.

.achtervoegsel1.achtervoegsel2:
acties

is gelijk aan

%.achtervoegsel2: %.achtervoegsel1
acties

maar veel moeilijker om te onthouden. (Welk achtervoegsel komt eerst?) Meestal verschijnt er een regel
in een verouderd makefile zoals dit:

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

wat precies gelijk is aan

%.o: %.c
$(CC) $(CFLAGS) -c $(invoer) -o $(uitvoer)

Tegenstrijdig reglement
Als er meer dan één manier is om een ​​bestand te maken, gebruikt makepp een eenvoudige procedure
bepalen welke regel u wilt gebruiken.

· Het is een fout om conflicterende expliciete regels te hebben voor het bouwen van een bestand.

· Patroonregels en foreach-regels met jokertekens overschrijven nooit expliciete regels. Dus
expliciete regels kunnen worden gebruikt om uitzonderingen voor patroonregels te specificeren. (Merk dat eenvoudig op
het gebruik van een ":foreach"-clausule maakt iets niet tot een patroonregel. Het moet een
jokerteken (zoals "*" of "?") als onderdeel van de bestandsnaam in de ":foreach"-clausule. Als het is
het is slechts een expliciete lijst met bestanden; het wordt behandeld als een expliciete regel voor elk van deze bestanden
bestanden.)

· Wanneer conflicterende patroonregels uit verschillende makefiles komen, kunnen regels uit "dichterbij"
makefiles overschrijven de regels van "verdere" makefiles. "Dichter" betekent dat het makefile
bevindt zich dichter bij het doel in de maphiërarchie (dat wil zeggen, de bestandsnaam van het
target relatief ten opzichte van de map van waaruit het makefile wordt uitgevoerd, is korter). Als dit
maakt geen onderscheid tussen de makefiles, dan wordt de regel gescheiden van de makefile die wordt geladen
nieuwste wordt gebruikt.

Dit betekent dat u een patroonregel kunt opgeven die van toepassing is op alle bestanden in uw
volledige directorystructuur in alleen het makefile op het hoogste niveau, maar u kunt deze vervolgens overschrijven
een makefile op een lager niveau. Uw makefile op het hoogste niveau kan bijvoorbeeld het volgende bevatten:

%.o : %.c : foreach **/*.c
$(CC) $(CFLAGS) -c $(invoer) -o $(uitvoer)

en je zou een makefile kunnen hebben in een van de submappen die zegt:

%.o: %.c
$(CC) $(SPECIAL_CFLAGS) -c $(invoer) -o $(uitvoer)

· Patroonregels met een kortere gevolgtrekkingsketen hebben de voorkeur boven andere patronen
reglement. Als u bijvoorbeeld de volgende regels had (gebaseerd op een voorbeeld uit de
Linux-kernel):

%.s: %.c
$(CC) -s $(invoer) -o $(uitvoer)

%.o: %.s
$(AS) $(invoer) -o $(uitvoer)

%.o: %.c
$(CC) -c $(invoer) -o $(uitvoer)

Als we "xyz.o" moeten bouwen, kunnen we het tussenliggende ".s"-bestand bouwen en vervolgens
voer dat door de assembler met behulp van de eerste twee regels, of we kunnen rechtstreeks naar a
".o"-bestand met behulp van de laatste regel. De laatste regel heeft de voorkeur omdat er minder zijn
stappen in de gevolgtrekkingsketen (één in plaats van twee).

· Patroonregels later in een makefile overschrijven patroonregels die eerder zijn. (Dit is
achteruit van GNU make.) Dit betekent dat u uw meer algemene regels moet opstellen
eerder, en uw meer specifieke regels later. Bijvoorbeeld,

%.o: %.c # Algemene compilatieregel.
actie

special_%.o: special_%.c # Speciale regel voor bestanden met a
andere actie # "speciaal_" voorvoegsel.

Regel opties
Soms is het nodig om extra opties aan te bieden om te wijzigen hoe makepp het
regel. Deze opties worden gespecificeerd als ":optionname value", ofwel op de regel met
de afhankelijkheden, of op de volgende regel.

Door de opties op aparte lijnen aan te bieden, kunt u er mogelijk gebruik van maken
makefile met makepp en een traditioneel merk. Bijvoorbeeld,

doel: afhankelijkheden
: handtekening target_newer
acties

zal prima werken met een traditioneel Unix-merk, omdat het de regel ": signature" interpreteert
als een shell-commando, en een commando dat begint met een dubbele punt doet niets.

:build_cache /pad/naar/build/cache
doel: afhankelijkheden
: build_cache /put/cache/files/over/there
acties

Specificeert het pad naar een build-cache die moet worden gebruikt voor bestanden die door deze regel worden geproduceerd. Dit
overschrijft het effect van de instructie "build_cache" of de opdracht "--build-cache".
lijnoptie, indien aanwezig, voor deze regel. Zie makepp_build_cache voor details over build
caches.

Als u in plaats van een pad "none" opgeeft, schakelt u hiervoor de build-cache uit
bepaalde regel. Dit kan handig zijn om te voorkomen dat u schijfruimte verspilt aan bestanden die u gebruikt
weet dat ze niet nuttig zijn om te cachen, ook omdat je er heel zeker van bent dat ze dat nooit zullen zijn
hergebruikt of omdat ze zo snel zijn gebouwd dat het niet de moeite waard is om ze in de cache op te slaan.

:build_check build_check_methode
doel: afhankelijkheden
: build_check target_newer
acties

Dit vertelt makepp welk algoritme moet worden gebruikt om te beslissen of de doelen opnieuw moeten worden opgebouwd.
Zie makepp_build_check voor meer details. Dit overschrijft het effect van de
"build_check"-instructie of de opdrachtregeloptie "--build-check-method", indien aanwezig, voor
deze regel.

:omv VARIABELE ...
Voeg een afhankelijkheid toe van de waarden van de genoemde omgevingsvariabelen. Als een van hen
verschillen van de vorige build, dan worden de doelen als verouderd beschouwd als de
build_check methode dicteert dit. (Alle ingebouwde buildcontrolemethoden behalve
target_newer respecteer dit.)

VARIABLE kan de vorm "bestandsnaam in PATH_VARIABLE" hebben (tussen aanhalingstekens), in welk geval de
doelen worden als verouderd beschouwd als de eerste map uit de dubbele punt wordt gescheiden
waarde van PATH_VARIABLE waarin bestandsnaam bestaat, verschilt van de laatste build.
Dit kan worden gebruikt om te voorkomen dat de doelen opnieuw worden opgebouwd wanneer PATH_VARIABLE verandert in een
irrelevante manier.

:verzenden commando ...
Plaats elke shell-actie (maar niet Perl-acties of Perl-opdrachten) in een "sh -c '...'"
en laat het voorafgaan door commando, maar neem aan dat het doel niet afhankelijk is van commando.
Dit is handig als u acties naar een wachtrijsysteem wilt sturen, maar het resultaat is dat wel
Er wordt aangenomen dat deze onafhankelijk is van de wachtrijparameters, en ook van de vraag of de wachtrij plaatsvindt
systeem überhaupt wordt gebruikt.

:erbij betrekken bestand_of_patroon
Regel varieert afhankelijk van compiler:

%.o: %.c
: inclusief %.d : handtekening C
gcc -MD -c ...

%.o: %.c
: include %.u : handtekening C # IBM gebruikt een ander achtervoegsel
xlc-M-c ...

sub dependify { # Zet het gebabbel van Microsoft om in een bruikbaar formaat
s/\$/\$\$/g;
s/(Let op: inclusief bestand: *)?(.+?)\r?\n/$1 ? "'$2' " : "'".f_output()."': "/e;
}
%.o: %.c
: inclusief %.d : handtekening C
cl -showIncludes -c ... >$(stem).d
&sed &dependify -o +<$(stem).d

Sommige compilers (Intel's icc, net als gcc hierboven, of IBM's xlc) kunnen afhankelijkheid produceren
bestanden in een handomdraai. Dat wil zeggen, terwijl ze compileren, schrijven ze een makefile die makepp kan maken
erbij betrekken. Het voordeel ten opzichte van de scanner van Makepp is dat deze gegarandeerd 100% betrouwbaar is.
correct, waar we misschien maar in de buurt komen.

Deze optie maakt daar op een speciale manier gebruik van: als het bestand niet aanwezig is, dat wil zeggen
Normaal gesproken vindt tijdens de eerste build normaal scannen plaats. Maar als het bestand aanwezig is, nee
er wordt gescand (daarom specificeren we hierboven een slimme handtekening - scannen valt niet).
terug naar de domme standaard van tijdstempel en grootte). In plaats daarvan bevat het het bestand before
het uitvoeren van de regel. Nadat de regel met succes is uitgevoerd, vergeet het programma wat het ook is
de eerste keer lezen, aangezien het bestand mogelijk verouderd is. In plaats daarvan leest het
het bestand opnieuw, als het is gewijzigd, zodat u over actuele build-informatie beschikt.

WAARSCHUWING: Dit is inherent onbetrouwbaar. Het afhankelijkheidsbestand wordt geproduceerd door de very
regel waarvan het een afhankelijkheid is. Aan de andere kant weet de compiler alles
het zijn interne sub-includes, die makepp meestal negeert. Dit is een betrouwbaarheid
alleen voordeel voor het geval waarin een compilerpatch alleen de sub-includes repareert. De
De prijs is dat makepp uiteindelijk naar veel meer bestanden moet kijken, wat tijd kost.

Er zit een probleem wanneer u een "#include"-instructie verwijdert en het bijbehorende bestand:
Het zal nog steeds vermeld worden in het afhankelijkheidsbestand van de laatste keer dat dit het geval was
nodig zijn. In een dergelijk geval moet u het afhankelijkheidsbestand bewerken om de afhankelijkheid te verwijderen
die niet meer te vervullen is.

Deze functie kan niet worden gebruikt met een build-cache omdat daar een bestand wordt opgehaald
vereist dat u alles over het bestand weet. Maar een afhankelijkheidsbestand is daarvan afhankelijk
bestanden waar makepp meer over leert door het te lezen. Een dergelijke circulaire afhankelijkheid is normaal gesproken niet het geval
mogelijk in een betrouwbaar bouwsysteem. Dit is een uitzondering want na herbouw
en het opnieuw lezen van een afhankelijkheidsbestand is alles weer correct.

Als u uw repository's inbouwt, haalt makepp het afhankelijkheidsbestand op uit de
1e repository die er één bevat. Dit is anders dan bij andere bestanden, waarbij de 1e
met de verwachte handtekening. Dit is beter dan voor build-caches, waar bij gebrek aan
handtekening, het kan het bestand niet eens vinden.

:laatste kans
Schakel een regel met een open einde in, zoals

%.foo foo%.bar: :last_chance
&echo $@ -o $@
&cp $(uitvoer)

Omdat een regel als deze een feitelijk oneindig aantal doelen zou kunnen genereren,
een doel van deze regel komt niet overeen met een functie- of patroonregel $(wildcard), tenzij
iets anders heeft de regel al toegepast door specifiek naar het doel te verwijzen.
Als bovendien "--rm-stale" is opgegeven, is er een doel overgebleven van een vorig doel
makepp run zal verouderd lijken als de enige manier om het te bouwen via een last_chance-regel is
dat nog niet voor het doel is uitgevoerd, wat een wenselijk gedrag is omdat
de build zal consistenter mislukken als deze ten onrechte op een jokerteken vertrouwt
overeenkomen met doelen uit een vorige run.

De optie ":last_chance" is bedoeld om de aandacht te vestigen op het speciale gedrag van de
regel met betrekking tot het matchen van jokertekens.

:parser parser
Dit vertelt makepp hoe het commando voor het detecteren (include) van bestanden moet worden geparseerd. Gebruikelijk,
makepp raadt hoe dit moet gebeuren op basis van de woorden in het commando zelf (zie
makepp_scanning voor details). Als makepp echter verkeerd gokt, wil je dat misschien wel doen
geef expliciet de parser aan, zoals deze:

%.o: %.abc
: parser c_compilation
actie hier

Dit zorgt ervoor dat makepp hetzelfde parseren en scannen uitvoert als voor C/C++
build-opdrachten, zelfs als de actie niet als een C-compilatie wordt herkend.

De standaardparser is afhankelijk van de opdracht. Als u geen ":parser"-optie opgeeft,
vervolgens wordt het eerste woord van elk commando onderzocht. Bijvoorbeeld voor een compilatie of koppeling
commando, makepp zal de "c_compilation" parser gebruiken; of als de opdracht lijkt op de
GNU-variant, "gcc_compilation". Als er geen parser wordt gevonden, wordt de parser "geen" gebruikt. Voor
meer details hierover, of als u uw eigen parser wilt schrijven of makepp's wilt wijzigen
standaardparsers, zie makepp_scanning.

Houd er rekening mee dat dit van toepassing is op elke opdracht in de regel, wat mogelijk niet is wat u wilt:

%.o: %.c: parser c-compilatie
@echo '$(output) bouwen'
@grappig_cc ...

Dit zal "echo" ook interpreteren als een compiler en het argument 'Building' afleiden
mymodule.o' als een impliciete afhankelijkheid. Dit zal leiden tot de klacht dat dit het geval is
weet niet hoe je zo'n bestand moet bouwen. In dit geval ben je beter af met
"register_parser". Daar vind je uitleg hoe parser kan worden gegeven als een
klassenaam of als functienaam.

:handtekening handtekening_methode
doel: afhankelijkheden
: handtekening md5
acties

Dit vertelt makepp welk algoritme moet worden gebruikt om te bepalen of de afhankelijkheden zijn veranderd.
Zie makepp_signatures voor meer details. Handtekeningmethoden die zijn opgenomen in de
makepp-distributie zijn "plain", "md5", "C" of "c_compilation_md5", en
"gedeeld_object". Dit overschrijft elke handtekeningmethode die is opgegeven met de "-m" of
"--signature-method" opdrachtregelopties, of met de instructie "signature".

special tekens
Makepp kan bestandsnamen ondersteunen die speciale tekens bevatten, zoals een dubbele punt of een spatie.
Stel dat u bijvoorbeeld een bestand met de naam "a:thing" wilt maken uit het bestand "b:thing".
Je kunt de regel niet op deze manier schrijven:

a:thing : b:thing # Dit is een syntaxisfout
&cat $(invoer) -o $(uitvoer)

omdat makepp niet weet welke dubbele punten doelen scheiden van afhankelijkheden en welke
een deel van de bestandsnamen. Plaats in plaats daarvan eenvoudigweg de naam tussen aanhalingstekens, zoals deze:

"a:ding" : "b:ding"
&cat $(invoer) -o $(uitvoer)

Nu is de regel ondubbelzinnig.

De syntaxis van Makepp voor aanhalingstekens lijkt veel op die van de shell. Je kunt bijvoorbeeld single gebruiken
aanhalingstekens in plaats van dubbele aanhalingstekens, of u kunt speciale tekens vermijden met een backslash:

a\:ding : 'b:ding'
&cat $(invoer) -o $(uitvoer)

Stel bijvoorbeeld dat uw bestandsnaam "'"!;\$" is. Waarom zou u nu zo'n bestandsnaam willen?
Ik weet het niet, maar hier zijn verschillende manieren waarop je het aan makepp (en de shell) kunt specificeren:

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

Let op wanneer makepp aanhalingstekens verwijdert en wanneer de shell dat doet. Makepp kijkt
citeert alleen in de volgende gevallen:

· in de "ifeq"-testfamilie

· voor en na de regeldubbelpunt

· in een ingebouwde makepp-opdracht

· in een functie die betrekking heeft op bestanden

In tegenstelling tot de shell, vouwt makepp de aanhalingstekens niet uit terwijl ze aan een variabele worden toegewezen. Dus
de volgende regels zijn identiek:

FILE = 'naam met spaties'
x := $(print $(FILE)) # om te controleren of de aanhalingstekens er nog steeds zijn
$(FILE): # aanhalingstekens rond één bestand verwijderd door makepp
&echo hallo -o$(FILE) # aanhalingstekens rond een enkel bestand verwijderd door makepp
echo daar >>$(FILE) # aanhalingstekens rond één bestand verwijderd door Shell
'naam met spaties':
&echo hallo -o'naam met spaties'
echo daar >>'$(output)' # aanhalingstekens zijn hierboven verwijderd, voeg ze opnieuw toe

Merk op dat (in tegenstelling tot de Shell) variabelen die beginnen met "$", zelfs binnen single worden uitgebreid
citaten. Dollartekens kunnen niet worden beschermd door aanhalingstekens of backslashes. Om een ​​letterlijke te krijgen
dollarteken, gebruik een dubbel dollarteken, bijvoorbeeld

$(nep alles):
@&echo Dit is een dollarteken: $$
@voor val in abcd; echo $$val; klaar

Over het algemeen zou je met vrijwel elk speciaal teken moeten kunnen omgaan door het te citeren
in zekere zin. Dit geldt ook voor spaties, controletekens, etc. Houd er echter rekening mee dat at
aanwezig is, is het verwijderen van commentaar door Makepp enigszins simplistisch, en alle "#"-tekens
voorafgegaan door witruimte wordt geïnterpreteerd als commentaar, ongeacht hoe deze wordt geciteerd.

Wanneer een doel- of afhankelijkheidsnaam in een automatische variabele zoals "$(output)" wordt geplaatst, dan
de aanhalingstekens en eventuele backslashes worden verwijderd. Dit betekent dat als u wilt verwijzen naar de
bestandsnaam in de acties, zult u deze waarschijnlijk opnieuw moeten citeren, zoals dit:

"een bestandsnaam met spaties":
echo "Speciale inhoud" > "$@"

Als je de aanhalingstekens niet rond $@ plaatst, zal de shell het commando zien

echo "Speciale inhoud" > een bestandsnaam met spaties

die de string "Bestandsnaam speciale inhoud met spaties" naar het aangeroepen bestand schrijft a.
Dit is waarschijnlijk niet wat je wilt.

Gebruik makepp_rules online met behulp van onworks.net-services