makepp_statements – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

makepp_statements – Verschiedene Anweisungen in einem Makefile

BESCHREIBUNG

A: Autoload, B: build_cache,
build_check, D: "definieren", E: Export, G: gesamt, I: ifdef,
ifeq,
ifmakeperl,
ifndef,
ifneq,
ifnsys,
wenn nicht wahr,
ifperl,
ifsys,
Wenn wahr,
-enthalten,
enthalten,
_enthalten, L: Load_makefile, M: machen,
makeperl,
makesub, N: „no_implicit_load“, P: Perl,
„perl_begin“,
vorgefertigt, R: register_command_parser,
register_input_suffix,
register_parser,
Repository,
Laufzeit, S: Unterschrift,
„sub“, V: vpath

Eine Anweisung ist jede Zeile, die mit einem Wort beginnt, das kein „:“ enthält. (Ein Doppelpunkt
impliziert, dass die Zeile eine Regel ist. Dies sind beispielsweise Anweisungen:

extra_rules.mk einschließen
Unterverzeichnis „load_makefile“.

Makepp verfügt über eine Reihe integrierter Anweisungen, die Sie gelegentlich verwenden müssen.

Beachten Sie, dass Sie überall dort, wo Sie einen Unterstrich sehen, auch einen Bindestrich verwenden können, da makepp konvertiert
Bindestriche werden in Anweisungsnamen zu Unterstrichen.

Bedingte
Bedingungen sind spezielle Anweisungen, die steuern, welche Zeilen in der Makepp-Datei enthalten sind
tatsächlich gesehen. Die einfachste Form (wobei „ifxxx“ für eine der Bedingungen steht
(siehe unten dokumentierte Aussagen) ist:

ifxxx ...
Zeilen werden angezeigt, wenn die Aussage als wahr ausgewertet wird
Endif

oder:

ifxxx ...
Zeilen werden angezeigt, wenn die Aussage als wahr ausgewertet wird
sonst
Zeilen werden angezeigt, wenn die Aussage als falsch ausgewertet wird
Endif

Es besteht auch die Möglichkeit, komplexe Kombinationen wie diese durchzuführen:

ifxxx ...
und ifxxx ...
und ifxxx ...
oder ifxxx ...
und ifxxx ...
Zeilen werden angezeigt, wenn die kombinierten Aussagen als wahr ausgewertet werden
sonst ifxxx ...
oder ifxxx ...
und ifxxx ...
Zeilen werden angezeigt, wenn die erste Kombination als falsch ausgewertet wird
und diese kombinierten Aussagen werden als wahr bewertet
sonst
Zeilen werden angezeigt, wenn die obigen Aussagen als falsch ausgewertet werden
Endif

Wie aus der Einrückung hervorgeht, "und" hat höhere Priorität als "oder". Mit anderen Worten
an "oder" wählt zwischen zwei Gruppen von "und"`s. Es kann eine beliebige Anzahl von „und ifxxx“`s geben,
„or ifxxx“`s und „else ifxxx“`s.

Die „ifxxx“-Bedingungsanweisungen sind insofern einzigartig, als sie in der Mitte der Regel auftreten können
Aktionen wie im obigen Beispiel ausführen, ohne die Regel zu verletzen.

ifeq string1, string2
ifneq string1, string2
ifeq ($(STR1),$(STR2))
Makefile-Zeilen, wenn wahr
sonst
Makefile-Zeilen, wenn falsch
Endif

Wenn die beiden Zeichenfolgen genau übereinstimmen (mit Ausnahme von führenden oder nachgestellten Leerzeichen), dann wird die
erster Zeilensatz wird verwendet; andernfalls wird die zweite verwendet. Die else-Klausel lautet
optional.

Es gibt zwei weitere akzeptable Syntaxen für die Anweisungen „ifeq“ und „ifneq“:

ifeq string1, string2
ifeq string1 string2

die gleichwertig sind. Natürlich können Sie die Zeichenfolgen nach Bedarf zitieren.

„ifeq“ und seine Freunde „ifneq“, „ifdef“, „ifndef“, „ifperl“, „ifmakeperl“, „ifsys“ und
„iftrue“ ist vor allem dann nützlich, wenn Sie ein Programm unter mehreren verschiedenen Bedingungen erstellen müssen
Bedingungen. Zum Beispiel,

BUILD_TYPE := debug # „debug“ oder „produktion“

ifeq ($(BUILD_TYPE), debuggen)
CFLAGS := -g
sonst
CFLAGS := -O2
Endif

Programm: *.o
$(CC) $(CFLAGS) $(Eingaben) -o $(Ausgabe) $(LIBS)
ifeq ($(BUILD_TYPE), Produktion)
Strip $(Ausgabe)
Endif

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

Wenn es sich um einen Produktions-Build handelt, werden alle Dateien stattdessen mit der Option „-O2“ kompiliert
die Option „-g“. Darüber hinaus wird das Programm „strip“ auf der resultierenden Binärdatei (in) ausgeführt
(falls Sie zufällig eine Verknüpfung mit einigen Bibliotheken hergestellt haben, die im Debug-Modus kompiliert wurden).

Manchmal ist es einfacher, die Funktion „$(if)“ oder die Funktion „$(perl)“ zu verwenden
anstelle einer „ifeq“-Anweisung.

Wenn Sie nur sehen möchten, ob ein Symbol leer ist oder nicht, müssen Sie nur a angeben
einzelnes Argument, etwa so:

ifneq $(EXE_SUFFIX)
# Was tun, wenn $(EXE_SUFFIX) nicht leer ist?
Endif

wenndef VARIABLE ...
ifndef VARIABLE ...
Diese Anweisungen funktionieren mit dem Unterschied, dass sie analog zu den Anweisungen „ifeq“ und „ifneq“ sind
Sie testen, ob eine der Variablen definiert ist oder nicht (d. h. keine).
definiert). Eine Variable ist definiert, wenn:

· Es wurde zuvor im Makefile ein Wert mit einer Zuweisung angegeben. Sehen
makepp_variables für Details.

· Es wurde ein Wert als Perl-Variable in einem „perl_begin“-Block angegeben.

· Die Variable ist in der Umgebung vorhanden.

· Die Variable ist in der Befehlszeile vorhanden, z. B. um Ihr Makefile aufzurufen
getippt

makepp CFLAGS=-O2

Zum Beispiel,

ifndef CFLAGS
CFLAGS := -g
Endif

In diesem Fall wird „CFLAGS“ nur dann auf „-g“ gesetzt, wenn es nicht bereits definiert wurde. Beachten Sie, dass
Diese Anweisung hätte genauso gut mit der Zuweisung „?=“ geschrieben werden können
Dies:

CFLAGS ?= -g

ifperl Perlcode
ifmakeperl Perlcode
Diese Anweisungen funktionieren mit dem Unterschied, dass sie analog zu den Anweisungen „ifeq“ und „ifneq“ sind
Die Tests sind in Perl. Die erste Variante ist reiner Perl-Code, während die zweite Variante
Übergibt die Anweisung zunächst einer Variablenerweiterung im Make-Stil.

VERSION := 3.0
# VERSION ist automatisch auch eine Perl-Variable:
ifperl $VERSION <= 2
CPPFLAGS := -DNEW
Endif
# Anführungszeichen für CFLAGS erforderlich, da Perl nur den Wert sieht:
ifmakeperl my $$x = '$(CFLAGS)'; $$x =~ /-g/
CFLAGS := -g -O2
Endif

ifsys Platzhalter ...
ifnsys Platzhalter ...
Testet, ob das aktuelle System-Makepp, auf dem es ausgeführt wird, mit einem der Platzhalter übereinstimmt oder nicht
irgendein (also keins).

ifsys i[3-6]86
und ifsys Linux SunOS
... # Eine Intel-Plattform mit Linux oder Solaris
sonst ifnsys sparc power*
... # Noch Sparc oder PowerPC
Endif

Es gibt bis zu sechs verschiedene Saiten, gegen die Sie antreten können. Die eigentlichen Saiten sind
nicht standardisiert. Drei davon spiegeln wider, wofür die Perl-Instanz gebaut wurde (nicht).
notwendigerweise derselbe wie dort, wo er ausgeführt wird), und die anderen kommen vom System und
alle variieren stark in der Form. Sie können alles finden, was mit der aktuellen Plattform übereinstimmt
Geben Sie den folgenden Befehl in die Shell ein:

