makepp_command – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

makepp – Befehlszeilensyntax für makepp

BESCHREIBUNG

?: -?, A: -EIN,
--args-file,
--arguments-file,
--assume-new,
--assume-old, B: -B,
--build-cache,
--build-check,
--build-check-method, C: -VS,
-C, D: --defer-include,
--Verzeichnis,
--do-build,
--dont-build,
--nicht-lesen,
--do-read,
--Probelauf,
--dump-makefile,
--dump-makeppfile, E: -e,
--environment-overrides,
--env-overrides, F: -F,
-F,
--Datei,
--final-rules-only,
--force-copy-from-bc,
--force-rescan, G: --leichtgläubig, H: -H,
--Hilfe,
--hybrid,
--hybrid-rekursion,
--hybrid-recursive-make, I: -ICH,
--implicit-load-makeppfile-only,
--enthalten,
--include-dir,
--in-sandbox,
--inside-sandbox, J: -J,
--Arbeitsplätze,
--just-print, K: -k,
--weitermachen, L: --Last-Chance-Regeln,
--load-makefile,
--load-makeppfile,
--Protokoll,
--Logdatei,
--Schleife, M: -M,
--makefile,
$MAKEFLAGS,
$MAKEPP_CASE_SENSITIVE_FILENAMES,
--makeppfile,
$MAKEPPFLAGS,
--md5-bc,
--md5-check-bc, N: -nicht,
--neue Datei,
--no-builtin-rules,
--no-cache-scaninfos,
--no-implicit-load,
--no-log,
--no-path-executable-dependencies,
--no-path-exe-dep,
--no-populate-bc,
--no-print-directory,
--no-remake-makefiles,
--keine Warnung, O: -Ö,
--old-file,
--out-of-sandbox,
--override-signature,
--override-signature-method, P: --populate-bc-only,
--Profil, Q: --ruhig, R: -R,
-R,
--recon,
--remove-stale,
--remove-stale-files,
--Repository,
--rm-stale,
--root-dir,
--Wurzelverzeichnis, S: -S,
--Sandkasten,
--sandbox-warn,
--sandbox-warning,
--Unterschrift,
--signature-method,
--still,
--stoppen,
--stop-after-loading,
--stop-before-building,
--stop-on-race,
--stop-race,
--symlink-in-rep-as-file,
--symlink-in-repository-as-file, T: --traditionell,
--traditionelle-Rekursion,
--traditionelles-rekursives-make, V: -V,
-in,
--ausführlich,
--Ausführung,
--virtual-sandbox, W: -W,
--was ist, wenn

machenpp [ ganz ohne irgendetwas tun oder drücken zu müssen. ... ] [ VAR=Wert ] [ Ziel ... ]

mpp [ ganz ohne irgendetwas tun oder drücken zu müssen. ... ] [ VAR=Wert ] [ Ziel ... ]

Makepp unterstützt die meisten Befehlszeilenoptionen und Syntax, die auch andere Hersteller unterstützen. Der
Bindestriche zwischen den Wörtern sind immer optional und können auch durch einen Unterstrich ersetzt werden.
Sie geben in der Befehlszeile eine Liste der zu erstellenden Ziele an. Wenn Sie keine angeben
targets wird das erste explizite Ziel im Makefile erstellt.

Sie können in der Befehlszeile Variablen zuweisen, die alle Zuweisungen überschreiben oder
Umgebungsvariable in jedem geladenen Makefile, z. B.

makepp CFLAGS=-O2

Gültige Optionen sind die meisten Standard-Make-Optionen sowie einige neue:

-A Dateinamen
--args-file=Dateinamen
--arguments-file=Dateinamen
Lesen Sie die Datei und analysieren Sie sie möglicherweise durch Leerzeichen und/oder Zeilenumbrüche in Anführungszeichen getrennt
nach.

-b Verzeichnis
--build-cache=Verzeichnis
Gibt den 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. Auf der Befehlszeile definierte Build-Caches können sein
wird durch eine build_cache-Anweisung in einem Makefile oder einen :build_cache-Regelmodifikator überschrieben.
Wenn Sie mit mehreren unterschiedlichen Builds arbeiten, kann es sinnvoll sein, die Umgebung festzulegen
Variable „MAKEPPFLAGS“, um „--buil“ „d-cache=/path/to/build/cache“ zu enthalten, damit alle
Ihrer Builds nutzen standardmäßig den Build-Cache.

--build-check=Methode
--build-check-method=Methode
Der Name einer Build-Prüfmethode, mit der entschieden wird, ob Dateien neu erstellt werden müssen.
Mögliche Werte sind „target_newer“, „exact_match“, siehe makepp_build_check
Informationen zu Build-Prüfmethoden.

-C Verzeichnis
--Verzeichnis=Verzeichnis
Wechseln Sie mit der CD in das angegebene Verzeichnis, bevor Sie das Makefile laden und versuchen, die Ziele zu erstellen.
Dies ähnelt der Angabe eines Verzeichnisses mit „-F“, mit der Ausnahme, dass das nachfolgende „-C“
Die Optionen „-f“, „-F“, „-I“ und „-R“ werden relativ zum neuen Verzeichnis interpretiert.
statt des alten.

-c
--root-dir
--Wurzelverzeichnis
CD bis zu dem Verzeichnis, das eine RootMakepp-Datei enthält.

--defer-include
Problemumgehung für die Include-Anweisung vor der Regel, die die Include-Datei erstellt. Das
geschieht, indem man vorgibt, dass die Include-Anweisungen im Makefile an letzter Stelle stehen. Auf diese Weise die
Die Include-Anweisung ist ausführbar, es können jedoch weiterhin Variablen überschrieben oder geändert werden
scheitern, in diesem Fall sollten Sie die problematischen in der Befehlszeile festlegen (während
gmake ignoriert alle Variableneinstellungen aus der Include-Datei, die die Art und Weise beeinflussen könnten
die Datei selbst wird erstellt).

