makepp_rules - Online nel cloud

PROGRAMMA:

NOME

makepp_rules -- come dire a makepp di creare qualcosa

DESCRIZIONE

?: &,
-,
@, B: :build_cache,
:build_check, D: :spedizione, E: :env, I: "ignora_errore",
:includere, L: :ultima possibilità, M: trucco, N: "noeco", P: :analizzatore,
"perla", S: :firma

Una regola è ciò che dice a makepp come creare un file o una classe di file. Makepp supporta il
stessa sintassi delle regole di altre implementazioni di make, più alcune aggiunte proprie.

Una regola ha il formato generale

espressione_obiettivo: espressione_dipendenza [: argomenti opzionali]
azioni

L'elenco dei target non può contenere variabili automatiche (tranne "$(foreach)"). Il
l'elenco delle dipendenze può contenere solo variabili automatiche riferite al target (cioè,
"$(output)", "$(output)" o i loro sinonimi). L'azione può contenere qualsiasi automatico
variabili.

Se makepp decide che la regola deve essere eseguita, viene eseguita ogni riga della regola
sequenzialmente, e se any restituisce uno stato diverso da zero, il resto non viene eseguito (e
makepp si interrompe con un errore a meno che tu non abbia specificato l'opzione "-k" sulla riga di comando.)
Ogni azione dovrebbe essere solo una riga. Se un'azione è troppo lunga per essere scritta comodamente su a
singola riga, puoi dividerla in più righe e inserire una barra rovesciata per indicare che il
più righe dovrebbero essere combinate in una.

Per distinguere le azioni dalla regola successiva, l'azione dovrebbe essere rientrata di più
rispetto alla riga contenente le destinazioni e le dipendenze. A differenza di altre implementazioni di
make, a makepp non interessa davvero quanto lo fai rientrare o se usi i caratteri di tabulazione
piuttosto che spazi. Per mantenere la retrocompatibilità con le marche tradizionali, le regole
makepp usa per decidere quando le azioni finiscono e inizia la regola successiva sono alquanto complicate:

· La prima riga di azione deve essere rientrata più della riga che contiene l'obiettivo.

· Se una riga è rientrata di un carattere di tabulazione o di 8 spazi o più, viene considerata
una linea d'azione

· Una riga vuota o una riga di commento con il carattere "#" al margine destro termina il
regola, a meno che la riga successiva non vuota non sia rientrata di più di 8 spazi (o più di uno
scheda).

· Se una riga è rientrata tanto o più della prima riga di azione, allora lo è
considerata una linea d'azione aggiuntiva.

Ci sono alcune azioni speciali:

& Questo simbolo deve essere seguito da un nome di comando e da un numero qualsiasi di argomenti. Guscio
la sintassi non è compresa completamente qui, solo virgolette singole e doppie e barra rovesciata
personaggi all'interno, come in tutto makepp. Il nome del comando porta a una funzione
"C_nome" da chiamare con le stringhe rimanenti come argomenti. Se tale funzione può
non essere trovato, questo è identico a chiamare "run" da un blocco "perl".

Ciò consente di chiamare in modo efficiente un comando integrato, fornito da makefile o esterno.
Il prefisso "&" è stato scelto perché è l'invocatore di funzioni in Perl e perché
all'inizio è illegale in Shell.

$(ROOT)/include/%.h: %.h
&ln $(ingresso) $(uscita)

noeco
@ Normalmente, ogni comando della shell viene stampato mentre viene eseguito. Tuttavia, se la prima parola
dell'azione è "noecho" (o se inizia con il carattere "@"), quindi il comando
non viene stampato. Per esempio,

%.o: %.cxx
noecho $(LIBTOOL) --mode=compila $(CC) -c $(input)

Ciò significa che quando viene eseguito il comando libtool, non viene stampato. (Libtool
stesso di solito stampa il comando modificato che esegue, quindi è ridondante
stampalo due volte.)

ignora_errore
- Normalmente, se il comando shell restituisce uno stato diverso da zero, makepp si interrompe perché
il comando non è riuscito. Tuttavia, alcuni programmi impostano erroneamente lo stato all'uscita, oppure
potrebbe esserci un errore che in realtà non è fatale e non dovrebbe interrompere il tutto
compilazione. Puoi fare in modo che makepp ignori lo stato di ritorno specificando
"ignore_error" come prima parola della riga di comando (o "-" come primo carattere).
Per esempio,

$(distribuzione fasulla):
ignore_error rm -r mio_programma-$(VERSION) # Elimina la spazzatura precedente.
&mkdir mio_programma-$(VERSIONE)
&cp $(FILES) mio_programma-$(VERSIONE)
tar cf mio_programma-$(VERSIONE).tar mio_programma-$(VERSIONE)

Questo comando crea una directory, copia un mucchio di file in essa e poi mette
tutto in un file tar per la distribuzione. È una buona idea pulire il
contenuto precedente della directory, se c'era qualcosa in precedenza, e questo è
cosa fa la prima riga. Il "rm" potrebbe non riuscire, ma il suo stato di ritorno viene ignorato.

perl
makeperl
Questo è essenzialmente lo stesso dell'istruzione perl, ma viene eseguito ogni volta che
eseguendo la regola, non durante la lettura del makefile. La prima variante è semplice Perl
codice, mentre la seconda variante passa prima l'istruzione attraverso la variabile Make-style
espansione.

Per le due possibilità di mettere le bretelle del corpo, vedere la spiegazione a
"perl_perlcode" in makepp_statements. Nota che la terza variante è spiegata lì
non ha senso qui, perché tutte le linee di azione devono essere rientrate. Devi segnalare
fallimento nelle istruzioni Perl, chiamando "die".

Per regola le istruzioni Perl sono attualmente valutate in un sottoprocesso comune, tranne on
Finestre. Ciò significa che hanno solo accesso in lettura a qualsiasi variabile di makefile. È altresì
il processo che esegue azioni non Perl. Quindi chiamare exec o exit confonderà
makepp. Ma questo potrebbe cambiare in futuro. Per chiamare in modo efficiente Perl
script, vedere l'elemento precedente "&" o "esegui".

$(versione fasulla):
noecho perl {{ # $(destinazione) & $(VERSIONE) da Perl:
print "Questo è ".f_target()." $VERSION\n";
}}
echo Puoi mescolarlo con i comandi Shell
-makeperl { print "Questo è $(target) $(VERSIONE)\n" }

Esistono diversi tipi di regole, ognuna con scopi diversi.

Esplicito Regole
target1 target2: dipendenza1 dipendenza2 ...
azioni da compiere

Questa sintassi specifica che per rendere sia target1 or target2, tutti i file
dipendenza1, dipendenza2, ecc., devono essere già stati effettuati. Allora le azioni date sono
eseguito dalla shell per creare i bersagli.

La prima regola esplicita in un file è la destinazione predefinita e viene creata se non si specifica
qualsiasi obiettivo sulla riga di comando.

A differenza dei tradizionali programmi make, makepp di solito presuppone che un'unica invocazione dell'azione
crea tutti i target (a meno che non ci siano dipendenze). Ad esempio, un'invocazione
di yacc crea entrambi i file di output per questa regola:

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

Nota che altre implementazioni di make non hanno il concetto di un singolo comando
producendo più file di output, quindi quando si specificano più obiettivi, lo faranno
eseguire la regola una volta per target. Makepp tornerà a questo comportamento se sembra
questo è un makefile vecchio stile. Nello specifico, eseguirà la regola una volta per target,
invece di una sola volta nel complesso, se sono vere tutte le seguenti condizioni:

· L'azione della regola menziona la variabile automatica $@. (I sinonimi "$(output)" o
"$(target)" non attiva questo comportamento.)