perl -MConfig -e'print "$^O @Config{qw(archname myarchname)} "'; uname -mps

Wenn wahr Ausdruck
wenn nicht wahr Ausdruck
Testet, ob der Ausdruck einen anderen Wert als Null oder die leere Zeichenfolge ergibt.

Andere Multiline Statements
Bedingungen können eine ganze mehrzeilige Anweisung steuern, sie dürfen jedoch nicht in einer solchen enthalten sein
Aussage.

definieren
{export|global|override}* definieren
VARIABLE [Zuweisungsoperator] definieren
Variablenwert Zeile 1
Variablenwert Zeile 2
Endef

Definiert den Wert von $(VARIABLE) als alle Zeilen zwischen der „define“-Anweisung und der
„endef“-Anweisung. Siehe mehrzeilige Variablen. Die Schlüsselwörter „export“ und „global“ dürfen
nicht gleichzeitig gegeben werden.

perl_begin
Dies ist dasselbe wie „Perl“, verwendet jedoch die GNU-Make-Style-Anweisungssyntax. Diese Aussage
führt einen Codeblock ein, der von Perl wörtlich interpretiert wird. Es kann nützlich sein
zum Definieren von Funktionen, aber Sie können dies präziser mit der „sub“-Anweisung tun.
Ein Perl-Codeblock in Ihrem Makefile kann hilfreich sein, um einfachere Aktionen auszuführen
in Perl als mit makepp-Funktionen und -Regeln.

Der Rest der Zeile nach der „perl_begin“-Anweisung wird ignoriert. Alle Texte
bis eine Zeile, die am linken Rand mit „perl_end“ beginnt, wörtlich an die gesendet wird
Perl-Interpreter. Vor „perl_end“ dürfen keine Leerzeichen stehen.