--dont-build=Dateinamen
--do-build=Dateinamen
Erstellen Sie nicht die angegebene Datei oder, wenn es sich um ein Verzeichnis handelt, alles darunter
obwohl makepp der Meinung ist, dass dies der Fall sein sollte – oder erstellen und dabei die entgegengesetzte Spezifikation überschreiben
aus einem höheren Verzeichnis. Dies ist nützlich, wenn Sie eine bestimmte Datei manuell mit erstellt haben
verschiedene Zusammenstellungsmöglichkeiten. Ohne diese Option, wenn Sie ein Modul manuell kompilieren
und führen Sie dann makepp aus, um den Rest des Programms zu kompilieren. makepp kompiliert das Programm ebenfalls neu
Modul, das Sie von Hand kompiliert haben, da makepp nicht garantieren kann, dass der Build korrekt ist
wenn eine der Dateien nicht unter seiner Kontrolle erstellt wurde. Mit dieser Option sagen Sie es
makepp, dass Sie wirklich wissen, was Sie im Fall dieser bestimmten Datei tun und
Sie versprechen, dass es in Ordnung ist, es nicht wieder aufzubauen.

Zum Beispiel,

% cc -g -DSPECIAL_DEBUG -c xc -o xo # Spezielle manuelle Kompilierung
% makepp
cc -g -O2 -c xc -o xo # Makepp hat hier gerade Ihre Zusammenstellung überschrieben!
cc xo yo -o my_program # Erneut verknüpfen.
% cc -g -DSPECIAL_DEBUG -c xc -o xo # Wiederholen Sie es.
% makepp --dont-build xo # Makepp anweisen, xo nicht neu zu erstellen, selbst wenn es möchte.
cc xo yo -o my_program # Jetzt wird es ohne Neukompilierung erneut verknüpft.

Wenn Sie spezielle Kompilierungsoptionen für nur ein Modul wünschen, ist die Bearbeitung oft einfacher
das Makefile als manuell zu kompilieren, wie in diesem Beispiel; siehe „Zielspezifisch“.
Zuweisungen“ in makepp_variables für eine einfache Möglichkeit, dies zu tun.

Wenn Sie ein RootMakeppfile(.mk) im Stammverzeichnis Ihres Build-Systems, dieses Verzeichnis und
alles darunter ist standardmäßig „--do-build“, während das gesamte Stammverzeichnis Ihrer Datei ist
Der Systemstandard ist „--dont-build“. Auf diese Weise ist alles in Ihrem Build-System vorhanden
gebaut (falls nötig), aber außerhalb wird nichts versucht. Wenn Sie in diesem Szenario möchten
Damit externe Teile immer nach Bedarf gebaut werden, müssen Sie diese explizit mit abholen
„load_makefile“-Anweisungen in einem der Makefiles in Ihrem Baum.

Möglicherweise haben Sie einen RootMakeppfile(.mk) Jeder baut in separaten Bäumen Bäume auf, und das werden sie auch sein
geladen, wenn ein Baum Abhängigkeiten von einem anderen hat. Aber das darfst du nicht haben
RootMakeppfile(.mk) in verschachtelten Verzeichnissen, um lustige Effekte zu vermeiden, die häufig auftreten
wenn Sie versehentlich erneut „makepp --repository“ in einem Unterverzeichnis aufrufen. Diese
Zu den Effekten gehören doppelte Regeln durch doppelte Quellen oder ein ewiger Build-Cache
reimportiert, weil zwischengespeicherte Dateien die richtigen Signaturen, aber den falschen Verwandten haben
Pfade.

Überschreiben Sie „--dont-build“ für die angegebene Datei oder das angegebene Verzeichnis. Wenn Sie eine haben
RootMakeppfile(.mk) im Stammverzeichnis Ihres Build-Systems, aber Sie möchten, dass makepp erstellt wird
Wenn Sie nur dieses eine Mal etwas außerhalb Ihres Build-Systems erstellen, müssen Sie es explizit als markieren
„--do-build“. Wenn Sie „--do-build“ für eine Datei oder ein Verzeichnis unter a angeben
RootMakeppfile(.mk), ohne „--dont-build“ für ein höheres Verzeichnis, dann das Stammverzeichnis (und
alles andere darunter) Ihres Build-Systems ist standardmäßig „--dont-build“.

Um Konflikte zwischen „--dont-build“ und „--do-build“ zu lösen, dem mit den meisten
Der spezifische Pfad hat unabhängig von der Reihenfolge Vorrang. Wenn der gleiche Pfad angegeben ist
mit „--dont-build“ und „--do-build“, dann gewinnt der ganz rechte.

Die Optionen „--dont-build“ und „--do-build“ können bei falscher Angabe gefährlich sein
Hinweise für makepp, da Sie makepp bitten, keine erforderlichen Prüfungen durchzuführen, um eine zu gewährleisten
korrekter Aufbau. Da sie es aber ermöglichen, die Anzahl der Kontrollen erheblich zu reduzieren, ist dies möglich
Beschleunigen Sie Ihre Builds erheblich, wie in den potenziell unsicheren Beschleunigungsmethoden erläutert.

--dont-read=Dateinamen
--do-read=Dateinamen
Lesen Sie nicht die angegebene Datei oder, wenn es sich um ein Verzeichnis handelt, alles darunter – oder
Lesen Sie es und überschreiben Sie dabei die entgegengesetzte Spezifikation aus einem höheren Verzeichnis. Generieren Sie eine
Fehler, anstatt Dateien zu lesen, die mit „--dont-read“ markiert sind. Siehe --sandbox. Das Dateisystem
root ist standardmäßig immer auf lesbar eingestellt.

--dump-makefile=Dateinamen
--dump-makeppfile=Dateinamen
Den Rohinhalt der Makefile(s) für das aktuelle Verzeichnis ausgeben (wie durch bestimmt).
die Position dieser Option relativ zu allen „-C“-Optionen). Dateinamen. Dateien einschließen
werden interpoliert, Kommentare werden entfernt und „ifdef“s werden aufgelöst. "# Linie
„Datei“-Marker werden nach Bedarf eingefügt. Der Endwert aller Nichtreferenzen
Skalare im Makefile-Paket werden nach dem Makefile gedruckt.

