makepp_build_check – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

makepp_build_check – Wie makepp entscheidet, Dateien neu zu erstellen

BESCHREIBUNG

A: „architecture_independent“, E: "genaue Übereinstimmung", I: „ignore_action“, O: „only_action“,
T: „target_newer“

Makepp speichert verschiedene Informationen darüber, wie eine bestimmte Datei das letzte Mal erstellt wurde.
Zu diesen Informationen gehören der Build-Befehl, die Architektur und die Signaturen aller
die Abhängigkeiten der Datei. (Alle gespeicherten Informationen befinden sich im Unterverzeichnis .makepp of
Jedes Verzeichnis.) Wenn sich eine dieser Informationen geändert hat, entscheidet makepp normalerweise, dies zu tun
Erstellen Sie die Datei neu. Die Build-Check-Methode ist es, die die Entscheidung von makepp zum Neuaufbau steuert.
Es entscheidet, welche Informationen betrachtet und welche ignoriert werden.

Makepp wählt normalerweise automatisch die richtige Build-Überprüfungsmethode aus. Sie können es jedoch tun
Ändern Sie die Signaturmethode für eine einzelne Regel, indem Sie den Modifikator :build_check verwenden
Regel oder für alle Regeln in einem Makefile mithilfe der build_check-Anweisung oder für alle
Erstellen Sie Makefiles gleichzeitig mit der Befehlszeilenoption -m oder --build-check-method.

Die Daten, die zur Entscheidung über einen Neuaufbau oder einen Repository- oder Build-Cache-Import verwendet werden, werden in gespeichert
die interne Build-Info-Datei. Sie können es mit makeppinfo, mppi anzeigen. Unten jeweils
Die Methode gibt ein Beispiel dafür, wie ihre Schlüssel angezeigt werden.

Bauen aus der Ferne überprüfen Methoden inklusive in Verteilung
Derzeit sind in der Distribution fünf Build-Check-Methoden enthalten:

genaue Übereinstimmung
Bei dieser Methode werden die Änderungsdaten der Datei als Signaturen verwendet. Es baut die wieder auf
Ziele, es sei denn, alle der folgenden Bedingungen sind erfüllt:

· Die Signatur jeder Abhängigkeit ist dieselbe wie beim letzten Build.

· Die Signatur jedes Ziels ist dieselbe wie beim letzten Build (d. h. „noone“)
hat mit den Zielen herumgespielt, seit makepp sie gebaut hat).

· Der Build-Befehl hat sich nicht geändert.

· Die Maschinenarchitektur (oder was Perl darunter versteht) hat sich nicht geändert.

„exact_match“ ist die Standardmethode, es sei denn, Sie erstellen ein Makefile neu (siehe unten).
Dies ist eine äußerst zuverlässige Methode, um korrekte Builds sicherzustellen, und das ist fast immer der Fall
Sie wollen. Es hat jedoch einige Nebenwirkungen, die überraschend sein können:

· Wenn Sie mit dem herkömmlichen make kompiliert haben und dann zu makepp wechseln,
Alles wird neu kompiliert, wenn Sie makepp zum ersten Mal ausführen.

· Wenn Sie die Informationen von makepp darüber beschädigen, was beim letzten Build passiert ist (z. B.
Sie löschen das Unterverzeichnis „.makepp“ oder kopieren es nicht, wenn Sie alles kopieren
sonst), dann wird ein Neuaufbau ausgelöst.

· Wenn Sie eine Datei durch eine ältere Version ersetzen, wird ein Neuaufbau ausgelöst. Das ist
normalerweise das, was Sie wollen, aber es könnte überraschend sein.

