makepp_rules – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

makepp_rules – Wie man makepp anweist, etwas zu erstellen

BESCHREIBUNG

?: &,
-,
@, B: :build_cache,
:build_check, D: :versenden, E: :env, I: „ignore_error“,
:enthalten, L: :letzte Möglichkeit, M: makeperl, N: „noecho“, P: :Parser,
„perl“, S: :Unterschrift

Eine Regel sagt makepp, wie eine Datei oder eine Dateiklasse erstellt werden soll. Makepp unterstützt die
Dieselbe Regelsyntax wie andere Implementierungen von make, plus einige eigene Ergänzungen.

Eine Regel hat das allgemeine Format

Zielausdruck: Abhängigkeitsausdruck [: optionale Argumente]
Aktionen

Die Liste der Ziele darf keine automatischen Variablen enthalten (außer „$(foreach)“). Der
Die Abhängigkeitsliste darf nur automatische Variablen enthalten, die sich auf das Ziel beziehen (d. h.
„$(output)“, „$(outputs)“ oder deren Synonyme). Die Aktion kann eine beliebige Automatik enthalten
Variablen.

Wenn makepp entscheidet, dass die Regel ausgeführt werden muss, wird jede Zeile der Regel ausgeführt
nacheinander, und wenn einer einen Status ungleich Null zurückgibt, wird der Rest nicht ausgeführt (und
makepp bricht mit einem Fehler ab, es sei denn, Sie haben die Option „-k“ in der Befehlszeile angegeben.)
Jede Aktion sollte nur eine Zeile umfassen. Wenn eine Aktion zu lang ist, können Sie bequem auf a schreiben
Wenn Sie eine einzelne Zeile eingeben, können Sie sie in mehrere Zeilen aufteilen und einen Backslash einfügen, um anzuzeigen, dass die
Mehrere Zeilen sollten zu einer zusammengefasst werden.

Um Aktionen von der nächsten Regel unterscheiden zu können, sollte die Aktion stärker eingerückt werden
als die Zeile mit den Zielen und Abhängigkeiten. Im Gegensatz zu anderen Implementierungen von
make, makepp ist es eigentlich egal, wie stark Sie es einrücken oder ob Sie Tabulatorzeichen verwenden
statt Leerzeichen. Um die Abwärtskompatibilität mit herkömmlichen Marken aufrechtzuerhalten, gelten die Regeln
makepp verwendet, um zu entscheiden, wann Aktionen enden und die nächste Regel beginnt, ist etwas kompliziert:

· Die erste Aktionszeile muss weiter eingerückt sein als die Zeile mit dem Ziel.

· Wenn eine Zeile um ein Tabulatorzeichen oder 8 Leerzeichen oder mehr eingerückt ist, wird dies berücksichtigt
eine Aktionslinie.

· Eine Leerzeile oder eine Kommentarzeile mit dem Zeichen „#“ am rechten Rand beendet die
Regel, es sei denn, die nächste nicht leere Zeile wird um mehr als 8 Leerzeichen (oder mehr als eins) eingerückt
Tab).

· Wenn eine Zeile genauso weit oder weiter eingerückt ist als die erste Aktionszeile, dann ist dies der Fall
als zusätzliche Aktionslinie betrachtet.

Es gibt ein paar besondere Aktionsgegenstände:

& Diesem Symbol folgen ein Befehlsname und eine beliebige Anzahl von Argumenten. Hülse
Die Syntax wird hier nicht vollständig verstanden, nur einfache und doppelte Anführungszeichen und Backslashes
Charaktere darin, wie überall in Makepp. Der Befehlsname führt entweder zu einer Funktion
"C_Name" mit den verbleibenden Zeichenfolgen als Argumenten aufgerufen werden. Wenn eine solche Funktion möglich ist
nicht gefunden wird, ist dies identisch mit dem Aufruf von „run“ aus einem „perl“-Block.

Dies ermöglicht den effizienten Aufruf eines integrierten, vom Makefile bereitgestellten oder externen Befehls.
Das Präfix „&“ wurde gewählt, weil es der Funktionsaufrufer in Perl ist und weil
Am Anfang ist es in Shell illegal.

$(ROOT)/include/%.h: %.h
&ln $(Eingabe) $(Ausgabe)

neinecho
@ Normalerweise wird jeder Shell-Befehl bei seiner Ausführung ausgegeben. Allerdings, wenn das erste Wort
der Aktion „noecho“ ist (oder wenn sie mit dem Zeichen „@“ beginnt), dann der Befehl
wird nicht gedruckt. Zum Beispiel,

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

Dies bedeutet, dass der Befehl libtool bei Ausführung nicht gedruckt wird. (Libtool
selbst gibt normalerweise den geänderten Befehl aus, den es ausführt, daher ist es überflüssig
Drucken Sie es zweimal aus.)

ignorieren_error
- Wenn der Shell-Befehl normalerweise einen Status ungleich Null zurückgibt, wird makepp abgebrochen, weil
Der Befehl ist fehlgeschlagen. Einige Programme setzen jedoch den Status beim Beenden fälschlicherweise oder
Möglicherweise liegt ein Fehler vor, der wirklich nicht schwerwiegend ist und das Ganze nicht zum Abbruch bringen sollte
Zusammenstellung. Sie können makepp veranlassen, den Rückgabestatus zu ignorieren, indem Sie Folgendes angeben
„ignore_error“ als erstes Wort der Befehlszeile (oder „-“ als erstes Zeichen).
Zum Beispiel,