Dies ist zum Debuggen nützlich, aber (derzeit) können Sie das nicht unbedingt verwenden
Dump-Datei als äquivalentes Makefile, zum Beispiel weil sie sowohl die Include- als auch die Include-Datei enthält
Anweisung und der interpolierten Datei.

-e
--env-overrides
--environment-overrides
Bewirkt, dass Variablen aus der Umgebung Definitionen im Makefile überschreiben. Von
Standardmäßig überschreiben Zuweisungen innerhalb des Makefiles importierte Variablenwerte
aus der Umwelt.

-F Makeppfile
--makeppfile=Makeppfile
Lädt das angegebene Makefile oder, wenn Sie ein Verzeichnis angeben, das Make-Datei darin,
anstelle des im aktuellen Verzeichnis – jedes rechts davon angegebene Ziel
Diese Option wird relativ zum Verzeichnis interpretiert, das das Makefile enthält. Für die
Einzelheiten zum Verzeichnisfall und RootMakeppfile siehe die Erklärung weiter unten
.

Diese Option kann nützlich sein, wenn Sie makepp aus unvorhersehbaren Verzeichnissen ausführen. Für
Wenn Sie beispielsweise innerhalb von Emacs kompilieren und die Quellen überall verstreut sind
Verzeichnisbaum, das aktuelle Arbeitsverzeichnis für den Kompilierungsbefehl ist
Verzeichnis, in dem sich die zuletzt von Ihnen bearbeitete Quelldatei befand. Das Verzeichnis kann ganz oben sein oder auch nicht
Level-Verzeichnis für Ihre Zusammenstellung. Sie können jedoch Ihre Zusammenstellung angeben
Befehl als

makepp -F /your/source/dir/top

und das funktioniert unabhängig von Ihrem aktuellen Verzeichnis.

Da sich diese Option nicht auf das Verzeichnis auswirkt, in Bezug auf das nachfolgende „-C“
Wenn die Optionen „-f“, „-F“, „-I“ und „-R“ angegeben sind, können Sie Ziele relativ zum festlegen
aktuelles Verzeichnis wie folgt:

makepp -F /foo/bar -C . mein Ziel

-f Make-Datei
--Datei=Make-Datei
--makefile=Make-Datei
Lädt das angegebene Makefile oder, wenn Sie ein Verzeichnis angeben, das Make-Datei darin,
anstelle der im aktuellen Verzeichnis. Wenn Sie die Option „-f“ nicht angeben oder
Mit der Option „-F“ sucht makepp zunächst nach einer Datei im aktuellen Verzeichnis (oder der
Verzeichnis, das durch die Option „-C“ ganz rechts angegeben wird (falls vorhanden), dann aufgerufen
RootMakeppfile.mk, Makeppfile und dann Makeppfile.mk und dann Makefile und dann Make-Datei.
Es können mehrere Optionen „-F“ und „-f“ angegeben werden.

Die ersten zwei (RootMakeppfile) sind etwas Besonderes (ob explizit angegeben oder gefunden).
implizit). Es darf höchstens einer dieser beiden in jedem Build-Baum vorhanden sein, auf dem
makepp soll funktionieren. Es können aber auch mehrere sein, wenn man mehrere disjunkte Bäume einbaut
ein Versuch. Diese beiden werden nicht nur im oben genannten Verzeichnis gesucht, sondern auch
von dort nach oben. Wenn einer gefunden wird, wird er vor allen anderen geladen.

--final-rules-only
Ignorieren Sie die Abhängigkeiten und impliziten Ziele der Regel, es sei denn, das Ziel ist falsch.

--force-copy-from-bc
Wenn Sie Build-Caches verwenden, kopieren Sie immer Dateien in den Cache und aus dem Cache, auch wenn es sich um die Quelle handelt
und Ziel befinden sich im selben Dateisystem. Dies ist hauptsächlich zum Testen (Emulieren) nützlich.
der Fall, in dem dies nicht der Fall ist.

--force-rescan
Verwenden Sie keine zwischengespeicherten Scannerergebnisse aus früheren Durchläufen.

--leichtgläubig
Glauben Sie, dass die Regeln das schaffen, was sie deklarieren, anstatt es zu überprüfen. Das ist
schneller, erkennt aber keine Fehler in den Regeln.

-?
-h
--help
Drucken Sie eine kurze Zusammenfassung der Optionen aus.

--hybrid
--hybrid-rekursion
--hybrid-recursive-make
Diese Option ist vorhanden, damit makepp mit alten Makefiles arbeiten kann, die rekursiv verwenden
ausgiebig machen, insbesondere in das gleiche Verzeichnis multiplizieren. Standardmäßig rekursives Make
wird von einem Unterprozess implementiert, der mit dem übergeordneten Prozess kommuniziert; der Aufbau ist
tatsächlich vom übergeordneten Prozess erledigt. Dies ermöglicht einige der netten Funktionen von makepp, z
Repositories für die Arbeit mit rekursiven Make-Aufrufen. Diese Technik wird jedoch
funktioniert nicht, wenn Sie mehr als ein Makefile aus demselben Verzeichnis laden. In diesem Fall
Diese Option besagt, dass auf den Start einer anderen unabhängigen Instanz von makepp zurückgegriffen werden soll. Wenn
Wenn dies fehlschlägt, versuchen Sie es mit „--traditional-recursive-make“.

Wenn Sie diese Option verwenden, erhalten Sie im Fallback Protokolldateien in jedem Verzeichnis
aufgetreten in. Um nur sie zu entfernen, verwenden Sie „makeppclean --logs --recurse“ oder „mppc
-lr".

-I Verzeichnis
--include=Verzeichnis
--include-dir=Verzeichnis
Durchsuchen Sie das angegebene Verzeichnis nach enthaltenen Makefiles.