· Wenn Sie eine Datei ändern, die außerhalb der Kontrolle von makepp liegt (z. B. wenn Sie die Datei ausführen
Wenn Sie den Kompilierungsbefehl selbst ausführen, erstellt makepp die Datei beim nächsten Mal neu. (Wenn
Wenn Sie dies vermeiden möchten, sehen Sie sich die Befehlszeilenoption „--dont-build“ an.)

· Architekturunabhängige Dateien werden neu erstellt, wenn Sie zu einer anderen wechseln
die Architektur. Dies ist in der Regel kein Problem, da sie oft nicht lange dauern
bauen. Der Grund, warum alle Dateien mit der Architektur getaggt sind, statt
Nur Binärdateien sind oft sogar ASCII-Dateien architektur-
abhängig. Beispielsweise lässt sich die Ausgabe des Solaris-Programms „lex“ nicht weiterkompilieren
Linux (oder zumindest war das so, als ich es das letzte Mal ausprobiert habe).

Konkret wird eine Datei nicht neu erstellt oder kann aus dem Repository oder Build abgerufen werden
Cache, wenn die folgende Befehlsausgabe gleich bleibt, also mit den Signaturen von übereinstimmt
die Abhängigkeiten:

mppi -k'COMMAND ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' Datei

Architektur_unabhängig
Die Methode „architecture_independent“ ist mit der Methode „exact_match“ identisch, außer dass dies der Fall ist
Überprüfen Sie nicht die Architektur. Dies kann für architekturunabhängige Dateien nützlich sein,
die nicht neu erstellt werden müssen, wenn Sie zu einer anderen Architektur wechseln. Für
Beispielsweise müssen Sie „bison“ unter Solaris wahrscheinlich nicht erneut ausführen, wenn Sie es bereits ausgeführt haben
Linux.

Die Methode „architecture_independent“ lässt sich am besten verwenden, indem man sie mit der angibt
Modifikator „:build_check Architecture_independent“ für jede Regel, die erzeugt
Architekturunabhängige Dateien. Makepp geht standardmäßig nie davon aus, dass Dateien vorhanden sind
architekturunabhängig, weil eben .c Dateien können architekturabhängig sein. Für
Beispielsweise lässt sich die Ausgabe von Solaris lex nicht unter Linux kompilieren, oder zumindest nicht
Ich würde es nicht das letzte Mal versuchen. Daher müssen Sie diese Build-Prüfmethode manuell angeben
alle Dateien, die wirklich architekturunabhängig sind.

Konkret wird eine Datei nicht neu erstellt oder kann aus dem Repository oder Build abgerufen werden
Cache, wenn die folgende Befehlsausgabe gleich bleibt, also mit den Signaturen von übereinstimmt
die Abhängigkeiten:

mppi -k'COMMAND SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' Datei

ignorieren_aktion
Die Methode „ignore_action“ ist die gleiche wie „exact_match“, außer dass sie keine Prüfung durchführt
die Aktionszeichenfolge (der Befehl). Manchmal kann sich ein Befehl ändern, ohne dass Sie dies möchten
einen Neuaufbau erzwingen.

Beispielsweise möchten Sie möglicherweise explizit ein Datum in Ihren Befehl einfügen, um zu protokollieren, wann
Der Build wurde durchgeführt, aber Sie möchten nicht jedes Mal einen Neuaufbau erzwingen, wenn der Befehl ausgeführt wird
hingerichtet. Zum Beispiel,

BUILD_DATE := $(Shell-Datum)

mein_programm: $(MODULES).o
$(CXX) $(Eingaben) -DBUILD_DATE="\"$(BUILD_DATE)\"" date_stamp.c -o $(Ausgabe)

Dies wird kompiliert date_stamp.c mit dem letzten Build-Datumsstempel, erzwingt aber kein a
neu kompilieren, wenn sich das Datum ändert. Leider fällt etwas anderes zum Link ein
Bei Befehlsänderungen (z. B. Sie ändern Linker-Optionen) wird auch kein Neuaufbau ausgelöst.

Dies ist auch in Verbindung mit $(changed_inputs) oder $? nützlich. Variable für
Aktionen, die lediglich ein Ziel aktualisieren, anstatt es von Grund auf neu zu erstellen. Für
Sie könnten beispielsweise eine .a-Datei wie folgt aktualisieren:

libmine.a: *.o: build_checkignore_action
$(AR) ru $(output) $(changed_inputs)

Dies funktioniert meistens immer noch, wenn Sie vergessen, „: build_check“ anzugeben
ignore_action". Nehmen wir jedoch an, dass sich keine der .o-Dateien geändert hat. Der Befehl
wird jetzt „ar ru libmine.a“ heißen, was wahrscheinlich anders ist als beim letzten Mal
(z. B. „ar ru libmine.a buggy_module.o“), sodass makepp den Befehl ausführt. In diesem
In diesem Fall wird der Befehl nichts anderes tun, als Zeit zu verschwenden.

Vom Erstellen solcher .a-Dateien wird abgeraten, da dadurch möglicherweise veraltete .o-Dateien darin zurückbleiben
das Archiv. Wenn Sie eine Quelldatei löschen, befindet sich die .o-Datei immer noch in der .a-Datei.
und dies kann zu fehlerhaften Builds führen. Es ist besser, eine .a-Datei wie folgt zu erstellen:

libmine.a : *.o
&rm $(Ausgabe)
$(AR) ru $(Ausgabe) $(Eingaben)

Konkret wird eine Datei nicht neu erstellt oder kann aus dem Repository oder Build abgerufen werden
Cache, wenn die folgende Befehlsausgabe gleich bleibt, also mit den Signaturen von übereinstimmt
die Abhängigkeiten:

mppi -k'ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' Datei

target_newer
Die Methode „target_newer“ berücksichtigt nur das Dateidatum. Wenn eine Abhängigkeit größer ist
aktueller als das Ziel ist, wird das Ziel neu erstellt. Dies ist der Algorithmus, der die
traditionelles Unix um Dienstprogramm verwendet.

Die Methode „target_newer“ ist nicht so sicher wie die Methode „exact_match“, da dies nicht der Fall ist
Lösen Sie eine Neuerstellung aus, wenn Sie den Build-Befehl ändern oder eine Datei durch eine ersetzen
ältere Version. Manchmal kann es auch zu Verwirrung kommen, wenn die Uhren nicht richtig funktionieren
synchronisiert. Wenn eine Datei beispielsweise irgendwie das Datum 4. Juni 2048 erhält, dann
Bis 2048 wird jedoch jede Datei, die von dieser Datei abhängt, neu erstellt
Die Datei ändert sich nicht. Auch der Wechsel zu einer anderen Architektur löst kein Problem aus
neu aufbauen. Es verhindert das Abrufen des Ziels einer Regel aus einem Build-Cache, da kein solcher vorhanden ist
einzigartige Signatur, die der endlosen Menge von Paaren zugeordnet werden kann, die das erfüllen
Beziehung neuer als.

Es gibt jedoch einige Fälle, in denen Sie möglicherweise die Methode „target_newer“ verwenden möchten:

· Wenn es für einen Benutzer sinnvoll ist, eine Datei außerhalb der Kontrolle von makepp zu erstellen.
Das vielleicht häufigste Beispiel sind die Befehle, die das Makefile generieren
selbst, also die Autokonfigurationsprozedur. Benutzer geben häufig die Konfiguration aus
Befehle manuell ausführen, aber Makefiles verfügen oft über eine Möglichkeit, sich selbst zu aktualisieren
automatisch. In diesem Fall möchten wir die Neuerstellung des Makefiles nicht erzwingen
selbst, wenn der Benutzer den Befehl manuell eingegeben hat, also die Methode „target_newer“.
geeigneter als die Methode „exact_match“. In der Tat, wenn Makepp es versucht
Wenn Sie ein Makefile erstellen, wird „target_newer“ zur Standardmethode, bis es fertig ist
Erstellen des Makefiles.

· Wenn es für einen Benutzer sinnvoll ist, eine Datei zu ändern, nachdem makepp sie erstellt hat. Für
Wenn beispielsweise eine Datei nicht vorhanden ist, möchten Sie sie möglicherweise von einer zentralen Datei kopieren
Speicherort oder checken Sie es aus einem Repository aus; aber der Benutzer sollte es dürfen
modifizieren Sie es. Wenn Sie die standardmäßige Build-Prüfmethode „exact_match“ verwenden, wird makepp dies tun
Erkennen Sie, dass der Benutzer die Datei geändert hat, und erzwingen Sie daher eine neue Kopie von
Der zentrale Standort oder ein neuer Checkout werden gelöscht, wodurch die Änderungen des Benutzers gelöscht werden.

Wenn Sie die Zeitstempel manuell überprüfen müssen, sehen Sie sich die Makeppinfo-Beispiele an, um zu erfahren, wie Sie sie abrufen können
der Pfad jeder Abhängigkeit.

only_action
Die sehr spezifische Methode „only_action“ führt die Aktion nur aus, wenn der Befehl
Die Zeichenfolge unterscheidet sich von der letzten Ausführung. Zum Beispiel,

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

veröffentlicht eine Datei, wiederholt dies jedoch nicht, wenn sich die Datei ändert. Beachten Sie, dass &ln
Der Befehl ist integriert und daher kostengünstig, aber makepp muss trotzdem abzweigen und a überwachen
Prozess, um die gesamte Aktion auszuführen. Wenn Sie also viele Dateien veröffentlichen möchten, klicken Sie hier
ist immer noch ein Vorteil. Tatsächlich haben wir die Methode nicht angegeben, da sie das Ziel ist
ist ein symbolischer Link, dieser Build-Check wird automatisch verwendet. Sie müssen nur
Geben Sie es für andere Befehle an, die ausschließlich vom Befehl abhängen (was normalerweise der Fall ist).
enthält die Namen der Eingänge):