$(falsche Verteilung):
ignore_error rm -r my_program-$(VERSION) # Vorherigen Müll entfernen.
&mkdir my_program-$(VERSION)
&cp $(FILES) my_program-$(VERSION)
tar cf my_program-$(VERSION).tar my_program-$(VERSION)

Dieser Befehl erstellt ein Verzeichnis, kopiert eine Reihe von Dateien hinein und legt sie dann ab
alles in eine TAR-Datei zur Verteilung. Es ist eine gute Idee, das zu reinigen
vorherigen Inhalt des Verzeichnisses, falls dort zuvor etwas vorhanden war, und das ist
was die erste Zeile bewirkt. Der „rm“ schlägt möglicherweise fehl, sein Rückgabestatus wird jedoch ignoriert.

perl
makeperl
Dies ist im Wesentlichen dasselbe wie die Perl-Anweisung, wird jedoch jedes Mal ausgeführt
Ausführen der Regel, nicht beim Lesen des Makefiles. Die erste Variante ist einfaches Perl
Code, während die zweite Variante die Anweisung zunächst über eine Variable im Make-Stil weiterleitet
Erweiterung.

Zu den beiden Möglichkeiten, die Zahnspange am Körper anzubringen, siehe die Erklärung unter
„perl_perlcode“ in makepp_statements. Beachten Sie, dass die dritte Variante dort erläutert wird
macht hier keinen Sinn, da alle Aktionszeilen eingerückt werden müssen. Sie müssen signalisieren
Fehler in Perl-Anweisungen durch den Aufruf von „die“.

Per Regel werden die Perl-Anweisungen derzeit in einem gemeinsamen Unterprozess ausgewertet, außer bei
Windows. Das bedeutet, dass sie nur Lesezugriff auf alle Makefile-Variablen haben. Es ist auch
der Prozess, der Nicht-Perl-Aktionen ausführt. Der Aufruf von „exec“ oder „exit“ wird also verwirrend sein
makepp. Aber das könnte sich in Zukunft ändern. Für eine effiziente Möglichkeit, Perl aufzurufen
Skripte finden Sie im vorherigen Punkt „&“ oder „Ausführen“.

$(falsche Version):
noecho perl {{ # $(target) & $(VERSION) aus Perl:
print „Das ist „.f_target().“ $VERSION\n“;
}}
echo Sie können dies mit Shell-Befehlen kombinieren
-makeperl { print „Dies ist $(target) $(VERSION)\n“ }

Es gibt verschiedene Arten von Regeln mit jeweils unterschiedlichen Zwecken.

Explicit Regeln
Ziel1 Ziel2: Abhängigkeit1 Abhängigkeit2 ...
durchzuführende Aktionen

Diese Syntax gibt an, dass entweder eines erstellt werden soll Ziel1 or Ziel2, alle Dateien
Abhängigkeit1, Abhängigkeit2usw. müssen bereits erstellt worden sein. Dann sind die gegebenen Aktionen
wird von der Shell ausgeführt, um die Ziele zu erstellen.

Die erste explizite Regel in einer Datei ist das Standardziel und wird erstellt, wenn Sie nichts angeben
beliebige Ziele in der Befehlszeile.

Im Gegensatz zu herkömmlichen Make-Programmen geht makepp normalerweise davon aus, dass die Aktion nur einmal aufgerufen wird
macht alle Ziele (es sei denn, es gibt keine Abhängigkeiten). Zum Beispiel ein Aufruf
von yacc erstellt beide Ausgabedateien für diese Regel:

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

Beachten Sie, dass andere Implementierungen von make kein Konzept eines einzelnen Befehls haben
Es werden mehrere Ausgabedateien erstellt. Wenn Sie also mehrere Ziele angeben, werden diese auch erzeugt
Führen Sie die Regel einmal pro Ziel aus. Makepp wird zu diesem Verhalten zurückkehren, wenn es danach aussieht
Dies ist ein Makefile im alten Stil. Konkret wird die Regel einmal pro Ziel ausgeführt.
statt nur einmal insgesamt, wenn alle folgenden Aussagen zutreffen:

· Die Regelaktion erwähnt die automatische Variable $@. (Die Synonyme „$(output)“ bzw
„$(target)“ löst dieses Verhalten nicht aus.)

· Die Regelaktion erwähnt nicht die automatische Variable „$(outputs)“ (oder ihr Synonym).
„$(Ziele)“).

· Dies ist keine Musterregel und es gibt keine foreach-Klausel.

Zum Beispiel,

Alle Testinstallationen:
für Unterverzeichnis in $(SUBDIRS); do cd $$subdir && $(MAKE) $@; CD ..; Erledigt

ist eine gebräuchliche Redewendung in Makefiles und wird von makepp unterstützt. (Beachten Sie, dass Sie niemals verwenden sollten
rekursives Make in allen neuen Makefiles, die Sie schreiben – verwenden Sie die Anweisung „load_makefile“, oder
stattdessen implizites Laden des Makefiles.)

Wenn Sie möchten, dass dieselbe Regel einmal für jedes Ziel ausgeführt wird (z. B. weil die Ziele
ähnliche Befehle haben), ist es vorzuziehen, entweder eine Musterregel (siehe unten) oder eine zu verwenden
„foreach“-Klausel. Wenn Sie beispielsweise mit einem herkömmlichen Make-Programm schreiben würden:

A B C D:
etwas tun, um $@ > $@ zu bauen

in makepp würden Sie es wahrscheinlich so schreiben wollen:

$(foreach) : : foreach abcd
do_something, um $(output) > $(output) zu erstellen