--implicit-load-makeppfile-only
Wenn das implizite Laden von Makefiles aktiviert ist, wird automatisch nur eine Datei geladen
namens RootMakeppfile, RootMakeppfile.mk, Makeppfile oder Makeppfile.mk und nicht
Makefile or Make-Datei. Dies ist nützlich, wenn makepp Abhängigkeiten hat, die von generiert werden
eine andere Make-Variante, und makepp kann die Makefiles dieser Variante im Allgemeinen nicht lesen.
(Sie möchten diese Situation nach Möglichkeit vermeiden, sie tritt jedoch häufig auf, während Sie sich darin befinden
der Prozess der Portierung eines Legacy-Build-Systems auf makepp.) Dies hat keine Auswirkung, wenn
Das implizite Laden ist deaktiviert.

-j n
--jobs=n
Interpretiert das Argument n als die Anzahl der Shell-Befehle, die ausgeführt werden können
parallel. Standardmäßig führt makepp keine Befehle parallel aus.

Im Gegensatz zu einigen anderen Versionen von make führt makepp Anweisungen aus, wenn Jobs parallel ausgeführt werden
speichert ihre Ausgabe in eine Datei und zeigt die Ausgabe erst an, wenn die Befehle abgeschlossen sind.
Dadurch wird verhindert, dass die Ausgabe mehrerer verschiedener Befehle auf dem gemischt wird
angezeigt, aber es bedeutet, dass Sie möglicherweise etwas länger warten müssen, bis Sie das sehen
Ausgabe- und stderr-Meldungen werden normalerweise vor stdout-Inhalten angezeigt, im Gegensatz zu
Terminalausgang.

Native Windows-Perls (z. B. Strawberry und ActiveState), da diese nicht unterstützt werden
Wenn Sie das Unix-Fork/Exec-Paradigma verwenden, lassen Sie diese Option nicht zu (Cygwin funktioniert einwandfrei!). Als ein
Für einen teilweisen Ersatz können Sie dort die Option --sandbox verwenden, allerdings ist dies weitaus kostengünstiger
komfortabel.

-k
--mach weiter
Erstellen Sie so viele Dateien wie möglich, auch wenn einige Befehle Fehler enthalten. Von
Standardmäßig stoppt makepp, wenn der erste Fehler auftritt, auch wenn weitere Fehler vorliegen
Dateien, die erstellt werden müssen und nicht von der fehlerhaften Datei abhängen.

--last-chance-rules
Begrenzte Sonderbehandlung für Musterregeln mit „%“ nur auf der Zielseite aktivieren.
Dies ist erforderlich, da makepp im Gegensatz zu herkömmlichen Marken normalerweise alles instanziiert
Regeln mit allen verfügbaren Dateien von unten nach oben, sodass alle erstellbaren Dateien gefunden werden können
Abhängigkeiten.

--load-makefile=Make-Datei
--load-makeppfile=Make-Datei
Lädt das angegebene Makefile bevor alle anderen Makefiles, außer RootMakeppfile oder
RootMakeppfile.mk darüber, aber ziehen Sie diese Option nicht für die Zwecke in Betracht
Bestimmen des Standardziels. Wenn kein anderes Makefile angegeben ist, wird nach einem gesucht
nach den üblichen Regeln. Wenn das angegebene Makefile dasselbe Makefile ist, das gefunden wurde
Wenn Sie die üblichen Regeln verwenden, hat diese Option keine Auswirkung.

--log=Logdateiname
--log-file=Logdateiname
Ändert den Namen der Protokolldatei in den angegebenen Namen. Standardmäßig ist die Protokolldatei
namens .makepp/log. Diese Datei kann mit makepplog und mppl gelesen werden.

--Schleife
--halt
--stop-before-building
--stop-after-loading
Makepp stoppt sich wiederholt selbst (schläft ein), bevor es analysiert und baut
alles, damit Sie es aufwecken können, wenn Sie dazu bereit sind. Es werden Ihnen einige Befehle mitgeteilt
Wählen Sie aus, um es wieder aufzuwecken. Wenn Sie dies in einer Shell tun, erhalten Sie die Eingabeaufforderung und
kann es dann im Vordergrund oder Hintergrund darstellen. Wenn Sie es innerhalb einer IDE tun, schläft es einfach und
Sie können es aus einer anderen Shell erwecken. Je nachdem, wo Sie es starten, schließen Sie es
window kann makepp beenden oder auch nicht, also prüfen Sie, wie Sie in Ihrem Browser damit umgehen können
Umwelt.

Die Absicht ist, dass Sie makepp auf diese Weise starten können, bevor Sie mit der Bearbeitung fertig sind
Einige Dateien. Abhängig von Ihrer Projektstruktur und -größe kann dies makepp ermöglichen
Verschaffen Sie sich einen Vorsprung von vielen Sekunden Arbeit, wenn Sie fertig sind. Dann alle
Zeit können Sie mehr bearbeiten und es wieder aufwecken, es sei denn, Sie ändern etwas an Ihrem
Makefile, das unbemerkt bleibt, bis Sie eine neue Instanz von makepp starten. Das gleiche
Gilt für Repositorys, die sich niemals ändern dürfen, während makepp ausgeführt wird.

Wenn Sie „prebuild“ oder „$(make)“ verwenden, stoppt es in der ersten Runde, wenn es soweit ist
dieser Punkt.

-m Methode
--signature=Methode
--signature-method=Methode
Gibt die Standardsignaturmethode an, die für Regeln verwendet werden soll, die nicht über das verfügen
„:signature“-Modifikator in Makefiles, die keine „signature“-Anweisung haben. Tut
Überschreiben Sie nicht die von Befehlsparsern, z. B. C/C++-Compilern, getroffene Auswahl. Möglich
Werte sind „md5“, „C“ oder „c_compilation_md5“, „xml“ und „xml-space“. Für mehr
Einzelheiten finden Sie unter makepp_signatures.

--md5-bc
--md5-check-bc
Wenn Sie aus einem Build-Cache importieren, lehnen Sie zwischengespeicherte Ziele ab, es sei denn, MD5_SUM ist vorhanden
und entspricht dem importierten Ziel. Berechnen und speichern Sie, wenn Sie einen Build-Cache füllen
die MD5_SUM in den Build-Informationen, falls sie noch nicht vorhanden ist. Dies ist langsamer und führt zu
mehr Neuerstellungen, aber es garantiert, dass importierte Ziele und Build-Infodateien übereinstimmen
genau.