Ein Beispiel, für das ich dies verwende, ist das Erstellen von Verzeichnissen, die möglicherweise nicht unbedingt erforderlich sind
existieren. In Makefiles ist es üblich, alle .o-Dateien in einem Unterverzeichnis abzulegen (z. B. a
Verzeichnis mit einem Namen i386, oder auch Sparc, oder etwas, das vom Maschinentyp abhängt).
Was aber, wenn das Verzeichnis noch nicht existiert? Sie können jede .o-Datei von der abhängig machen
Unterverzeichnis und fügen Sie eine Regel zum Erstellen des Unterverzeichnisses ein. Aber es ist viel einfacher
um dies zu tun:

OBJDIR := $(ARCH) # Wo wir .o-Dateien ablegen.
perl_begin
-d $OBJDIR oder mkdir $OBJDIR; # Stellen Sie sicher, dass das Verzeichnis existiert.
perl_end

Auf diese Weise wird jedes Mal, wenn das Makefile ausgeführt wird, das Unterverzeichnis erstellt, wenn dies der Fall ist
nicht existieren.

Einige Operationen lassen sich besser durch reguläre Ausdrücke ausdrücken als die von makepp
Textfunktionen. Zum Beispiel,

perl_begin
if ($ARCH =~ /^i[56]86/) { # Sie könnten dies tun mit: ifsys i[56]86
$CFLAGS = '-O6 -malign-double'; # Auf Intel-Maschinen > 486, dort
# ist eine erhebliche Geschwindigkeitseinbuße
# für Doubles, die keine Quadwords sind
# ausgerichtet.
} Else {
$CFLAGS = '-O6';
}
perl_end

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

Auf jede Make-Variable kann direkt als Perl-Skalar zugegriffen werden. In diesem Fall haben wir festgelegt
Der Wert von „CFLAGS“ kann je nach Übereinstimmung mit einem regulären Ausdruck unterschiedlich sein
Architekturfahnen.

Als letztes Beispiel: Auf einige Informationen kann direkt aus Perl leichter zugegriffen werden
als von makepp. Sie können beispielsweise auf alle Konfigurationsinformationen zugreifen
dass Perl über Ihr System Bescheid weiß, einschließlich der Erstellung von gemeinsam genutzten Bibliotheken usw.
(Geben Sie „perldoc Config“ ein, wenn Sie sehen möchten, welche Konfigurationsinformationen Perl hat
verfügbar.)

perl_begin

Konfig verwenden;

$ARCH = $Config{'archname'}; # Nutzen Sie Perls Wissen über die Architektur.
$CC = $Config{'cc'}; # Verwenden Sie denselben C-Compiler wie Perl.
$SHARED_OBJ_CFLAGS = $Config{'cccdlflags'};
# Flags, die zum Kompilieren von Objekten benötigt werden, die dies tun
# in eine gemeinsam genutzte Bibliothek gehen.
$SHARED_OBJ_LDFLAGS = $Config{'ccdlflags'} . " " . $Config{'lddflags'};
# Linker-Flags zum Erstellen einer gemeinsam genutzten Bibliothek.
$SHARED_CC_LINK = $Config{'ld'}; # Befehl zum Erstellen gemeinsam genutzter Bibliotheken.

$SHARED_EXTENSION = $Config{'dlext'}; # Erweiterung gemeinsam genutzter Bibliotheken.
perl_end

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

libmylib.$(DLEXT): *.o
$(SHARED_CC_LINK) $(Eingaben) -o $(Ausgabe) $(SHARED_OBJ_LDFLAGS)

Beachten Sie, wie wir im Perl-Block eine Reihe von Variablen definieren und diese dann verwenden
anschließend im Rest des Makefiles. Sie können die volle Kraft des Perls nutzen
Interpreter, um Ihre Variablen auf beliebig komplizierte Weise festzulegen. Sie können Shell ausführen
Befehle aus Ihrem Perl-Code ausführen, auf eine Datenbank zugreifen oder was auch immer Sie möchten.

perl Perlcode
makeperl Perlcode
Dies ist dasselbe wie „perl_begin“, verwendet jedoch geschweifte Klammern im Perl-Stil. Die erste Variante ist
reiner Perl-Code, während die zweite Variante die Anweisung zunächst über Make weiterleitet.
Stilvariablenerweiterung. Beachten Sie, dass die Schwierigkeit, Perls Klammern zu analysieren, führend ist
zur folgenden einfachen Heuristik:

· Wenn in derselben oder der nächsten Zeile eine doppelte öffnende geschweifte Klammer gefunden wird, erfolgt eine doppelte schließende Klammer
Eine geschweifte Klammer beendet den Block. Es muss am Anfang einer Zeile stehen, kann aber sein
mit vorangestelltem Leerzeichen.

· Andernfalls ist dies eine Eins, wenn die schließende geschweifte Klammer ganz am Ende der „Perl“-Zeile steht
Liner

· Andernfalls muss die schließende Klammer ganz am Anfang einer folgenden Zeile stehen.
dh kein führendes Leerzeichen.

Eine effiziente Möglichkeit zum Aufrufen von Perl-Skripten finden Sie unter „Ausführen“. Im Gegensatz zur Funktion „$(perl)“
Der Rückgabewert dieses Blocks wird ignoriert.

perl { print "diesen Punkt im Makefile übergeben\n" }

perl
{
print "und dieses auch\n";
}

ifdef NOISY
perl {{
print „sowie dieses\n“
}}
Endif