Phony Ziele

A falsch Ziel ist ein Ziel, das niemals tatsächlich im Dateisystem existieren wird; es ist nur ein
Möglichkeit, makepp dazu zu bringen, einige Ziele zu erstellen und möglicherweise einige zusätzliche Befehle auszuführen.

Ein typisches falsches Ziel ist „alles“, was normalerweise verwendet wird, um alles zu verursachen, was sein kann
gebaut, um gebaut zu werden, so:

alle: prog1 prog2 Unterverzeichnis/prog3 Unterverzeichnis2/libmine.a
@&echo „Alles erledigt!“

Wenn Sie „makepp all“ eingeben oder all als erstes explizites Ziel in Ihrem Makefile angeben
(was typisch ist) und geben Sie einfach „makepp“ ein, dann werden alle Abhängigkeiten angezeigt
erstellt, dann wird „Alles erledigt!“ ausgegeben. An diesem Punkt sucht makepp nach der Datei ./alle
und werden feststellen, dass es nicht existiert. Es wird sich lautstark beschweren.

Um zu verhindern, dass makepp die Datei erwartet ./alle Zum Beenden müssen Sie ihm mitteilen, dass es sich um ein handelt
falsches Ziel. Fügen Sie einfach eine Zeile wie die folgende in Ihr Makefile ein (es macht keinen Unterschied
Wo):

.PHONY: alle

Eine gleichwertige Alternative, die manchmal praktischer ist, ist die Verwendung von „$(phony)“.
Funktion wie folgt:

$(falsche alle): prog1 prog2 subdir/prog3 subdir2/libmine.a

Falsche Ziele in einem Makefile können auf falsche Ziele in einem anderen Makefile verweisen. Das ist
oft mit dem „sauberen“ Ziel gemacht, so:

# Makefile der obersten Ebene:
# hier gibt es viele Regeln und so
# ....
$(falsch sauber): subdir1/clean subdir2/clean
&rm -fm mein_programm

Dann könnten die Makefiles in den Unterverzeichnissen so lauten:

# Makefile in einem Unterverzeichnis
#...
$(gefälschte Reinigung):
&rm -fm $(Platzhalter *.o *.a)

Heutzutage würden Sie jedoch den Befehl „makeppclean“ anstelle eines sauberen Ziels verwenden.

Wildcards

Es ist sicher, Platzhalter in der Abhängigkeitsliste anzugeben. Platzhalter stimmen nicht nur mit Dateien überein
die existieren, sondern Dateien, die anhand der Regeln im Makefile erstellt werden können. Zum Beispiel,
Um eine Bibliothek aus allen .o-Dateien in einem Verzeichnis zu erstellen, könnten Sie Folgendes schreiben:

libmine.a: *.o
&rm -f $(Ausgabe)
ar cr $(Ausgabe) $(Eingaben)

Dies funktioniert auch dann, wenn noch keine der „.o“-Dateien erstellt wurde, weil makepp
Platzhalter stimmen mit Dateien überein, die noch nicht existieren, aber erstellt werden können. Das wird sogar noch zunehmen
Dateien, deren Regel später entdeckt wird (im selben Makefile oder einem noch nicht gelesenen). In diesem
Im letzten Punkt unterscheidet es sich von der „Wildcard“-Funktion, die auf die bekannten Regeln beschränkt ist,
da es sein Ergebnis zurückgeben muss, wenn es erweitert wird.

Makepp unterstützt alle üblichen Shell-Platzhalter („*“, „?“ und „[]“). Es hat auch eine
Platzhalter „**“, der auf eine beliebige Anzahl dazwischenliegender Verzeichnisse passt. (Diese Idee wurde gestohlen
von zsh.) Beispielsweise stimmt „**/*.c“ mit allen überein .c Dateien im gesamten Quellbaum.
„objects/**/*.o“ stimmt mit allen überein .o Dateien, die irgendwo im Unterverzeichnis enthalten sind Objekte
oder eines seiner Unterverzeichnisse oder eines ihrer Unterverzeichnisse. Der Platzhalter „**“ wird nicht verwendet
Folgen Sie Softlinks zu Verzeichnissen auf jeder Ebene. Außerdem werden niemals falsche Ziele angezeigt.

Die Platzhalter von Makepp ignorieren vorhandene, aber nicht lesbare Dateien oder Verzeichnisse. Nach
Insgesamt können solche Dateien ohnehin nicht im Build-Prozess verwendet werden. Einfügen unlesbarer Dateien in eine
Verzeichnis ist in erster Linie nützlich, um den automatischen Import der angegebenen Datei aus einem zu verhindern
Repository.

Die anfängliche Behauptung war, dass dies sicher sei. Dies liegt in dem Sinne, dass es funktioniert ob
Die Dateien sind bereits vorhanden oder müssen zuerst erstellt werden. Allerdings ist es in diesem Sinne unsicher
dass es immer noch mit Dateien übereinstimmt, die von makepp erstellt wurden, aber keine Regel mehr haben (z. B
Du hast das entfernt .c Datei, aber die .o Die Datei ist immer noch vorhanden.) Um dies zu verhindern, verwenden Sie die Datei
Option „--rm-stale“.

Schnittmuster Ohne eine erfahrene Medienplanung zur Festlegung von Regeln und Strategien beschleunigt der programmatische Medieneinkauf einfach die Rate der verschwenderischen Ausgaben.
Eine Musterregel ist eine Regel, die auf der Grundlage eines Textmusters angewendet wird. Das ist gewohnt
Wenden Sie dieselbe Regel auf eine ganze Klasse von Dateien an. Die Syntax ist die gleiche wie bei GNU make
Musterregeln:

%.o: %.c
$(CC) -c $(Eingabe) -o $(Ausgabe)

Dies besagt, dass jede Datei im aktuellen Verzeichnis, die mit „*.c“ übereinstimmt, konvertiert werden kann
die entsprechende .o-Datei mit dem angegebenen Befehl.

Beachten Sie, dass möglicherweise mehrere Musterabhängigkeiten bereitgestellt werden. Zum Beispiel, wenn Ihr xyzo Datei
kommt auf das entsprechende an xyz.cpp Datei, und auch auf eine Datei namens moc_xyz.cflags welche
enthält die Compiler-Optionen, dies könnte ausgedrückt werden mit:

%.o: %.cpp %.cflags
$(CXX) `cat $(stem).cflags` -c $(Eingaben) -o $(Ausgabe)

Möglicherweise haben Sie auch mehrere Musterziele. Zum Beispiel,

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

Normalerweise suchen Musterregeln nur nach Dateien in den aktuellen Verzeichnissen. Sie können erzwingen
Geben Sie ihnen die Möglichkeit, im aktuellen Verzeichnis und allen darunter liegenden Verzeichnissen zu suchen

makepp_percent_subdirs := 1

beispielsweise vor der ersten Musterregel in Ihrem Makefile oder in der Befehlszeile.

Es gibt einen klaren Unterschied zwischen „%“ und dem Platzhalter „*“, obwohl beide mit „any“ übereinstimmen
string: Der Platzhalter gibt eine Liste von Dateien zurück, die zu diesem Zeitpunkt vollständig verwendet werden. Also
das hängt von allem ab .o Dateien hier erstellbar:

prog: *.o
$(LD) $(LDFLAGS) $(Eingaben) -o $(Ausgabe)

Dies konnte nicht erreicht werden, indem „*“ durch „%“ ersetzt wurde, da letzteres für eine einzelne steht
Abgleich der Eingabe mit der Ausgabe, wodurch intern eine Regel für jeden übereinstimmenden Stamm erstellt wird.

Statisch Anleitungen Ohne eine erfahrene Medienplanung zur Festlegung von Regeln und Strategien beschleunigt der programmatische Medieneinkauf einfach die Rate der verschwenderischen Ausgaben.
Eine statische Musterregel ist eine Musterregel, die nur auf eine begrenzte Anzahl von Dateien angewendet wird:

$(SPECIAL_MODULES).o : %.o : %.cpp
$(CXX) -c $(Eingabe) -o $(Ausgabe)

Dies besagt, dass die Musterregel nur für die Dateien in „$(SPECIAL_MODULES).o“ gilt.

Dies dient hauptsächlich der Kompatibilität mit GNU make; foreach-Regeln (siehe unten) sind mehr
wirkungsvolle Art und Weise, dasselbe zu tun.

Foreach Ohne eine erfahrene Medienplanung zur Festlegung von Regeln und Strategien beschleunigt der programmatische Medieneinkauf einfach die Rate der verschwenderischen Ausgaben.
Die obige Musterregelsyntax ist leistungsstark genug, um fast alle Builds zu unterstützen
Gelegentlich ist es notwendig, etwas Komplizierteres zu tun. Makepp bietet mehr
leistungsstarke Syntax: die „:foreach“-Klausel für die Regel.

Zielausdruck: Abhängigkeitsausdruck: für jede Dateiliste
Aktionen

Die einfachste Art einer foreach-Regel ist lediglich eine Musterregel, deren Anwendung eingeschränkt ist
auf eine bestimmte Liste von Dateien. Angenommen, Sie haben eine Musterregel, die dies verrät
makepp, wie man alles kompiliert .c Dateien. Sie haben jedoch eine Liste von .c Dateien, für die Sie
etwas anderes machen möchte. Sie könnten so etwas tun:

# Hier ist die Regel, die für alles gilt:
%.o : %.c
$(CC) $(CFLAGS) -c $(Eingabe) -o $(Ausgabe)

%.o : %.c : foreach $(SPECIAL_MODULES)
$(CC) $(SPECIAL_CFLAGS) -c $(Eingabe) -o $(Ausgabe)

Eine noch leistungsfähigere Verwendung von foreach-Regeln nutzt die Tatsache aus, dass die Variable
„$(foreach)“ wird der Reihe nach auf jede Datei gesetzt, die der Dateiliste und dem Ziel entspricht und
Abhängigkeitsausdrücke werden ausgewertet. Die Dateiliste kann Platzhalter enthalten
Passen Sie sogar Dateien an, die noch nicht existieren, aber erstellt werden können (siehe „Platzhalter“ in
makepp_rules).

Dies ist eine umständliche Syntax, aber aufgrund der Variablen „$(foreach)“ äußerst flexibel
kann in irgendeiner Weise im Ausdruck vorkommen. Beachten Sie zunächst, dass Musterregeln tatsächlich a sind
Sonderfall von foreach-Regeln; die Musterregel

%.o : %.c
$(CC) $(CFLAGS) -c $(Eingabe) -o $(Ausgabe)

ist genau gleichbedeutend mit:

$(patsubst %.c, %.o, $(foreach)) : $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(Eingabe) -o $(Ausgabe)

(Tatsächlich wird es intern auf ungefähr diesen Wert umgerechnet.)