-n
--Probelauf
--just-print
--recon
Geben Sie Befehle aus, ohne sie tatsächlich auszuführen – unzuverlässig, wenn Befehle davon abhängen
zu früheren Ergebnissen. Auf diese Weise können Sie sehen, was makepp tatsächlich tun wird
Ändern von Dateien.

Genauer gesagt führt makepp alle rekursiven Make-Befehle wie gewohnt aus (aber hoffentlich
Sie verwenden nirgendwo rekursives Make!). Andere Befehle werden einfach ohne ausgegeben
hingerichtet wird. Auch Befehle mit dem Präfix „@“ oder „noecho“ werden ausgegeben
nachdem das „@“ oder „noecho“ entfernt wurde. Befehle mit dem Präfix „+“ sollten dies jedoch tun
ausgeführt werden, derzeit jedoch nicht.

Warnung: Die Befehle, die makepp mit „-n“ ausführt, sind nicht unbedingt identisch
was es auch ohne „-n“ tun wird. Dateisignaturen ändern sich mit „-n“ überhaupt nicht
bedeutet, dass makepp nicht genau dieselben Build-Tests durchführen kann wie beim
Signaturen ändern sich. Dies wird gelegentlich einen Unterschied machen, wenn Sie es verwenden
MD5-Signaturen (was die Standardeinstellung für Kompilierungsbefehle ist) oder wenn Sie über eine Shell verfügen
Befehle, die das Datum ändern können oder auch nicht.