· L'azione della regola non menziona la variabile automatica "$(outputs)" (o il suo sinonimo
"$(obiettivi)").

· Questa non è una regola del modello e non esiste una clausola foreach.

Per esempio,

tutti i test installano:
per sottodirectory in $(SUBDIRS); do cd $$sottodirectory && $(MAKE) $@; cd ..; fatto

è un linguaggio comune nei makefile e makepp lo supporta. (Nota che non dovresti mai usare
make ricorsivo in ogni nuovo makefile che scrivi: usa l'istruzione "load_makefile", oppure
caricamento implicito del makefile invece.)

Se vuoi che la stessa regola venga eseguita una volta per ogni target (ad esempio, perché i target
hanno comandi simili), è preferibile utilizzare una regola modello (vedi sotto) o a
clausola "foro". Ad esempio, se con un programma make tradizionale dovessi scrivere:

abcd:
fai_qualcosa per costruire $@ > $@

in makepp, probabilmente vorrai scriverlo in questo modo:

$(foreach) : : foreach abcd
fai_qualcosa per costruire $(output) > $(output)

falso obiettivi

A falso bersaglio è un obiettivo che non esisterà mai effettivamente nel file system; è solo un
modo per fare in modo che makepp costruisca alcuni target ed eventualmente esegua alcuni comandi aggiuntivi.