Als Beispiel dafür, wie Sie eine „:foreach“-Klausel verwenden würden, wo es keine Musterregel gibt
ausreichend, nehmen wir an, Sie haben welche .c Dateien, die mit einer Art Präprozessor erstellt werden
das nimmt als Eingabedateien mit a .k Verlängerung. Sie möchten diese zusammenstellen .c Dateien mit a
andere Kompilierungsoptionen als üblich .c Dateien, die gewöhnliche Quellen sind
Dateien. Sie könnten so etwas tun:

# Regel für gewöhnliche .c-Dateien:
%.o : %.c
$(CC) $(CFLAGS) -c $(Eingabe) -o $(Ausgabe)

# Regel zum Erstellen von .c-Dateien aus .k-Dateien:
%.c : %.k
$(Präprozessor) $(Eingabe) > $(Ausgabe)

# Spezielle Build-Regeln für .c-Dateien, die aus .k-Dateien erstellt werden:
$(foreach:%.k=%.o) : $(foreach:%.c=%.k) : foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(Eingabe) -o $(Ausgabe)

(Hierbei wird statt des Aufrufs die etwas prägnantere Substitutionsreferenzsyntax verwendet
„patsubst“ explizit angeben.)

Beachten Sie, dass Sie lediglich den Wert einer Variablen (hier „CFLAGS“) ändern möchten
Fall) ist es manchmal bequemer, zielspezifische Variablen zu verwenden.

Legacy Suffix Ohne eine erfahrene Medienplanung zur Festlegung von Regeln und Strategien beschleunigt der programmatische Medieneinkauf einfach die Rate der verschwenderischen Ausgaben.
Aus Gründen der Abwärtskompatibilität unterstützt makepp die Suffixregeln im alten Stil.

.suffix1.suffix2:
Aktionen

entspricht

%.suffix2: %.suffix1
Aktionen

aber viel schwerer zu merken. (Welches Suffix kommt zuerst?) Normalerweise wird eine Regel angezeigt
in einem alten Makefile wie diesem:

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

was genau gleichbedeutend mit ist

%.o : %.c
$(CC) $(CFLAGS) -c $(Eingabe) -o $(Ausgabe)

Widersprüchlich Ohne eine erfahrene Medienplanung zur Festlegung von Regeln und Strategien beschleunigt der programmatische Medieneinkauf einfach die Rate der verschwenderischen Ausgaben.
Wenn es mehr als eine Möglichkeit gibt, eine Datei zu erstellen, verwendet makepp dazu ein einfaches Verfahren
Bestimmen Sie, welche Regel verwendet werden soll.

· Es ist ein Fehler, widersprüchliche explizite Regeln für die Erstellung einer Datei zu haben.

· Musterregeln und Foreach-Regeln mit Platzhaltern überschreiben niemals explizite Regeln. Daher
Mit expliziten Regeln können Ausnahmen für Musterregeln festgelegt werden. (Beachten Sie das einfach
Die Verwendung einer „:foreach“-Klausel macht etwas nicht zu einer Musterregel. Es muss eine haben
Platzhalter (wie „*“ oder „?“) als Teil des Dateinamens in der „:foreach“-Klausel. Wenn ja
Da es sich lediglich um eine explizite Liste von Dateien handelt, wird sie für jede dieser Dateien als explizite Regel behandelt
Dateien.)