Angenommen, Sie generieren eine .h Datei über eine Art Präprozessor. Das
kann auf viele verschiedene Arten passieren. Der Konkretheit halber gehen wir davon aus, dass Sie automatisch sind
Generieren Sie eine Liste von Prototypen für Funktionen, die in jedem C-Modul definiert sind (siehe
<http://cproto.sourceforge.net/> wie die Anwendung „cproto“ funktioniert oder
<http://www.lemoda.net/c/cfunctions/> für die ähnlichen Funktionen).

Prototypen.h: *.c
cproto $(CPPFLAGS) $(Eingaben) > $(Ausgabe)

Dann jeder .c Datei enthalten wird Prototypen.h. Der Zweck hiervon ist die Aufrechterhaltung der
Deklarationen für alle Funktionen automatisch weiterleiten, also wenn Sie eine Funktion ändern
Wenn Sie eine Signatur erstellen oder eine neue Funktion hinzufügen, müssen Sie niemals vorwärts oder extern eingeben
Erklärungen überall. Sie müssen nicht einmal die Abhängigkeit Ihrer .o-Dateien deklarieren
In diesem Fall sieht makepp die Include-Anweisung und prüft automatisch, ob sie benötigt wird
um cproto (erneut) auszuführen.

Angenommen, Sie ändern nur eine davon .c Datei. Was passiert, wenn Sie makepp mit „-n“ ausführen?
In diesem Fall ist es so, dass es das erkennt Prototypen.h muss neu gemacht werden. Insgesamt
Wahrscheinlichkeit, Neugestaltung Prototypen.h hat keinen Einfluss auf die Signatur, sondern auf den Inhalt der Datei
wahrscheinlich identisch sein, da keine Funktionsargumente geändert wurden – also die meisten
Zeit, nichts, was davon abhängt Prototypen.h muss tatsächlich neu kompiliert werden. Aber Makepp
weiß das nicht, es sei denn, es ist tatsächlich erlaubt, die Befehle auszuführen. Es wird also davon ausgegangen
dass alles, was davon abhängt Prototypen.h muss auch neu kompiliert werden. Also in
In diesem Beispiel wird eins geändert .c Datei wird dazu führen, dass „makepp -n“ denkt, dass jeder einzelne
.c Die Datei muss neu kompiliert werden, obwohl höchstwahrscheinlich der reguläre Befehl makepp verwendet wird
wird tatsächlich nicht alle diese Befehle ausführen.

Diese Situation kommt nicht allzu häufig vor und kann nur auftreten, wenn (a) Sie eine Signatur verwenden
Methode, die als Standardkompilierung vom Dateiinhalt und nicht vom Datum abhängt
Signaturmethode dies tut, oder (b) wenn Sie Shell-Befehle haben, die die nicht immer ändern
Datum. Beispielsweise mit einer herkömmlichen Implementierung von make, die nur auf Datumsangaben schaut
Anstelle von Dateisignaturen schreiben Leute manchmal Befehle wie diesen:

Prototypen.h: $(wildcard *.c) # Gehackte Technik für makepp nicht erforderlich
cproto $(CPPFLAGS) $(inputs) > junk.h
if cmp -s junk.h Prototypen.h; Dann \
rm junk.h; \
anders \
mv junk.h Prototypen.h; \
fi

Wenn also die erneute Ausführung von cproto für alle Dateien genau denselben Dateiinhalt erzeugt, wird der
Dateidatum wird nicht aktualisiert. Dies wird genau das gleiche Problem wie oben haben
Beispiel mit „makepp -n“: Es ist nicht bekannt, ob das Datum an ist Prototypen.h Änderungen
es sei denn, der Befehl wird tatsächlich ausgeführt, daher kann „makepp -n“ unmöglich 100 % genau sein.
(Beachten Sie, dass die Verwendung des herkömmlichen „make -n“ ebenfalls zu genau demselben Problem führt
dieses Beispiel.)

„makepp -n“ sollte immer mehr Befehle ausgeben als ein normaler Aufruf von makepp,
nicht weniger. Wenn weniger Befehle ausgegeben werden, bedeutet das, dass makepp davon nichts weiß
gewisse Abhängigkeit; Es wird eine Datei geändert, von der nicht erwartet wird, dass sie sich ändert
davon, was es darüber weiß, welche Dateien jede Regel betrifft. Das bedeutet, dass Ihr Makefile
hat einen Bug.

--no-cache-scaninfos
Zeichnen Sie die Ergebnisse des Scanvorgangs nicht auf, sodass er beim nächsten Mal erneut ausgeführt werden muss
läuft.

--no-implicit-load
Makefiles nicht automatisch aus Verzeichnissen laden, auf die verwiesen wird (siehe „Implizites Laden“
in makepp_build_algorithm). Standardmäßig lädt makepp automatisch ein Makefile von
jedes Verzeichnis, das eine Abhängigkeit von einem Ziel enthält, das erstellt werden muss, und von dem aus es erstellt werden muss
jedes Verzeichnis, das mit einem Platzhalter gescannt wird. Manchmal führt dies jedoch zu einem
Problem, da Makefiles mit unterschiedlichen Befehlszeilenvariablen geladen werden müssen oder
Optionen und ob sie implizit geladen werden, bevor sie explizit von a geladen werden
Bei einem rekursiven Make-Aufruf oder der „load_makefile“-Anweisung bricht makepp mit einem ab
Fehler. Sie können das Laden von Makefiles auch verzeichnisweise deaktivieren, indem Sie
Verwenden Sie die Anweisung „no_implicit_load“ in einem Ihrer Makefiles.

--no-log
Machen Sie sich nicht die Mühe, eine detaillierte Beschreibung dessen zu schreiben, was mit der Protokolldatei geschehen ist. Von
Standardmäßig schreibt makepp eine Erklärung zu jeder Datei, die es zu erstellen versucht hat, und
warum es es erstellt hat oder nicht, in eine Datei namens .makepp/log, lesbar mit
makepplog, mppl. Dies kann für das Debuggen eines Makefiles – makepp – äußerst wertvoll sein
sagt Ihnen, was es bei all den Abhängigkeiten vermutet hat und welche es vermutet hat
geändert. Es nimmt jedoch etwas mehr CPU-Zeit in Anspruch, und Sie möchten sich vielleicht nicht darum kümmern.

--no-path-exe-dep
--no-path-executable-dependencies
Fügen Sie keine impliziten Abhängigkeiten zu ausführbaren Dateien hinzu, die bei der Befehlssuche ermittelt wurden
Weg. Wenn diese Option angegeben ist, geht makepp davon aus, dass jede ausführbare Datei deren
Das Verhalten kann sich mit einer neuen Version ändern. Wird mit einem Namen angegeben, der ein enthält
Schrägstrich.

Dies ist nützlich für Programme wie grep und diff, die im Grunde immer das Gleiche tun
selbst wenn sich ihre Implementierung ändert, obwohl Sie besser dran sind, die integrierte Version zu verwenden
Befehle für grep. Möglicherweise benötigen Sie dies auch für Repositorys auf NFS-Clustern, in denen die
Dieselben Befehle haben möglicherweise nicht überall den gleichen Zeitstempel, was zu unnötigen Fehlern führt
Wird je nach Maschine, an der jemand arbeitet, neu erstellt.

--no-populate-bc
Füllen Sie den Build-Cache nicht, importieren Sie ihn aber trotzdem, wenn möglich. Das ist
nützlich, wenn die Umgebung dazu führen kann, dass Ziele anders generiert werden, aber
makepp kennt solche Abhängigkeiten nicht. Es ist auch nützlich, das zu vermeiden
Erstellen Sie einen Cache mit einer großen Anzahl gleichzeitiger Autoren, die einen stören könnten
eine andere.

--no-print-directory
Schalten Sie die Nachrichten zum Betreten oder Verlassen des Verzeichnisses aus.

--no-remake-makefiles
Normalerweise lädt makepp jedes Makefile und prüft dann, ob es eine Regel gibt
das gibt an, wie das Makefile aktualisiert wird. Wenn ja, und das Makefile muss vorhanden sein
neu erstellt, der Befehl wird ausgeführt und das Makefile wird erneut gelesen. Dies führt oft dazu
Probleme mit Makefiles, die für das Standard-Unix-Make-Dienstprogramm erstellt wurden, weil (in meinem
Erfahrung) oft sind die Make-Regeln zum Aktualisieren von Makefiles ungenau – sie
häufig werden geänderte Ziele weggelassen. Dies kann dazu führen, dass makepp viel neu erstellt
Dateien unnötig. Sie können dieses Problem oft lösen, indem Sie makepp einfach verhindern
verhindern, dass das Makefile automatisch aktualisiert wird (Sie müssen jedoch daran denken, es zu aktualisieren).
Hand).

- nein warnen
Geben Sie keine Warnmeldungen an stderr aus, sondern nur an die Protokolldatei. Die meisten Warnmeldungen
Es geht um Konstrukte, die Sie möglicherweise in älteren Makefiles sehen, die makepp berücksichtigt
gefährlich, aber einige davon betreffen mögliche Fehler in Ihrem Makefile.

-o Dateinamen
--assume-old=Dateinamen
--old-file=Dateinamen
Gibt vor, dass sich die angegebene Datei nicht geändert hat, auch wenn dies der Fall ist. Alle zielen darauf ab
Von dieser Datei abhängige Dateien werden aufgrund dieser Datei nicht neu erstellt, obwohl dies möglicherweise der Fall ist
neu erstellt, wenn sich auch eine andere Abhängigkeit geändert hat. Die Datei selbst könnte es sein oder auch nicht
neu erstellt werden, je nachdem, ob es hinsichtlich seiner Abhängigkeiten veraltet ist.
(Um dies zu verhindern, verwenden Sie „--dont-build“.)

--override-signatur=Methode
--override-signature-method=Methode
Identisch mit „--signature-method“, überschreibt aber sogar die von Befehlsparsern getroffene Auswahl.

--out-of-sandbox=Dateinamen
Erzeugen Sie einen Fehler, anstatt Dateien außerhalb der „Sandbox“ zu schreiben. Wie --dont-build,
Spezifischere Pfade überschreiben weniger spezifische Pfade. Der Standardwert für das Dateisystem-Root ist
Out-of-Sandbox, wenn es irgendwelche „--sandbox“-Optionen gibt.