Sie können den Perl-Debugger für Ihren eingebetteten Code verwenden, indem Sie makepp selbst im ausführen
Debugger, wobei ... die Argumente sind, falls vorhanden, die Sie normalerweise übergeben:

perl -d -S mpp ...

Es ist schwierig, Haltepunkte in Perl-Code zu setzen, der nicht geladen wurde. Du kannst arbeiten
Um dies zu umgehen, fügen Sie diese Zeile direkt vor der gewünschten Stelle in Ihr eingebettetes Perl ein
brechen:

$DB::single = 1;

Anschließend können Sie an der Eingabeaufforderung des Debuggers „c“ eingeben, um bis zu diesem Punkt fortzufahren.

unten
makesub
Diese Anweisung bietet eine Möglichkeit, eine Perl-Subroutine in Ihrem Makefile zu definieren. Der
Die erste Variante ist reiner Perl-Code, während die zweite Variante zuerst die Anweisung übergibt
durch Variablenerweiterung im Make-Stil. Die Syntax ist identisch mit der von Perl
sub-Anweisung, außer dass Prototypen bedeutungslos sind.

Zu den drei Möglichkeiten, die Körperspange anzubringen, siehe die Erklärung unter
die „Perl“-Anweisung.

Eine Perl-Subroutine wird immer dann aufgerufen, wenn eine Anweisung angezeigt wird oder wenn ein Ausdruck wie
„$(Name Wörter)“ wird angezeigt. Angenommen, Sie müssen aus irgendeinem Grund laden
den Inhalt einer Datei in eine Make-Variable. (Sie könnten dies tun, indem Sie sagen
„$(Shell-Cat-Dateiname)“, aber es ist möglich, dies zu tun, ohne jemals die Shell aufzurufen.)
Dies können Sie erreichen, indem Sie Folgendes in Ihr Makefile einfügen:

sub f_file_contents {
my ($file) = @_; # Benennen Sie das Argument.
öffne mein $fh, $file oder die "$file: $!\n";
local $/ = undef; # Slurp-Datei in einem Lesevorgang.
<$fh>;
}

ifdef NEWSUB
makesub f_VAR2
{{
$(VAR) * 2;
}}
Endif

makesub f_VAR1 { $(VAR) + 1 }

Nachdem diese Funktion definiert ist, können Sie nun schreiben

X = $(file_contents Dateiname) # entspricht dem eingebauten $(&cat Dateiname)

und die Variable „$(X)“ ruft bei jedem Zugriff den Inhalt der angegebenen Datei ab
erweitert. Verwenden Sie „:=", um dies genau einmal zu tun, oder „;=", um dies höchstens einmal zu tun.

Weitere Details und Beispiele finden Sie unter makepp_extending.

Einfacher Statements
Autoload Dateinamen ...
Gibt ein oder mehrere Makefiles an, die geladen werden sollen, falls versucht wird, eine Regel für eine Datei in zu finden
Dieses Verzeichnis schlägt sonst fehl. Dies ist nützlich, wenn das Makefile Regeln enthält, deren
Definitionen hängen (möglicherweise indirekt) von einer Datei in einem anderen Verzeichnis ab, die davon abhängt
(möglicherweise indirekt) auf andere Dateien in diesem Verzeichnis (erstellt durch Regeln, die dies tun). nicht
hängen von der Datei im anderen Verzeichnis ab).

Zum Beispiel dein Makeppfile könnte so aussehen:

Regeln zum Erstellen von Dateien, von denen das andere Verzeichnis/x abhängt

more_rules.makeppfile: otherdir/x
action-to-build-more_rules.makeppfile

autoload more_rules.makeppfile

Beachten Sie, dass wir „autoload“ hier nicht zuverlässig durch „include“ ersetzen können, denn if
etwas anderes als die Regel für more_rules.makeppfile versucht zu bauen otherdir/x
zuerst dann more_rules.makeppfile wird wahrscheinlich daran scheitern otherdir/x wird nicht existieren
noch, denn es gibt bereits einen Versuch, es zu bauen, wann Makeppfile is
implizit in seinem Namen geladen.

WARNUNG: Seien Sie sehr vorsichtig, wenn Sie in einem automatisch geladenen Makefile Dinge tun, die das ändern
Verhalten von Regeln in den anderen Makefile(s) des Verzeichnisses, da dies dazu führen wird
Das Verhalten hängt davon ab, ob ein zuvor erstelltes Ziel Makefiles dazu veranlasst hat oder nicht
automatisch geladen werden.

build_cache /path/to/build/cache
[global] build_cache /path/to/build/cache
Gibt einen Pfad zu einem Build-Cache an. Weitere Informationen finden Sie unter makepp_build_cache. Der Bau
Cache muss bereits vorhanden sein; siehe „So verwalten Sie einen Build-Cache“ in makepp_build_cache für
wie man es überhaupt schafft. Eine „build_cache“-Anweisung in einem Makefile überschreibt
die Befehlszeilenoption „--build-cache“ für Regeln im Makefile, kann aber sein
wird durch den Regelmodifikator „:build_cache“ auf Regelbasis überschrieben.

Das Schlüsselwort „global“ kann dieser Anweisung mit der gleichen Wirkung wie dem Befehl vorangestellt werden
line-Option, dh der Build-Cache gilt in jedem Makefile. Das sollte am besten sein
gegeben in a RootMakeppfile um sicherzugehen, dass es früh genug gesehen wird.