· Wenn widersprüchliche Musterregeln aus verschiedenen Makefiles stammen, Regeln von „näher“
Makefiles überschreiben Regeln von „entfernteren“ Makefiles. „Näher“ bedeutet, dass das Makefile
befindet sich näher am Ziel in der Verzeichnishierarchie (d. h. der Dateiname der
(Ziel relativ zum Verzeichnis, aus dem das Makefile ausgeführt wird, ist kürzer). Wenn dies
Unterscheidet die Makefiles nicht, dann unterscheidet sich die Regel von dem Makefile, das geladen wird
Die neueste Version wird verwendet.

Das bedeutet, dass Sie eine Musterregel angeben können, die für alle Dateien in Ihrem Ordner gilt
den gesamten Verzeichnisbaum nur im Makefile der obersten Ebene, aber dann können Sie ihn überschreiben
ein Makefile auf niedrigerer Ebene. Ihr Makefile der obersten Ebene könnte beispielsweise Folgendes enthalten:

%.o : %.c : foreach **/*.c
$(CC) $(CFLAGS) -c $(Eingabe) -o $(Ausgabe)

und Sie könnten ein Makefile in einem der Unterverzeichnisse haben, das besagt:

%.o : %.c
$(CC) $(SPECIAL_CFLAGS) -c $(Eingabe) -o $(Ausgabe)

· Musterregeln mit einer kürzeren Schlussfolgerungskette werden anderen Mustern vorgezogen
Regeln. Wenn Sie beispielsweise die folgenden Regeln hätten (basierend auf einem Beispiel aus dem
Linux Kernel):

%.sc
$(CC) -s $(Eingabe) -o $(Ausgabe)

%.o: %.s
$(AS) $(Eingabe) -o $(Ausgabe)

%.o: %.c
$(CC) -c $(Eingabe) -o $(Ausgabe)

Wenn wir „xyz.o“ erstellen müssen, können wir entweder die Zwischendatei „.s“ erstellen und dann
Führen Sie das mithilfe der ersten beiden Regeln durch den Assembler, oder wir gehen direkt zu a
„.o“-Datei mit der letzten Regel. Die letzte Regel wird bevorzugt, da es weniger davon gibt
Schritte in der Folgerungskette (eins statt zwei).

· Musterregeln, die später in einem Makefile liegen, überschreiben Musterregeln, die früher liegen. (Das ist
rückwärts von GNU make.) Dies bedeutet, dass Sie Ihre allgemeineren Regeln festlegen sollten
früher und Ihre spezifischeren Regeln später. Zum Beispiel,

%.o: %.c # Allgemeine Kompilierungsregel.
Aktion

special_%.o: special_%.c # Sonderregel für Dateien mit a
andere Aktion # „special_“ Präfix.

Regel Optionen
Manchmal ist es notwendig, zusätzliche Optionen bereitzustellen, um zu ändern, wie makepp das ausführt
Regel. Diese Optionen werden als „:Optionsname-Wert“ entweder in der Zeile mit angegeben
die Abhängigkeiten, oder in der nächsten Zeile.

Wenn Sie die Optionen in separaten Zeilen bereitstellen, können Sie diese möglicherweise nutzen
Makefile mit makepp und einem traditionellen Make. Zum Beispiel,

Ziel: Abhängigkeiten
: Signatur target_newer
Aktionen

funktioniert gut mit einem herkömmlichen Unix-Make, da es die Zeile „:signatur“ interpretiert
als Shell-Befehl, und ein Befehl, der mit einem Doppelpunkt beginnt, bewirkt nichts.

:build_cache /path/to/build/cache
Ziel: Abhängigkeiten
: build_cache /put/cache/files/over/there
Aktionen

Gibt den Pfad zu einem Build-Cache an, der für von dieser Regel erstellte Dateien verwendet werden soll. Das
überschreibt die Wirkung der „build_cache“-Anweisung oder des „--build-cache“-Befehls
Zeilenoption (falls vorhanden) für diese Regel. Einzelheiten zum Build finden Sie unter makepp_build_cache
Caches.

Wenn Sie statt eines Pfades „none“ angeben, deaktivieren Sie hierfür den Build-Cache
besondere Regel. Dies kann nützlich sein, um zu vermeiden, dass Speicherplatz für von Ihnen gespeicherte Dateien verschwendet wird
Sie wissen, dass sie zum Zwischenspeichern nicht nützlich sind, da Sie sehr sicher sind, dass dies niemals der Fall sein wird
wiederverwendet werden oder weil sie so schnell erstellt werden, dass es sich nicht lohnt, sie zwischenzuspeichern.

:build_check build_check_method
Ziel: Abhängigkeiten
: build_check target_newer
Aktionen

Dadurch wird makepp mitgeteilt, welcher Algorithmus verwendet werden soll, um zu entscheiden, ob die Ziele neu erstellt werden müssen.
Weitere Details finden Sie unter makepp_build_check. Dies überschreibt die Wirkung von
„build_check“-Anweisung oder die Befehlszeilenoption „--build-check-method“, falls vorhanden, für
diese Regel.

:env VARIABLE ...
Fügen Sie eine Abhängigkeit von den Werten der benannten Umgebungsvariablen hinzu. Wenn einer von ihnen
vom vorherigen Build abweichen, gelten die Ziele als veraltet, wenn die
Die Methode build_check bestimmt dies. (Alle integrierten Build-Überprüfungsmethoden außer
target_newer respektiert dies.)

VARIABLE kann die Form „Dateiname in PATH_VARIABLE“ (in Anführungszeichen) haben
Ziele gelten als veraltet, wenn das erste Verzeichnis durch Doppelpunkte getrennt ist
Der Wert von PATH_VARIABLE, in dem der Dateiname vorhanden ist, unterscheidet sich vom letzten Build.
Dies kann verwendet werden, um einen Neuaufbau der Ziele zu vermeiden, wenn sich PATH_VARIABLE in einem ändert
irrelevante Weise.

:versenden Befehl ...
Schließen Sie jede Shell-Aktion (aber keine Perl-Aktionen oder Perl-Befehle) in ein „sh -c '...'“ ein.
und stellen Sie ihm den Befehl voran, gehen Sie jedoch davon aus, dass das Ziel nicht vom Befehl abhängt.
Dies ist nützlich, wenn Sie Aktionen an ein Job-Warteschlangensystem senden möchten, das Ergebnis jedoch nicht vorhanden ist
Es wird davon ausgegangen, dass es unabhängig von den Warteschlangenparametern ist und auch davon, ob die Warteschlangenfunktion aktiviert ist
System überhaupt genutzt wird.

:enthalten file_or_pattern
Die Regel variiert je nach Compiler:

%.o : %.c
: %.d einschließen : Signatur C
gcc -MD -c ...

%.o : %.c
: include %.u : Signatur C # IBM verwendet ein anderes Suffix
xlc -M -c ...

sub dependify { # Verwandeln Sie Microsofts Chatter in ein nützliches Format
s/\$/\$\$/g;
s/(Hinweis: einschließlich Datei: *)?(.+?)\r?\n/$1 ? "'$2' " : "'".f_output()."': "/e;
}
%.o : %.c
: %.d einschließen : Signatur C
cl -showIncludes -c ... >$(stem).d
&sed &dependify -o +<$(stem).d

Einige Compiler (Intels ICC, genau wie GCC oben, oder IBMs XLC) können Abhängigkeiten erzeugen
Dateien im Handumdrehen. Das heißt, während sie kompilieren, schreiben sie ein Makefile, das makepp ausführen kann
enthalten. Der Vorteil gegenüber dem Scanner von makepp besteht darin, dass eine 100-prozentige
richtig, wo wir vielleicht nur nahe kommen.

Diese Option nutzt dies auf besondere Weise: Wenn die Datei nicht vorhanden ist, d. h
Normalerweise erfolgt beim ersten Build ein normaler Scanvorgang. Aber wenn die Datei vorhanden ist, nein
Das Scannen erfolgt (weshalb wir oben eine intelligente Signatur angeben) – es erfolgt kein Scanvorgang
zurück zur dummen Standardeinstellung von Zeitstempel und Größe). Stattdessen wird die Datei zuvor eingefügt
die Regel ausführen. Nach erfolgreicher Ausführung der Regel vergisst es, was auch immer es ist
Lesen Sie es beim ersten Mal, da die Datei möglicherweise veraltet ist. Stattdessen heißt es
Überprüfen Sie die Datei erneut, falls sie sich geändert hat, um über aktuelle Build-Informationen zu verfügen.

WARNUNG: Dies ist grundsätzlich unzuverlässig. Die Abhängigkeitsdatei wird von selbst erstellt
Regel, für die es eine Abhängigkeit ist. Andererseits weiß der Compiler alles
Es handelt sich um interne Sub-Includes, die makepp normalerweise ignoriert. Das ist eine Zuverlässigkeit
Vorteil nur für den Fall, dass ein Compiler-Patch nur die Sub-Includes behebt. Der
Der Preis besteht darin, dass makepp am Ende viel mehr Dateien durchsucht, was Zeit kostet.

Es gibt einen Haken, wenn Sie eine „#include“-Anweisung entfernen und die entsprechende Datei:
Es wird immer noch in der Abhängigkeitsdatei vom letzten Mal erwähnt, als es vorhanden war
erforderlich. In einem solchen Fall müssen Sie die Abhängigkeitsdatei bearbeiten, um die Abhängigkeit zu entfernen
was nicht mehr erfüllbar ist.

Diese Funktion kann nicht mit einem Build-Cache verwendet werden, da eine Datei von dort abgerufen wird
erfordert, alles über die Datei zu wissen. Aber eine Abhängigkeitsdatei hängt davon ab
Dateien, von denen Makepp durch das Lesen erfährt. Eine solche zirkuläre Abhängigkeit ist normalerweise nicht gegeben
in einem zuverlässigen Build-System möglich. Dies ist eine Ausnahme, da nach dem Wiederaufbau
und beim erneuten Lesen einer Abhängigkeitsdatei ist alles wieder korrekt.

Wenn Sie Ihre Repositorys einbauen, holt makepp die Abhängigkeitsdatei aus dem
1. Repository, das eines enthält. Dies ist anders als bei anderen Dateien, bei denen die erste Datei benötigt wird
mit der erwarteten Unterschrift. Dies ist besser als bei Build-Caches, wo es an solchen mangelt
Signatur, es kann die Datei nicht einmal finden.

:letzte Möglichkeit
Aktivieren Sie eine Regel mit offenem Ende, z

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

Da eine Regel wie diese eine praktisch unendliche Anzahl von Zielen generieren könnte,
Ein Ziel dieser Regel stimmt nicht mit einer $(Platzhalter)-Funktion oder Musterregel überein, es sei denn
Etwas anderes hat die Regel bereits instanziert, indem es speziell auf das Ziel verwiesen hat.
Wenn außerdem „--rm-stale“ angegeben ist, dann ein Ziel, das von einem vorherigen übrig geblieben ist
makepp run erscheint veraltet, wenn die einzige Möglichkeit zum Erstellen über eine last_chance-Regel besteht
das wurde noch nicht für das Ziel instanziert, was ein wünschenswertes Verhalten ist, weil
Der Build schlägt häufiger fehl, wenn er fälschlicherweise auf einen Platzhalter angewiesen ist
Übereinstimmung mit Zielen aus einem vorherigen Lauf.

Die Option „:last_chance“ soll auf das besondere Verhalten des aufmerksam machen
Regel in Bezug auf passende Platzhalter.

:parser Parser
Dies teilt makepp mit, wie der Befehl zum Erkennen (Einschließen) von Dateien analysiert werden soll. Normalerweise,
makepp errät anhand der Wörter im Befehl selbst, wie das geht (siehe
makepp_scanning für Details). Wenn Makepp jedoch falsch vermutet, möchten Sie es vielleicht tun
Geben Sie den Parser explizit an, etwa so:

%.o: %.abc
: Parser c_compilation
Aktion hier

Dies führt dazu, dass makepp das gleiche Parsing und Scannen durchführt wie für C/C++
Build-Befehle, auch wenn die Aktion nicht als C-Kompilierung erkannt wird.

Der Standardparser hängt vom Befehl ab. Wenn Sie keine „:parser“-Option angeben,
dann wird das erste Wort jedes Befehls untersucht. Zum Beispiel für eine Kompilierung oder einen Link
Befehl, makepp verwendet den Parser „c_compilation“; oder wenn der Befehl wie folgt aussieht
GNU-Variante „gcc_compilation“. Wenn kein Parser gefunden wird, wird der Parser „none“ verwendet. Für
Weitere Details dazu oder wenn Sie Ihren eigenen Parser schreiben oder Makepps ändern möchten
Standardparser finden Sie unter makepp_scanning.

Beachten Sie, dass dies für jeden Befehl in der Regel gilt, der möglicherweise nicht Ihren Wünschen entspricht:

%.o: %.c: Parser-C-Kompilierung
@echo 'Building $(output)'
@funny_cc ...

Dadurch wird „echo“ auch als Compiler interpretiert und sein Argument „Building“ abgeleitet
mymodule.o' als implizite Abhängigkeit. Dies wird zu der Beschwerde führen, dass es
weiß nicht, wie man eine solche Datei erstellt. In diesem Fall wären Sie besser dran
„register_parser“. Dort finden Sie eine Erklärung wie Parser kann entweder als angegeben werden
Klassenname oder als Funktionsname.

:Unterschrift signaturmethode
Ziel: Abhängigkeiten
: Signatur MD5
Aktionen

Dies teilt makepp mit, welchen Algorithmus es verwenden soll, um festzustellen, ob sich die Abhängigkeiten geändert haben.
Weitere Informationen finden Sie unter makepp_signatures. Signaturmethoden, die im enthalten sind
Die makepp-Distributionen sind „plain“, „md5“, „C“ oder „c_compilation_md5“ und
„shared_object“. Dies überschreibt alle mit „-m“ oder angegebenen Signaturmethoden
„--signature-method“-Befehlszeilenoptionen oder mit der „signature“-Anweisung.

Spezial Zeichen
Makepp kann Dateinamen unterstützen, die Sonderzeichen wie einen Doppelpunkt oder ein Leerzeichen enthalten.
Angenommen, Sie möchten beispielsweise aus der Datei „b:thing“ eine Datei mit dem Namen „a:thing“ erstellen.
Sie können die Regel nicht so schreiben:

a:thing : b:thing # Dies ist ein Syntaxfehler
&cat $(Eingabe) -o $(Ausgabe)

weil makepp nicht weiß, welche Doppelpunkte Ziele von Abhängigkeiten trennen und welche
Teil der Dateinamen. Setzen Sie den Namen stattdessen einfach in Anführungszeichen, etwa so:

„a:thing“ : „b:thing“
&cat $(Eingabe) -o $(Ausgabe)

Jetzt ist die Regel eindeutig.

Die Zitatsyntax von Makepp ist der der Shell ziemlich ähnlich. Sie können beispielsweise Single verwenden
Geben Sie Anführungszeichen anstelle von doppelten Anführungszeichen ein, oder Sie können Sonderzeichen mit einem Backslash maskieren:

a\:thing : 'b:thing'
&cat $(Eingabe) -o $(Ausgabe)

Nehmen wir zum Beispiel an, dass Ihr Dateiname „'“!;\$“ lautet. Warum möchten Sie nun einen solchen Dateinamen?
Ich weiß es nicht, aber es gibt mehrere Möglichkeiten, wie Sie es für makepp (und die Shell) angeben können:

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

Achten Sie darauf, wann makepp Anführungszeichen entfernt und wann die Shell dies tut. Makepp schaut zu
Zitate nur in folgenden Fällen:

· in der „ifeq“-Testfamilie

· vor und nach dem Regeldoppelpunkt

· in einem in makepp integrierten Befehl

· in einer Funktion, die sich auf Dateien bezieht

Im Gegensatz zur Shell erweitert makepp Anführungszeichen nicht, während es sie einer Variablen zuweist. Daher
Die folgenden Regeln sind identisch:

FILE = 'Name mit Leerzeichen'
x := $(print $(FILE)) # nur um zu überprüfen, ob noch Anführungszeichen vorhanden sind
$(FILE): # Anführungszeichen um einzelne Dateien, die von makepp entfernt wurden
&echo hallo -o$(FILE) # Anführungszeichen um einzelne Dateien, die von makepp entfernt wurden
echo there >>$(FILE) # Anführungszeichen um einzelne Dateien, die von Shell entfernt wurden
'Name mit Leerzeichen':
&echo hallo -o'name mit Leerzeichen'
echo there >>'$(output)' # Anführungszeichen wurden oben entfernt, fügen Sie sie erneut hinzu

Beachten Sie, dass (im Gegensatz zur Shell) Variablen, die mit „$“ beginnen, auch innerhalb von Single erweitert werden
Zitate. Dollarzeichen können nicht durch Anführungszeichen oder Backslashes geschützt werden. Um ein Literal zu bekommen
Dollarzeichen, verwenden Sie ein doppeltes Dollarzeichen, z.

$(falsche alle):
@&echo Das ist ein Dollarzeichen: $$
@for val in abcd; echo $$val; Erledigt

Im Allgemeinen sollten Sie in der Lage sein, mit fast jedem Sonderzeichen umzugehen, indem Sie es zitieren
irgendwie. Dazu gehören Leerzeichen, Steuerzeichen usw. Beachten Sie jedoch, dass at
Derzeit ist das Entfernen von Kommentaren durch Makepp etwas vereinfacht und enthält alle „#“-Zeichen
Vorangestellte Leerzeichen werden als Kommentare interpretiert, unabhängig davon, wie sie zitiert werden.

Wenn ein Ziel- oder Abhängigkeitsname in eine automatische Variable wie „$(output)“ eingefügt wird, dann
Die Anführungszeichen und alle Backslashes werden entfernt. Dies bedeutet, dass, wenn Sie darauf verweisen möchten
Wenn Sie den Dateinamen in den Aktionen verwenden, müssen Sie ihn wahrscheinlich erneut zitieren, etwa so:

„ein Dateiname mit Leerzeichen“:
echo „Spezielle Inhalte“ > „$@“

Wenn Sie $@ nicht in Anführungszeichen setzen, erkennt die Shell den Befehl

echo „Spezielle Inhalte“ > ein Dateiname mit Leerzeichen

Dadurch wird die Zeichenfolge „Spezieller Inhaltsdateiname mit Leerzeichen“ in die aufgerufene Datei geschrieben a.
Das ist wahrscheinlich nicht das, was Sie wollen.

Verwenden Sie makepp_rules online über die Dienste von onworks.net