Der Zweck der Sandbox besteht darin, mehrere gleichzeitige MakePP-Prozesse sicher zu ermöglichen
auf disjunkten Teilen des Dateisystems arbeiten. Damit dies zuverlässig funktioniert,
Gleichzeitige Sandboxen dürfen sich nicht überlappen und jeder Prozess muss die Sandbox jedes Prozesses markieren
anderer gleichzeitiger Makepp-Prozess für --dont-read. Siehe Partitionierung in Sandboxes.

--populate-bc-only
Nicht aus dem Build-Cache importieren. Dies ist nützlich, wenn Sie Ziele spenden möchten
den Cache, aber Sie möchten sich nicht auf den Inhalt des Caches verlassen (z. B. für Mission-
kritische Builds).

--Profil
Rohe Zeitstempel vor und nach jeder Aktion ausgeben.

-R Verzeichnis
--repository=Verzeichnis
Geben Sie das angegebene Verzeichnis als Repository an (Einzelheiten finden Sie unter makepp_repositories).
Repositorys werden in der in der Befehlszeile angegebenen Reihenfolge hinzugefügt, also als erstes
Der von Ihnen angegebene Wert hat Vorrang. Alle Dateien im Verzeichnis (und allen seinen Unterverzeichnissen)
werden automatisch mit dem aktuellen Verzeichnis (und Unterverzeichnissen) verknüpft, sofern dies der Fall ist
Installation!

Wenn Sie nach „-R“ einfach ein Verzeichnis angeben, wird dessen Inhalt in das aktuelle verlinkt
Verzeichnis. Sie können den Inhalt mit an eine beliebige Stelle im Dateisystem verknüpfen
Angabe der Position vor einem Gleichheitszeichen, z. B.
„-R subdir1/subdir2=/users/joe/joes_nifty_library“.

-r
--no-builtin-rules
Laden Sie nicht die Standardregelsätze. Wenn diese Option nicht angegeben ist, und die Variable
„makepp_no_builtin“ ist nicht im Makefile definiert, dann gibt es eine Reihe von Regeln zum Kompilieren
Für jedes Verzeichnis wird C-, C++- und Fortran-Code geladen.

--rm-stale
--remove-stale
--remove-stale-files
Ignorieren Sie veraltete Dateien, anstatt sie als neue Quelldateien zu behandeln und sie ggf. zu entfernen
notwendig, um zu verhindern, dass sie von einem Build-Befehl gelesen werden. Das ist nicht
Dies ist die Standardeinstellung, da dadurch Dinge gelöscht werden. Dies ist jedoch häufig erforderlich
inkrementelles Bauen, damit es ordnungsgemäß funktioniert.

Nehmen wir zum Beispiel an, dass es eine gibt xc Datei, die so aussieht:

#include „xh“
int main() { return X; }

Betrachten Sie dieses Makefile:

$(falscher Standard): x
xh:
&echo "#define X 1" -o $@

Irgendwann ändern Sie das Makefile so, dass es wie folgt aussieht:

CFLAGS := -Idir
$(falscher Standard): x
dir/xh:
&mkdir -p $(dir $@)
&echo "#define X 2" -o $@

Wenn Sie nun aus sauberem Grund bauen, x wird mit Status 2 beendet, aber wenn Sie während des alten Builds bauen
./xh Datei existiert noch und Sie geben dann nicht „--rm-stale“ an x Exits mit Status
1, da die Include-Direktive die veraltete generierte Header-Datei aufnimmt.

Wenn Sie mit „--rm-stale“ erstellen, dann ./xh wird entfernt und das Ergebnis ist das gleiche wie
das einer sauberen Bauweise, was fast immer eine gute Sache ist.

Beachten Sie, dass Sie diese Option zuerst dort angeben müssen, wenn Sie ein Repository einbauen.
weil das importierende Makepp nicht weiß, was im Repository möglicherweise veraltet ist.

Ältere Makefiles enthalten manchmal die Regel, nach dem Include eine Include-Datei zu generieren
Stellungnahme. Mpp umgeht das wie gmake, indem es am Ende des Makefiles neu lädt
wenn benötigt. Dies bedeutet jedoch, dass es bei einem Umbau an der Stelle, an der es ist, altbacken aussieht
benötigt und werden gelöscht. Daher schaltet diese Option diese Art des Neuladens aus.

-s
--ruhig
--Leise
Geben Sie keine Befehle als Echo aus und geben Sie keine Informationsmeldungen wie „Scanning“ oder „Loading“ aus
Makefile".

--sandkasten=Verzeichnis
--in-sandbox=Verzeichnis
--inside-sandbox=Verzeichnis
Beschränken Sie diese Instanz von makepp auf einen Teilbaum eines normalerweise größeren Build-Baums. Sehen
Partitionierung in Sandboxen.

--sandbox-warn
--sandbox-warning
Verstöße gegen „In-Sandbox“ und „Nicht gelesen“ werden auf Warnungen statt auf Fehler herabgestuft.
Siehe Partitionierung in Sandboxes.

--stop-race
--stop-on-race
Fehlerhaft beenden, anstatt nur vor einer Kollision beim Build-Cache-Zugriff zu warnen, die dazu führen könnte
repariert sein.

--symlink-in-rep-as-file
--symlink-in-repository-as-file
Wenn ein Repository einen symbolischen Link enthält, ist dieser symbolische Link standardmäßig vorhanden
als Link importiert werden, d. h. das Ziel des importierten Links muss es nicht sein
identisch mit dem Ziel des symbolischen Links im Repository. Wenn die
Wenn die Option „--symlink-in-repository-as-file“ angegeben wird, erfolgt der symbolische Link
als Zieldatei importiert, d. h. der importierte Link verweist auf dieselbe Datei
Zieldatei als symbolischer Link im Repository. Dies ist nützlich, wenn die symbolische
Der Link im Repository sollte die Build-Time-Semantik einer Kopie haben.