Un tipico bersaglio fasullo è "tutto", che di solito viene utilizzato per causare tutto ciò che può essere
costruito per essere costruito, in questo modo:

tutto: prog1 prog2 sottodir/prog3 sottodir2/libmine.a
@&echo "Tutto fatto!"

Se digiti "makepp all", o se metti all come primo target esplicito nel tuo makefile
(che è tipico) e digita semplicemente "makepp", quindi tutte le dipendenze saranno
costruito, quindi stamperà "Tutto fatto!". A questo punto makepp cercherà il file ./Tutti
e scoprirà che non esiste. Si lamenterà ad alta voce.

Per evitare che makepp si aspetti il ​​file ./Tutti per uscire, devi dirgli che è a
bersaglio fasullo. Metti una riga come la seguente nel tuo makefile (non fa differenza
dove):

.FHONY: tutto

Un'alternativa equivalente che a volte è più conveniente è usare "$(falso)"
funzione, in questo modo:

$(tutti fasulli): prog1 prog2 subdir/prog3 subdir2/libmine.a

I target fasulli in un makefile possono fare riferimento a target fasulli in un altro makefile. Questo è
spesso fatto con l'obiettivo "pulito", in questo modo:

# Makefile di primo livello:
# un sacco di regole e cose qui
#....
$(pulito fasullo): subdir1/clean subdir2/clean
&rm -fm mio_programma

Quindi nelle sottodirectory, i makefile potrebbero essere letti in questo modo:

# Makefile in una sottodirectory
#...
$(falso pulito):
&rm -fm $(carattere jolly *.o *.a)

Ma al giorno d'oggi useresti il ​​comando "makeppclean", invece di un target pulito.

I caratteri jolly

È sicuro specificare i caratteri jolly nell'elenco delle dipendenze. I caratteri jolly corrispondono non solo ai file
che esistono, ma file che possono essere creati date le regole nel makefile. Per esempio,
per creare una libreria da tutti i file .o in una directory, potresti scrivere questo:

libmine.a: *.o
&rm -f $(uscita)
ar cr $(output) $(input)

Funzionerà anche se nessuno dei file ".o" è stato ancora creato, perché makepp's
i caratteri jolly corrispondono a file che non esistono ancora ma che possono essere compilati. Anche questo riprenderà
file la cui regola viene scoperta in seguito (nello stesso makefile o in uno non ancora letto). In questo
ultimo punto si differenzia dalla funzione "jolly", che è limitata alle regole note,
poiché deve restituire il suo risultato quando viene espanso.

Makepp supporta tutti i soliti caratteri jolly della shell ("*", "?" e "[]"). Ha anche un
carattere jolly "**" che corrisponde a qualsiasi numero di directory interposte. (Questa idea è stata rubata
da zsh.) Ad esempio, "**/*.c" corrisponde a tutti i .c file nell'intero albero dei sorgenti.
"objects/**/*.o" corrisponde a tutti i .o file contenuti ovunque nella sottodirectory oggetti
o una delle sue sottodirectory o una delle loro sottodirectory. Il carattere jolly "**" non lo farà
segui i soft link alle directory a qualsiasi livello. Inoltre, non restituirà mai obiettivi fasulli.

I caratteri jolly di Makepp ignoreranno i file o le directory che esistono ma non possono essere letti. Dopo
tutti, tali file non possono comunque essere utilizzati nel processo di compilazione. Mettere file illeggibili in a
è principalmente utile per inibire l'importazione automatica del file dato da a
repository.

L'affermazione iniziale era che questo è sicuro. Questo è nel senso che funziona se
i file esistono già o devono essere prima compilati. Tuttavia non è sicuro nel senso
che corrisponderà ancora ai file che sono stati creati da makepp, ma non hanno più una regola (ad es
hai rimosso il file .c file, ma il .o file è ancora lì.) Per evitare ciò, utilizzare il tasto
Opzione "--rm-stale".