%.list: %.x: build_check only_action
&echo $(Eingaben) -o $(Ausgabe)

Konkret wird eine Datei nicht neu erstellt oder kann aus dem Repository oder Build abgerufen werden
Cache, wenn die folgende Befehlsausgabe gleich bleibt, also mit den Signaturen von übereinstimmt
die Abhängigkeiten:

mppi -kCOMMAND-Datei

Andere Build-Check-Methoden sind möglich. Sie können Ihre eigene Build-Überprüfungsmethode schreiben
Erstellen eines Moduls „Mpp::BuildCheck::MyMethod“. Lesen Sie die Dokumentation in
Mpp/BuildCheck.pm in der makepp-Distribution. Höchstwahrscheinlich möchten Sie Ihren Build überprüfen
Methode, die von „Mpp::BuildCheck::exact_match“ erbt, also lesen Sie auch die Dokumentation.

Es ist häufiger sinnvoll, den Signaturmechanismus zu ändern, als die Build-Prüfung zu ändern
Mechanismus direkt. Bevor Sie den Build-Überprüfungsmechanismus ändern, prüfen Sie, ob Ihr Problem vorliegt
Besser ist es, die Signaturen zu ändern (siehe makepp_signatures für Details).

Hier sind einige Gründe, warum eine benutzerdefinierte Build-Überprüfungsmethode nützlich sein könnte:

· Wenn Sie möchten, dass makepp einen Teil des Befehls ignoriert. Zum Beispiel, wenn Sie Befehle haben
in Ihrem Makefile so:

xo : xc
ssh $(REMOTE_MACHINE) cc $< -o $@

Möglicherweise möchten Sie, dass makepp keinen Neuaufbau erzwingt, wenn sich „$(REMOTE_MACHINE)“ ändert. Du
könnte die Methode „exact_match“ so ändern, dass sie über SSH-Befehle Bescheid weiß und diese ignoriert
Maschinenname. Suchen Sie in :dispatch nach einer anderen Möglichkeit, dies zu erreichen.

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