--traditionell
--traditionelle-Rekursion
--traditionell-rekursiv-machen
Diese Option ist vorhanden, damit makepp mit alten Makefiles arbeiten kann, die rekursiv verwenden
machen Sie umfangreich, insbesondere mit unterschiedlichen Optionen. Standardmäßig ist rekursives Make
implementiert durch einen Unterprozess, der mit dem übergeordneten Prozess kommuniziert; der Aufbau ist
tatsächlich vom übergeordneten Prozess erledigt. Dies ermöglicht einige der netten Funktionen von makepp, z
Repositories für die Arbeit mit rekursiven Make-Aufrufen. Diese Technik wird jedoch
funktioniert nicht, wenn Sie bei unterschiedlichen Aufrufen von unterschiedliche Befehlszeilenoptionen verwenden
rekursives Make. Bevor Sie dies verwenden, versuchen Sie es mit „--hybrid-recursive-make“.

Die Option „--traditional-recursive-make“ bewirkt, dass makepp rekursive Makes auf die gleiche Weise ausführt wie
das traditionelle Make, das die Arbeit von mehr Makefiles ermöglicht, aber dann auch Repositorys und
Parallele Builds funktionieren nicht richtig. Diese Option wird nur noch selten benötigt und
makepp teilt Ihnen mit, wenn es auf ein Konstrukt stößt, das dies erfordert.

Wenn Sie diese Option nutzen, häufen sich die Protokolldateien in den verschiedenen Verzeichnissen
das ändert sich zu. Um nur sie loszuwerden, verwenden Sie „makeppclean --logs --recurse“ oder „mppc
-lr".

-v
- ausführlich
Ausführlicher Modus. Erklärt, was erstellt werden soll und warum jede Datei erstellt wird.
Dies kann nützlich sein, wenn Sie der Meinung sind, dass eine Datei zu oft neu erstellt wird.

Diese Option nimmt tatsächlich das, was in die Protokolldatei geschrieben würde, und zeigt es an
der Bildschirm. Normalerweise ist es einfacher, makepp auszuführen und sich dann die Ausgabe von anzusehen
makepplog, das verschiedene Auswahlmöglichkeiten und einige Umschreibungen ermöglicht.

-V
--Version
Drucken Sie die Versionsnummer aus.

--virtual-sandbox
Schreiben Sie keine Build-Informationen von Dateien neu, die nicht durch diesen Makepp-Prozess erstellt wurden. Sehen
Partitionierung in Sandboxen.

-W Dateinamen
--assume-new=Dateinamen
--new-file=Dateinamen
--what-if=Dateinamen
Tut so, als hätte sich die angegebene Datei geändert, sodass alle Ziele, die von dieser Datei abhängen, gelöscht werden
wird wieder aufgebaut. Die Datei selbst wird nicht unbedingt geändert (das kann sein oder auch nicht).
neu erstellt, je nachdem, ob es hinsichtlich seiner Abhängigkeiten auf dem neuesten Stand ist), aber
Alles, was davon abhängt, denkt, dass es sich verändert hat. Dies kann nützlich sein für
Debuggen eines Makefiles.

Makepp sucht nach oben nach einer Datei namens .makepprc beim Start und nochmal nach jedem
Option „-C“ oder „-c“. Jedes Mal, wenn eine solche Datei gefunden wird, aber nur einmal pro Datei, wird sie gelesen
die Datei und analysieren Sie sie als möglicherweise zitierte Optionen in einer oder mehreren Zeilen. im Gegensatz zu den
Wenn Sie die Option „-A“ verwenden, werden die Optionen relativ zu dem Verzeichnis analysiert, in dem sich die Datei befindet.

Makepp betrachtet die folgenden Umgebungsvariablen:

$MAKEFLAGS
Alle Flags in dieser Umgebungsvariablen werden zuvor als Befehlszeilenoptionen interpretiert
alle expliziten Optionen. Alle Befehlszeilenargumente werden in diese Variable eingefügt

Beachten Sie, dass das traditionelle Make diese Variable ebenfalls verwendet. Wenn Sie also beide verwenden müssen
Wenn Sie make und makepp verwenden, sollten Sie die Verwendung von „MAKEPPFLAGS“ in Betracht ziehen.

$MAKEPPFLAGS
Das Gleiche wie „MAKEFLAGS“, soweit es Makepp betrifft. Wenn diese Variable nicht leer ist,
dann wird „MAKEFLAGS“ ignoriert. Manchmal ist dies anstelle von „MAKEFLAGS“ nützlich, wenn Sie
Sie müssen sowohl make als auch makepp verwenden und die Optionen getrennt halten.

$MAKEPP_CASE_SENSITIVE_FILENAMES
Makepp versucht herauszufinden, ob in seinem Standardverzeichnis die Groß-/Kleinschreibung beachtet wird
Erstellen Sie eine Datei und greifen Sie dann mit einem anderen Fall darauf zu. Normalerweise funktioniert das gut,
solange sich alle Dateien, auf die Sie zugreifen, im selben Dateisystem wie Ihr Standard befinden
Verzeichnis, daher sollten Sie diese Option selten verwenden müssen.

Wenn diese Variable in der Umgebung vorhanden ist, wird ihr Wert (0 oder eine leere Zeichenfolge für
false, alles andere für true) überschreibt Makepps Auswahl. Diese Variable ist meistens
nützlich unter Windows, wenn Sie die Standardeinstellung von makepp überschreiben möchten. Wenn nicht
Behandeln Sie Dateinamen unter Berücksichtigung der Groß- und Kleinschreibung, dann konvertiert makepp alle Dateinamen in Kleinbuchstaben.
was gelegentlich zu Schwierigkeiten führt. (Zum Beispiel öffnet Emacs möglicherweise mehrere Puffer
die gleiche Datei.)

Makepp unterstützt derzeit einen Build über mehrere Dateisysteme hinweg nicht gut, falls dies der Fall ist
Bei der anderen wird die Groß- und Kleinschreibung beachtet, bei der anderen wird die Groß- und Kleinschreibung nicht beachtet.

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