Cartamodello norme
Una regola modello è una regola che viene applicata in base a un modello testuale. Questo è usato per
applicare la stessa regola a un'intera classe di file. La sintassi è la stessa di quella di GNU make
regole del modello:

%.o: %.c
$(CC) -c $(ingresso) -o $(uscita)

Questo dice che qualsiasi file nella directory corrente che corrisponde a "*.c" può essere convertito in
il file .o corrispondente usando il comando dato.

Si noti che possono essere fornite diverse dipendenze dai pattern. Ad esempio, se il tuo xyz.o filetto
dipende dal corrispondente xyz.cpp file, e anche su un file chiamato moc_xyz.cflags quale
contiene le opzioni del compilatore, questo potrebbe essere espresso con:

%.o: %.cpp %.cflags
$(CXX) `cat $(gambo).cflags` -c $(input) -o $(output)

Potresti anche avere diversi target di pattern. Per esempio,

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

Normalmente, le regole del modello cercano solo i file nelle directory correnti. puoi forzare
loro di cercare nella directory corrente e in tutte le directory sottostanti impostando

makepp_percent_subdirs := 1

prima della prima regola del modello nel makefile o sulla riga di comando, ad esempio.

C'è una chiara differenza tra "%" e il carattere jolly "*", sebbene entrambi corrispondano a qualsiasi
string: il carattere jolly restituisce un elenco di file completamente utilizzati in quel punto. Così
questo dipende da tutto .o file compilabili qui:

prog: *.o
$(LD) $(LDFLAG) $(input) -o $(output)

Ciò non può essere ottenuto sostituendo "*" con "%", perché quest'ultimo è per uno per uno
corrispondenza tra input e output, producendo internamente una regola per ogni radice abbinata.

statica modello norme
Una regola del modello statico è una regola del modello che viene applicata solo a un set limitato di file:

$(MODULI_SPECIALI).o : %.o : %.cpp
$(CXX) -c $(ingresso) -o $(uscita)

Questo dice che la regola del modello si applica solo ai file in "$(SPECIAL_MODULES).o".

Questo è principalmente per compatibilità con GNU make; le regole di foreach (vedi sotto) sono più
modo potente di fare la stessa cosa.

Per ciascuno norme
La sintassi della regola del modello sopra è abbastanza potente da supportare quasi tutte le build, ma
ogni tanto è necessario fare qualcosa di più complicato. Makepp offre un altro
sintassi potente: la clausola ":foreach" per la regola.

target_expression : dependency_expression : per ogni elenco di file
azioni

Il tipo più semplice di regola foreach è solo una regola modello la cui applicazione è limitata
a un elenco specifico di file. Ad esempio, supponiamo di avere una regola del modello che dice
makepp come compilare tutto .c File. Tuttavia, hai una lista di .c file per i quali tu
vuole fare qualcosa di diverso. Potresti fare qualcosa del genere:

# Ecco la regola che si applica a tutto:
%.o: %.c
$(CC) $(CFLAGS) -c $(ingresso) -o $(uscita)

%.o : %.c : foreach $(MODULI_SPECIALI)
$(CC) $(SPECIAL_CFLAGS) -c $(ingresso) -o $(uscita)

Un uso ancora più potente delle regole foreach sfrutta il fatto che la variabile
"$(foreach)" è impostato a sua volta su ciascun file che corrisponde all'elenco dei file e al target e
vengono valutate le espressioni di dipendenza. L'elenco dei file può contenere caratteri jolly e questi
trova anche file che non esistono ancora ma che possono essere compilati (vedi "Caratteri jolly" in
regole_makepp).

Questa è una sintassi ingombrante ma è estremamente flessibile, perché la variabile "$(foreach)"
può apparire in alcun modo nell'espressione. Innanzitutto, nota che le regole del modello sono in effetti a
caso speciale di regole foreach; la regola del modello

%.o: %.c
$(CC) $(CFLAGS) -c $(ingresso) -o $(uscita)

è esattamente equivalente a:

$(patubst %.c, %.o, $(foreach)) : $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(ingresso) -o $(uscita)

(In effetti, viene convertito in circa quello internamente.)