Geben Sie „none“ anstelle eines Pfads zu einem Verzeichnis an, wenn Sie den Build-Cache deaktivieren möchten
für alle Regeln in diesem Makefile.

build_check build_check_method
[global] build_check build_check_method
Gibt die standardmäßige Build-Überprüfungsmethode für alle Regeln in diesem Makefile an. Sehen
makepp_build_check für Details. Die Anweisung „build_check“ überschreibt die
Befehlszeilenoption „--build-check-method“ für alle Regeln im Makefile, kann aber sein
Wird durch den Modifikator „:build_check“ auf Regelbasis überschrieben.

Das Schlüsselwort „global“ kann dieser Anweisung mit der gleichen Wirkung wie dem Befehl vorangestellt werden
line-Option, d. h. die Build-Check-Methode gilt in jedem Makefile, das dies nicht tut
seine eigene angeben. Dies sollte am besten in einem angegeben werden RootMakeppfile um sicher zu sein, dass es so ist
früh genug gesehen.

Geben Sie „build_check default“ anstelle eines Namens an, wenn Sie zur Standardeinstellung zurückkehren möchten.
Mit dem Schlüsselwort „global“ bedeutet dies die Methode „exact_match“, andernfalls wird die Methode zurückgesetzt
Das aktuelle Makefile weist darauf hin, dass es keine eigene spezifische Methode gibt.

exportieren VAR ...
exportieren Zuordnung
export PATH := $(PWD):$(PATH)

Markiert die angegebenen Variablen für den Export in Unterprozesse. Siehe Variablen festlegen.

globale VAR ...
globale Zuordnung
global MYPROJECT.INFO = Informationen, die in allen Makefiles angezeigt werden

Markiert die angegebenen Variablen als global für alle Makefiles. Siehe Variablen festlegen.

das Makefile
Dadurch wird der Inhalt eines anderen Makefiles in das aktuelle Makefile eingefügt. Es kann sein
nützlich, wenn Sie Boilerplate-Dateien mit einer Reihe von Regeln oder Variablen haben, und zwar jeweils
Im Verzeichnis müssen nur wenige Änderungen vorgenommen werden. Die „include“-Anweisung wird ebenfalls verwendet
Wird häufig in herkömmlichen Marken in Verbindung mit der automatischen Include-Datei verwendet
Scannern, aber mit makepp ist dies nicht mehr notwendig.

„include“ berücksichtigt zuerst das aktuelle Verzeichnis und dann das übergeordnete Verzeichnis des aktuellen
Verzeichnis, dann sein übergeordnetes Verzeichnis usw. Es hört auf, Verzeichnisse zu berücksichtigen, wenn es das erreicht
Stammverzeichnis des Dateisystems oder wenn sich die Geräte-ID des Dateisystems ändert. (Das bedeutet, dass
Es werden keine Dateien gefunden, die sich in anderen NFS-Mounts befinden. Dadurch sollen Probleme vermieden werden
Netzwerkdateisysteme oder Automounter und tote Server.) Wenn keine Datei gefunden wird
Wenn die Suche gestoppt wird, sucht sie nach dem Vornamen und sucht dann in den makepp-Daten
Verzeichnis (/usr/local/share/makepp wenn Sie makepp installiert haben Verzeichnis / usr / local) für einen von
die Include-Dateien, die mit makepp geliefert werden.

Wenn Sie in jedes Makefile in einem ganzen Verzeichnis eine Vorlagendatei einschließen möchten
Hierarchie können Sie Ihre Makefile-Vorlage im obersten Verzeichnis platzieren. Die Makefiles
müssen nicht genau wissen, wo sie in der Hierarchie stehen; Jedes Makefile kann enthalten
eine Zeile wie diese:

Standard_definitions.mk einschließen

statt etwas Komplizierteres, etwa so:

include ../../../standard_definitions.mk # Ist das die richtige Anzahl von ..?

Sie können so viele Dateien angeben, wie Sie möchten, und Variablen sind zulässig:

Datei1 Datei2 Datei3 einschließen $(other_include_files)

Wenn Sie an einem Build arbeiten, der sowohl mit GNU make als auch mit makepp funktionieren muss,
Manchmal ist es praktisch, genau identische Makefiles, aber ein anderes Include zu haben
Datei. Beispielsweise können alle Ihre Makefiles eine Zeile wie diese enthalten:

schließen Sie $(TOPDIR)/standard_rules.mk ein

und du willst standard_rules.mk für GNU make und makepp unterschiedlich sein. Zu erleichtern
Dies ist die „include“-Anweisung zuerst sucht nach einer Datei mit dem Suffix .makepp bevor
Ich suche nach der Datei, nach der Sie gefragt haben. In diesem Fall würde zunächst nach einer Datei gesucht
namens standard_rules.mk.makepp, und wenn das existiert, würde es es stattdessen laden
standard_rules.mk. Auf diese Weise wird das Makefile geladen, wenn Sie es mit GNU make ausführen
standard_rules.mk, aber mit makepp wird es geladen standard_rules.mk.makepp.