Come esempio di come useresti una clausola ":foreach" dove una regola del modello non lo è
sufficiente, supponiamo che tu ne abbia un po' .c file che sono costruiti usando un qualche tipo di preprocessore
che prende come input file con a .k estensione. Vuoi compilarli? .c file con estensione
set di opzioni di compilazione diverso dal solito .c file che sono sorgenti ordinarie
File. Potresti fare qualcosa del genere:

# Regola per i normali file .c:
%.o: %.c
$(CC) $(CFLAGS) -c $(ingresso) -o $(uscita)

# Regola per creare file .c da file .k:
%.c: %.k
$(preprocessore) $(input) > $(output)

# Regole di compilazione speciali per i file .c creati da file .k:
$(foreach:%.k=%.o) : $(foreach:%.c=%.k) : foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(ingresso) -o $(uscita)

(Questo usa la sintassi di riferimento di sostituzione leggermente più concisa piuttosto che chiamare
"patsubst" esplicitamente.)

Nota che se tutto ciò che vuoi fare è cambiare il valore di una variabile ("CFLAGS" in questo
case) a volte è più conveniente usare variabili specifiche per il target.

Eredità suffisso norme
Per la compatibilità con le versioni precedenti, makepp supporta le regole dei suffissi vecchio stile.

.suffisso1.suffisso2:
azioni

è equivalente

%.suffisso2: %.suffisso1
azioni

ma molto più difficile da ricordare. (Quale suffisso viene prima?) In genere, apparirà una regola
in un makefile legacy come questo:

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

che è esattamente equivalente a

%.o: %.c
$(CC) $(CFLAGS) -c $(ingresso) -o $(uscita)

Conflitto norme
Quando c'è più di un modo per creare un file, makepp usa una semplice procedura per
determinare quale regola utilizzare.

· È un errore avere regole esplicite in conflitto per la creazione di un file.

· Le regole del modello e le regole foreach con caratteri jolly non sovrascrivono mai le regole esplicite. così
le regole esplicite possono essere utilizzate per specificare le eccezioni per le regole del modello. (Nota che semplicemente
l'uso di una clausola ":foreach" non rende qualcosa una regola del modello. Deve avere un
carattere jolly (come "*" o "?") come parte del nome del file nella clausola ":foreach". Se è
solo un elenco esplicito di file, viene trattato come una regola esplicita per ciascuno di questi
File.)

· Quando le regole del modello in conflitto provengono da makefile diversi, le regole da "più vicino"
i makefile sovrascrivono le regole dei makefile "più lontani". "Più vicino" significa che il makefile
si trova più vicino alla destinazione nella gerarchia delle directory (cioè, il nome del file del
target relativo alla directory da cui viene eseguito il makefile è più breve). Se questo
non distingue i makefile, quindi la regola dal makefile che viene caricato
viene utilizzato l'ultimo.

Ciò significa che puoi specificare una regola del modello che si applica a tutti i file nel tuo
intero albero di directory solo nel makefile di primo livello, ma poi puoi sovrascriverlo in
un makefile di livello inferiore. Ad esempio, il tuo makefile di primo livello potrebbe contenere:

%.o : %.c : per ogni **/*.c
$(CC) $(CFLAGS) -c $(ingresso) -o $(uscita)

e potresti avere un makefile in una delle sottodirectory che dice:

%.o: %.c
$(CC) $(SPECIAL_CFLAGS) -c $(ingresso) -o $(uscita)

· Le regole di pattern che hanno una catena di inferenza più corta sono preferite rispetto ad altri pattern
regole. Ad esempio, se avessi le seguenti regole (basate su un esempio dal
kernel Linux):

%.ns
$(CC) -s $(ingresso) -o $(uscita)

%.o: %.s
$(COME) $(ingresso) -o $(uscita)

%.o: %.c
$(CC) -c $(ingresso) -o $(uscita)

Se abbiamo bisogno di creare "xyz.o", potremmo creare il file ".s" intermedio e poi
eseguiamolo attraverso l'assemblatore usando le prime due regole, oppure potremmo andare direttamente a a
File ".o" utilizzando l'ultima regola. L'ultima regola è da preferire perché ce ne sono di meno
passi nella catena di inferenza (uno invece di due).

· Le regole di pattern successive in un makefile sovrascrivono le regole di pattern precedenti. (Questo è
indietro da GNU make.) Ciò significa che dovresti mettere le tue regole più generali
prima e le tue regole più specifiche in seguito. Per esempio,

%.o: %.c # Regola di compilazione generale.
azione

special_%.o: special_%.c # Regola speciale per i file con a
azione diversa # prefisso "special_".

Regola Opzioni
A volte è necessario fornire opzioni aggiuntive per modificare il modo in cui makepp esegue il
regola. Queste opzioni sono specificate come ":optionname value", sia sulla riga che contiene
le dipendenze o sulla riga successiva.

Fornire le opzioni su righe separate potrebbe rendere possibile l'utilizzo delle stesse
makefile con makepp e un make tradizionale. Per esempio,

obiettivo: dipendenze
: firma target_newer
azioni

funzionerà bene con una marca Unix tradizionale, perché interpreta la riga ": signature"
come comando di shell e un comando che inizia con i due punti non fa nulla.

:build_cache /percorso/per/creare/cache
obiettivo: dipendenze
: build_cache /put/cache/files/sopra/là
azioni

Specifica il percorso di una cache di build da utilizzare per i file prodotti da questa regola. Questo
sovrascrive l'effetto dell'istruzione "build_cache" o del comando "--build-cache"
opzione riga, se presente, per questa regola. Vedi makepp_build_cache per i dettagli su build
cache.

Se specifichi "none" invece di un percorso, disabiliti la cache di build per questo
regola particolare. Questo può essere utile per evitare di sprecare spazio su disco su file che
so che non sono utili per la cache, anche perché sei molto sicuro che non lo saranno mai
riutilizzati o perché sono costruiti così velocemente che non vale la pena memorizzarli nella cache.

: build_check build_check_metodo
obiettivo: dipendenze
: build_check target_newer
azioni

Questo dice a makepp quale algoritmo usare per decidere se i target devono essere ricostruiti.
Vedi makepp_build_check per maggiori dettagli. Questo annulla l'effetto di
l'istruzione "build_check" o l'opzione della riga di comando "--build-check-method", se presente, per
questa regola.

:env VARIABILE ...
Aggiungere una dipendenza dai valori delle variabili di ambiente denominate. Se qualcuno di loro
differiscono dalla build precedente, quindi gli obiettivi sono considerati obsoleti, se il
metodo build_check così impone. (Tutti i metodi di controllo build incorporati ad eccezione di
target_newer rispetta questo.)

VARIABLE può essere nella forma "filename in PATH_VARIABLE" (tra virgolette), nel qual caso il
i target sono considerati obsoleti se la prima directory dal carattere delimitato da due punti
il valore di PATH_VARIABLE in cui esiste il nome del file è diverso dall'ultima build.
Questo può essere usato per evitare di ricostruire i target quando PATH_VARIABLE cambia in un
modo irrilevante.

:spedizione command ...
Racchiudi ogni azione della shell (ma non le azioni Perl né i comandi Perl) in un "sh -c '...'"
e prefiggilo con comando, ma presumi che l'obiettivo non dipenda da comando.
Ciò è utile se si desidera inviare azioni a un sistema di accodamento lavori, ma il risultato è
si presume essere indipendente dai parametri di coda, nonché dal fatto che la coda
il sistema viene utilizzato del tutto.

:includere file_o_modello
La regola varia a seconda del compilatore:

%.o: %.c
: include %.d : firma C
gcc -MD -c...

%.o: %.c
: include %.u : firma C # IBM utilizza un suffisso diverso
xlc -M -c...

sub dependify { # Trasforma le chiacchiere di Microsoft in un formato utile
s/\$/\$\$/g;
s/(Nota: incluso il file: *)?(.+?)\r?\n/$1 ? "'$2' " : "'".f_output()."': "/e;
}
%.o: %.c
: include %.d : firma C
cl -showIncludes -c ... >$(radice).d
&sed &dipende -o +<$(radice).d

Alcuni compilatori (icc di Intel proprio come gcc sopra o xlc di IBM) possono produrre dipendenza
file al volo. Cioè, mentre compilano, scrivono un makefile che makepp può
includere. Il vantaggio rispetto allo scanner di makepp è che è garantito al 100%
corretto, dove possiamo solo avvicinarci.

Questa opzione lo sfrutta in modo speciale: se il file non è presente, ad es
in genere sulla prima build, si verifica la scansione normale. Ma se il file è presente, no
si verifica la scansione (motivo per cui specifichiamo una firma intelligente sopra -- non la scansione cade
torna alla stupida impostazione predefinita di timestamp e dimensioni). Invece include il file, prima
esecuzione della regola. Dopo aver eseguito con successo la regola, dimentica qualunque cosa
letto la prima volta, dato che il file potrebbe essere obsoleto. Invece si legge
il file di nuovo, se è cambiato, per avere informazioni di build aggiornate.

ATTENZIONE: questo è intrinsecamente inaffidabile. Il file delle dipendenze viene prodotto da molto
regola per la quale è una dipendenza. D'altra parte, il compilatore sa tutto
sono sottoinclude interne, che makepp di solito ignora. Questa è un'affidabilità
vantaggio solo nel caso in cui una patch del compilatore risolva solo le sottoinclude. Il
il prezzo è che makepp finisce per guardare molti più file, il che richiede tempo.

C'è un problema quando si rimuove un'istruzione "#include" ed il file corrispondente:
Sarà ancora menzionato nel file delle dipendenze dall'ultima volta, quando era
necessario. In tal caso è necessario modificare il file delle dipendenze per rimuovere la dipendenza
che non è più realizzabile.

Questa funzione non può essere utilizzata con una cache di build perché il recupero di un file da lì
richiede di sapere tutto sul file. Ma un file di dipendenza dipende da quelli
file di cui makepp apprende leggendolo. Una tale dipendenza circolare non è normalmente
possibile in un sistema di build affidabile. Questa è un'eccezione perché dopo la ricostruzione
e rileggendo un file di dipendenza tutto è di nuovo corretto.

Se crei nei tuoi repository, makepp prenderà il file delle dipendenze da
Primo repository che ne contiene uno. Questo è diverso da altri file, dove prende il primo
con la firma prevista. Questo è meglio che per le cache di compilazione, dove per mancanza di
firma, non riesce nemmeno a trovare il file.

:ultima possibilità
Abilita una regola aperta, come

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

Poiché una regola come questa potrebbe generare un numero essenzialmente infinito di obiettivi,
un obiettivo di questa regola non corrisponderà a una funzione $ (carattere jolly) o a una regola del modello a meno che
qualcos'altro ha già istanziato la regola facendo riferimento specificamente al target.
Inoltre, se viene specificato "--rm-stale", allora un bersaglio rimasto da un precedente
makepp run apparirà obsoleto se l'unico modo per compilarlo è tramite una regola last_chance
che non è stato ancora istanziato per il target, il che è un comportamento desiderabile perché
la build fallirà in modo più coerente quando si basa erroneamente su un carattere jolly per
abbinare gli obiettivi di una corsa precedente.

L'opzione ":last_chance" ha lo scopo di richiamare l'attenzione sul comportamento speciale del
regola rispetto ai caratteri jolly corrispondenti.

:analizzatore parser
Questo dice a makepp come analizzare il comando per rilevare (includere) i file. Generalmente,
makepp indovina come farlo in base alle parole nel comando stesso (vedi
makepp_scanning per i dettagli). Tuttavia, se makepp indovina, potresti volerlo
indicare esplicitamente il parser, in questo modo:

%.o: %.abc
: analizzatore c_compilation
azione qui

Questo fa sì che makepp esegua la stessa analisi e scansione che fa per C/C++
build, anche se non riconosce l'azione come una compilazione C.

Il parser predefinito dipende dal comando. Se non specifichi un'opzione ":parser",
quindi viene esaminata la prima parola di ogni comando. Ad esempio per una compilazione o un collegamento
comando, makepp utilizzerà il parser "c_compilation"; o se il comando assomiglia a
Variante GNU, "gcc_compilation". Se non viene trovato alcun parser, utilizza il parser "none". Per
maggiori dettagli su questo, o se vuoi scrivere il tuo parser o cambiare makepp
parser predefiniti, vedere makepp_scanning.

Nota che questo vale per ogni comando nella regola, che potrebbe non essere quello che vuoi:

%.o: %.c : compilazione c del parser
@echo 'Costruire $(output)'
@divertente_cc...

Questo interpreterà anche "echo" come compilatore e dedurrà il suo argomento "Building"
mymodule.o' come dipendenza implicita. Questo porterà alla denuncia che
non sa come creare un file del genere. In questo caso staresti meglio con
"register_parser". Lì trovi una spiegazione su come parser può essere dato sia come a
nomeclasse o come nome di funzione.

:firma firma_metodo
obiettivo: dipendenze
: firma md5
azioni

Questo dice a makepp quale algoritmo usare per determinare se le dipendenze sono cambiate.
Vedi makepp_signatures per maggiori dettagli. Metodi di firma inclusi con il
Le distribuzioni di makepp sono "plain", "md5", "C" o "c_compilation_md5" e
"oggetto_condiviso". Questo sovrascrive qualsiasi metodo di firma specificato con "-m" o
opzioni della riga di comando "--signature-method" o con l'istruzione "signature".

Special caratteri
Makepp può supportare nomi di file che contengono caratteri speciali come i due punti o uno spazio.
Supponiamo, ad esempio, di voler creare un file chiamato "a:thing" dal file "b:thing".
Non puoi scrivere la regola in questo modo:

a:thing : b:thing # Questo è un errore di sintassi
&cat $(input) -o $(output)

perché makepp non saprà quali due punti separano i target dalle dipendenze e quali sono
parte dei nomi dei file. Invece, racchiudi semplicemente il nome tra virgolette, in questo modo:

"a:cosa": "b:cosa"
&cat $(input) -o $(output)

Ora la regola è univoca.

La sintassi delle citazioni di Makepp è abbastanza simile a quella della shell. Puoi, ad esempio, usare single
virgolette anziché virgolette doppie, oppure puoi eseguire l'escape dei caratteri speciali con una barra rovesciata:

a\:cosa : 'b:cosa'
&cat $(input) -o $(output)

Supponiamo, ad esempio, che il nome del tuo file sia "'"!;\$". Ora perché vorresti un nome di questo tipo
Non lo so, ma qui ci sono diversi modi per specificarlo su makepp (e sulla shell):

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

Presta attenzione a quando makepp rimuove le citazioni e quando lo fa la shell. Makepp guarda
quotazioni solo nei seguenti casi:

· nella famiglia di test "ifeq"

· prima e dopo la regola due punti

· in un comando integrato di makepp

· in una funzione che riguarda i file

A differenza della shell, makepp non espande le virgolette mentre le assegna a una variabile. così
le seguenti regole sono identiche:

FILE = 'nome con spazi'
x := $(print $(FILE)) # solo per verificare che le virgolette siano ancora presenti
$(FILE): # virgolette attorno a un singolo file rimosso da makepp
&echo ciao -o$(FILE) # virgolette attorno a un singolo file rimosso da makepp
echo there >>$(FILE) # virgolette attorno a un singolo file rimosso da Shell
'nome con spazi':
&echo ciao -o'nome con spazi'
echo there >>'$(output)' # le virgolette sono state eliminate sopra, aggiungile di nuovo

Nota che (a differenza della Shell) le variabili che iniziano con "$" vengono espanse anche all'interno di single
citazioni. I simboli del dollaro non possono essere protetti da virgolette o barre rovesciate. Per ottenere un letterale
simbolo del dollaro, utilizzare un doppio simbolo del dollaro, ad es.

$(falso tutto):
@&echo Questo è il simbolo del dollaro: $$
@for val in abcd; fai echo $$val; fatto

In genere, dovresti essere in grado di gestire qualsiasi carattere speciale citandolo
in qualche modo. Ciò include spazi, caratteri di controllo, ecc. Tuttavia, tieni presente che a
presente, la rimozione dei commenti di makepp è in qualche modo semplicistica e qualsiasi carattere "#"
preceduti da spazi verranno interpretati come commenti, indipendentemente da come vengono citati.

Quando un nome di destinazione o dipendenza viene inserito in una variabile automatica come "$(output)", allora
le virgolette e le eventuali barre rovesciate vengono eliminate. Ciò significa che se si desidera fare riferimento al
nome file nelle azioni, probabilmente dovrai citarlo di nuovo, in questo modo:

"un nome file con spazi":
echo "Contenuti speciali" > "$@"

Se non metti le virgolette intorno a $@, la shell vedrà il comando

echo "Contenuti speciali" > un nome di file con spazi

che scrive la stringa "Nome file di contenuti speciali con spazi" nel file chiamato a.
Questo probabilmente non è quello che vuoi.

Usa makepp_rules online usando i servizi onworks.net