Da viele ältere Dateien die Regel zum Generieren einer Include-Datei nach dem Include festlegen
Anweisung wird makepp Entscheidungen über nicht vorhandene oder veraltete Includes bis zum Ende aufschieben
des Makefile-Ladens. Das heißt, es sei denn, es wird mit „--rm-stale“ aufgerufen. Für ebenso viele
Mal, wenn sich die Situation bis dahin verbessert hat (weil eine Regel aufgetaucht ist), wird makepp es tun
Laden Sie das Makefile neu, wodurch möglicherweise erneut weitere solcher Regeln angezeigt werden. Das ist offensichtlich
eine ineffiziente Methode zum Laden von Makefiles, also versuchen Sie, dies zu vermeiden. Schlimmer noch, wenn Ihr Makefile
Das Laden hat Nebenwirkungen (wie das Anhängen an eine globale Variable oder eine Zeile wie
„do_it_now := $(shell cat a >>b)“ oder sein Makepp-Äquivalent „&cat a -o>>b“) werden sie tun
Dies passiert so oft, wie das Makefile geladen werden muss. Versuchen Sie also, dies zu vermeiden!

_enthalten Makefile
-einschließen Makefile
Die Anweisung „_include“ ist eine Nebenvariante von „include“ und schließt die Datei ein, sofern sie vorhanden ist
Wenn dies nicht der Fall ist, wird jedoch kein schwerwiegender Fehler generiert. Früher war es die „_include“-Anweisung
ist wichtig für das Scannen von Include-Dateien mit GNU Make, ist aber für makepp weniger nützlich.

Load_makefile /some/directory/somewhere/Makefile
Load_makefile Unterverzeichnis
Load_makefile VAR1=Wert1 VAR2=Wert2 Unterverzeichnis
Diese Anweisung bewirkt, dass makepp in das Verzeichnis wechselt, das das Makefile enthält, und es lädt
seine Regeln in die interne Datenbank von makepp. Wenn Sie stattdessen nur ein Verzeichnis angeben
ein Makefile, „load_makefile“ sucht darin nach „Makeppfile“, „makefile“ oder „Makefile“.
Verzeichnis.

Alle Variablen, die Sie mit der Syntax „VAR=Wert“ (oder „VAR="Wert1 Wert2") angeben, sind
an die geladenen Makefiles übergeben. Sie überschreiben einfach alle Einstellungen in diesen Makefiles
als ob Sie sie in der Befehlszeile eingegeben hätten.

Die Verwendung von „load_makefile“ unterscheidet sich vom Befehl

Verzeichnis/Makefile einschließen

In zwei Wegen. Erstens überträgt „load_makefile“ keine Variablen von oben.
Ebenen-Makefile in das untergeordnete Makefile einfügen; Jedes Makefile existiert für sich
Namensraum. Das untergeordnete Makefile kann die Variablen in der obersten Ebene nicht beeinflussen
Makefile in irgendeiner Weise.

Zweitens wird jeder Build-Befehl mit dem Verzeichnis der Makefile-Datei versehen, aus der er stammt
aus. Wenn makepp eine Regel aus einem anderen Makefile ausführt, wird zunächst eine CD in die erstellt
Verzeichnis, das dieses Makefile enthält, bevor Sie den Befehl ausführen. Makefiles welche sind
die mit der „include“-Anweisung gesehen werden, werden tatsächlich als Teil des Makefiles behandelt
Sie wurden eingeschlossen und daher sind ihre Regeln nicht mit einem anderen Verzeichnis gekennzeichnet.

Normalerweise müssen Sie ein Makefile nicht explizit laden, es sei denn, es hat einen ungewöhnlichen Namen.
oder es hat Ziele, die nicht im selben Verzeichnis wie das Makefile enthalten sind
selbst, oder Sie haben das implizite Laden von Makefiles deaktiviert. Standardmäßig, wenn makepp ist
Sie versuchen, eine Datei zu erstellen und haben keine Regel zum Erstellen, oder wenn eine Datei ausgewertet wird
Wenn Sie einen Dateinamen mit Platzhalter in einem Verzeichnis angeben, wird automatisch versucht, ein Makefile zu laden
aus diesem Verzeichnis. Weitere Informationen finden Sie unter „Tipps für mehrere Verzeichnisse“ in makepp_cookbook
beim Erstellen mit mehreren Verzeichnissen.

Sie können „load_makefile“ nicht verwenden, um mehrere Makefiles zu laden, die für dasselbe gelten
Verzeichnis. Verwenden Sie „include“ für mehrere Teile des Makefiles, die für dasselbe gelten
Verzeichnis und „load_makefile“ für Makefiles, die für verschiedene Verzeichnisse gelten.

no_implicit_load
Diese Anweisung deaktiviert das implizite Laden von Makefiles aus einer Reihe von Verzeichnissen.
Dies kann nützlich sein, wenn Sie Makefiles automatisch aus den meisten Verzeichnissen laden möchten.
Es gibt jedoch einige Verzeichnisse, in die Makepp aus verschiedenen Gründen nicht gelangen soll
Versuchen Sie ein Update. (Möglicherweise enthält das Verzeichnis beispielsweise ein Makefile für eine andere Version
von make, was makepp nicht versteht.) Zum Beispiel:

no_implicit_load dir1 dir2/*

Die obige Anweisung deaktiviert das implizite Laden für Makefiles in „dir1“. und alle of
seine Unterverzeichnisse. Außerdem wird das implizite Laden von Makefiles für alle deaktiviert
Unterverzeichnisse von „dir2“ (und allen Unterverzeichnissen), jedoch nicht für „dir2“ selbst.

Sie können in der Anweisung Platzhalter verwenden. Nicht-Verzeichnisdateien, die dem Platzhalter entsprechen
werden ignoriert. Sie können Funktionen auch verwenden, um die von Ihnen verwendeten Verzeichnisse weiter zu spezifizieren
interessieren sich z.B. für

no_implicit_load $(filter-out dir1 dir2, *)

deaktiviert das implizite Laden für alle Unterverzeichnisse außer dir1 und dir2 und ihre
Unterverzeichnisse.

vorgefertigt Ziel
um Ziel
Die Argumente (die einer Variablenerweiterung im Make-Stil unterzogen werden) werden sofort erstellt.
Dies ist nützlich, wenn die Liste der Ziele, die das Makefile erstellen kann, von a abhängt
generierte Datei in einem anderen Verzeichnis.

Derzeit schlägt die Erstellung von Zielen stillschweigend fehl, wenn zwischen ihnen eine Abhängigkeitsschleife besteht
die vorgefertigten Ziele und die Makefiles, die geladen werden müssen, um sie zu erstellen, aber das
sollte als Fehler behandelt werden.

register_command_parser command_word Parser
register_parser command_word Parser
Verwenden Sie bei der lexikalischen Analyse von Regelaktionen Parser für den command_word, das kann das sein
Vollständiger Pfad oder nur der Basisname. Der Basisname reicht normalerweise aus, da der Lexer
probiert beides.

Die Parser kann entweder ein Klassenname mit oder ohne führendes Element sein
„Mpp::CommandParser::“. Eine solche Klasse muss eine Mitgliedsfunktion namens „Factory“ haben.
das ein Objekt dieser Klasse zurückgibt. Wenn der Klassenname Doppelpunkte enthält, muss dies der Fall sein
zitiert, damit diese Zeile nicht wie eine Regel aussieht.

Oder weil diese Klasse normalerweise noch nicht geladen ist, stattdessen möglicherweise die Factory-Funktion
befinden sich im Makefile-Namespace. Diese Funktionen haben das Präfix „p_“, das muss
nicht gegeben werden. Dies ist bei den eingebauten Parsern der Fall.

Der Effekt ist vergleichbar mit der Regeloption „:parser“. Aber für Regeln mit mehreren Befehlen
Das ist der bessere Weg.

register_input_suffix command_word Suffix ...
Fügen Sie „suffix“ ... zur Liste der bei einer Aktion erkannten Eingabedateisuffixe hinzu
beginnend mit „command_word“ wird analysiert. Der Parser würde dies normalerweise über abholen
Mpp::CommandParser::input_filename_regexp, aber es könnte stattdessen dies vollständig ignorieren.

Parser erfassen normalerweise nicht alle Argumente, die nicht als Optionen erkannt werden.
weil es sich möglicherweise um Argumente unerkannter Optionen handelt. (Zum Beispiel, i386v is nicht
eine Eingabedatei des Befehls „gcc -b i386v foo.c“.) Stattdessen greifen sie nur auf
Positionsargumente, die wie Eingabedateinamen aussehen.

Es ist nicht ungewöhnlich, Standardtools mit standortspezifischen, nicht standardmäßigen Suffixen zu verwenden
um anzuzeigen, dass diese Dateien eine besondere Behandlung erfordern, z. B. einen anderen Befehl
Optionen und/oder Nachbearbeitungsschritte. Zum Beispiel:

register_input_suffix cpp .vpp
%.v: %.vpp
cpp $< > $@

Quelle Verzeichnis
Quelle destdir=srcdir
Gibt ein oder mehrere Repository-Verzeichnisse an. Das erste angegebene Repository hat
Vorrang vor den anderen, wenn dieselbe Datei in mehreren Repositorys und dort vorhanden ist
Es gibt keinen Build-Befehl dafür. Weitere Informationen finden Sie unter makepp_repositories
Repositories.

Wenn Sie nach „Repository“ nur ein Verzeichnis angeben, wird dessen Inhalt in das verlinkt
Aktuelles Verzeichnis. Sie können den Inhalt an einer beliebigen Stelle in der Datei verknüpfen
System durch Angabe der Position vor einem Gleichheitszeichen, z. B.

Repository subdir1/subdir2=/users/joe/joes_nifty_library

Sie sollten die Repository-Anweisung ganz oben in Ihrem Makefile platzieren, vor allen anderen
Regeln, die möglicherweise für die Verwendung erforderlich sind.

Laufzeit Programm, Bibliothek
Speichern Sie „Bibliothek“ als Laufzeitabhängigkeit von „Programm“. Sowohl „Programm“ als auch „Bibliothek“
kann mehrere Wörter enthalten. In diesem Fall wird jedes Wort in der „Bibliothek“ als gespeichert
Laufzeitabhängigkeit jedes Wortes in „Programm“. Wenn „Programm“ automatisch hinzugefügt wird
als ausführbare Abhängigkeit eines Befehls von der Basisklasse „Mpp::CommandParser“, it
Laufzeitabhängigkeiten (falls vorhanden) werden ebenfalls hinzugefügt. Damit dies geschieht,
„Programm“ muss in der Regel mit und ohne Verzeichniskomponente angegeben werden
Shell-Metazeichen. Der Zweck dieser Anweisung besteht darin, Abhängigkeiten zu erfassen
Bibliotheken und andere ausführbare Dateien, die häufig vom Programm geladen werden, ohne dass dies der Fall ist
um sie explizit als Abhängigkeiten jeder Regel anzugeben, die „Programm“ aufruft, oder um
Scannen Sie „Programm“, um diese Abhängigkeiten zu ermitteln (die unerschwinglich sein könnten).
schwierig.)

Laufzeitabhängigkeiten werden rekursiv durchlaufen, wenn also „a“ eine Laufzeitabhängigkeit aufweist
„b“ und „b“ haben eine Laufzeitabhängigkeit von „c“, ebenso wie jede Regel, die „./a“ verwendet
implizite Abhängigkeiten sowohl von „b“ als auch von „c“ (es sei denn, es wird ein spezielles verwendet).
„Mpp::CommandParser“-Klasse, die dieses Verhalten überschreibt.

Beachten Sie, dass fehlende Abhängigkeiten nicht unbedingt hinzugefügt werden, nachdem Sie diese Anweisung hinzugefügt haben
in ein Makefile, es sei denn, die Regel wird erneut gescannt. Verwenden Sie die Befehlszeile „--force-rescan“.
Option, um sicherzustellen, dass dies geschieht.

Stempel, Unterschrift Name
[globale] [override] Signatur Name
Signatur MD5
Unterschrift C
Signatur c_compilation_md5
Signatur-XML
Signatur-XML-Bereich
Signaturstandard

Legt die Signaturmethode für alle Regeln fest, die auf die Anweisung „signature“ folgen
Kein Befehlsparser wählt eine Methode. Sie können dies für einzelne Regeln mit außer Kraft setzen
der Regelmodifikator „:signature“.

Wenn Sie das Schlüsselwort „override“ hinzufügen, überschreibt diese Methode sogar die Auswahl
von Befehlsparsern erstellt, jedoch nicht diejenigen, die mit dem Regelmodifikator „:signature“ angegeben wurden.
Wenn Sie das Schlüsselwort „global“ hinzufügen, gilt der Effekt für alle noch zu lesenden Regeln,
es sei denn, ihr Makefile hat auch eine eigene „Signatur“-Anweisung. Dies entspricht
die Befehlszeilenoption „--signature“, wenn sie vor dem Lesen einer Regel angegeben wird, z. B. in a
RootMakeppfile um sicherzugehen, dass es früh genug gesehen wird. Ebenso die Schlüsselwörter „global
override“ für diese Anweisung entsprechen der Befehlszeile „--override-signature“.
.

Geben Sie „Signaturstandard“ anstelle eines Namens an, wenn Sie zum Standard zurückkehren möchten.
Mit dem Schlüsselwort „global“ ist damit die einfache Änderungszeit und Dateigröße gemeint
Methode. Andernfalls wird das aktuelle Makefile so zurückgesetzt, dass es keine eigene spezifische Methode mehr hat.
Verwenden einer globalen Methode, sofern eine festgelegt wurde.

Weitere Informationen zu Signaturmethoden finden Sie unter makepp_signatures.

vpath Anleitungen Verzeichnis ...
Rufen Sie alle Dateien, die dem Muster entsprechen, aus jedem angegebenen Verzeichnis ab. Das Muster kann Folgendes enthalten:
höchstens ein „%“-Platzhalter. Dies nutzt den transparenten Repository-Mechanismus (im Gegensatz zu gmake
wodurch Dateinamen neu geschrieben werden), es erfolgt jedoch keine Rekursion in Unterverzeichnisse.

Befehle
Alle integrierten und selbst definierten Befehle (siehe integrierte Befehle und Erweiterung von makepp).
als externe sauber programmierte Perl-Skripte können wie Anweisungen verwendet werden. In diesem Fall
Sie unterscheiden sich von Regelaktionen dadurch, dass sie im selben Prozess wie makepp und alle Eingaben ausgeführt werden
oder Ausgabedateien werden nicht als Abhängigkeiten vermerkt oder als von makepp erstellt.

Wie bei allen Aussagen gelten sie als solche, wenn sie weniger eingerückt sind als die
Aktionen der vorherigen Regel, falls vorhanden.

Dies kann für die Ausgabe von Meldungen beim Lesen des Makefiles genutzt werden:

&echo Der Wert von $$(VAR) ist $(VAR)

Oder anstatt viele Regeln jeweils von einer Verzeichniserstellungsregel abhängig zu machen, können Sie dies auch einfach tun
Erstellen Sie es im Handumdrehen. Beachten Sie, dass Befehle, die Dateien erstellen, alle erneut verarbeitet werden
Mal, wenn das Makefile gelesen wird. Deshalb schützen wir dieses mit einem Test – allerdings in diesem
Sonderfall, der nicht notwendig wäre, da dieser Befehl bei Wiederholung keinen Schaden anrichten würde:

ifperl !-d 'include'
&mkdir -p include # Nur erstellen, wenn nicht vorhanden
Endif

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