makepp_sandboxes – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

makepp_sandboxes – So partitionieren Sie einen makepp-Build

BESCHREIBUNG

D: --do-build,
--dont-build,
--nicht-lesen,
--do-read, I: --in-sandbox,
--inside-sandbox, O: --out-of-sandbox, S: --Sandkasten,
--sandbox-warn,
--sandbox-warning, V: --virtual-sandbox

Es gibt mehrere Gründe, warum Sie den Dateibaum für ein MakePP partitionieren möchten
bauen:

1. Wenn Sie wissen, dass der Großteil des Baums von den vorgenommenen Änderungen nicht betroffen ist
Quelldateien seit dem vorherigen Build erstellt haben, können Sie makepp anweisen, diese Dateien anzunehmen
in diesen Teilen des Baums sind bereits aktuell, also nicht einmal implizit
Laden ihrer Makefiles, ganz zu schweigen von der Berechnung und Überprüfung ihrer Abhängigkeiten. (Notiz
dass explizit geladene Makefiles jedoch weiterhin geladen werden.)

2. Wenn Sie über mehrere Makepp-Prozesse verfügen, die auf denselben Baum zugreifen, möchten Sie eine Erhöhung durchführen
ein Fehler, wenn Sie feststellen, dass zwei gleichzeitige Prozesse denselben Teil des schreiben
Baum, oder dass ein Prozess einen Teil des Baums liest, der ein gleichzeitiger Prozess ist
Schreiben. In jedem Fall liegt eine Rennbedingung vor, die die relative Reihenfolge der Ereignisse bestimmt
in zwei gleichzeitigen Prozessen (die nicht garantiert werden können) können das Ergebnis beeinflussen.

Makepp verfügt über Sandboxing-Funktionen, die beide Anliegen berücksichtigen.

Sandboxing Optionen
Die folgenden Makepp-Optionen können verwendet werden, um die Sandboxing-Eigenschaften des Unterbaums festzulegen
gegeben durch Weg und alle seine Dateien und potenziellen Dateien:

--dont-build Weg
--do-build Weg
Legen Sie die Eigenschaft „Dont-Build“ fest oder setzen Sie sie zurück. Es wird davon ausgegangen, dass jede Datei mit diesem Eigenschaftssatz
bereits auf dem neuesten Stand sein und es werden keine Build-Prüfungen durchgeführt. Die Standardeinstellung ist zurückgesetzt
(also „do-build“), es sei denn, Sie haben eine „RootMakeppfile“, in diesem Fall alles
außerhalb seiner Teilbaum-ID „dont-build“.

--Sandkasten Weg
--in-sandbox Weg
--inside-sandbox Weg
--out-of-sandbox Weg
Legen Sie die Eigenschaft „in der Sandbox“ fest oder setzen Sie sie zurück. Andernfalls wird ein Fehler ausgelöst
Schreiben Sie eine Datei, in der diese Eigenschaft zurückgesetzt wird. Build-Prüfungen werden weiterhin durchgeführt, es sei denn
Die Eigenschaft „dont-build“ ist ebenfalls festgelegt. Der Standardwert ist festgelegt (z. B. „in-Sandbox“), sofern nicht
es gibt keine --Sandkasten Optionen, in diesem Fall ist die Standardeinstellung für alle anderen Dateien
zurückgesetzt (d. h. „out-of-sandbox“).

--sandbox-warn
--sandbox-warning
Verstöße gegen „In-Sandbox“ und „Nicht gelesen“ werden auf Warnungen statt auf Fehler herabgestuft.
Dies ist nützlich, wenn es Hunderte von Verstößen gibt, sodass Sie alle erfassen können
Sie können sie in einem einzigen Durchlauf überprüfen und entsprechende Korrekturmaßnahmen ergreifen. Ansonsten sehen Sie nur
ein Verstoß pro Makepp-Aufruf, und Sie wissen nicht, wie viele bis dahin verbleiben
Sie sind alle repariert.

--nicht-lesen Weg
--do-lesen Weg
Legen Sie die Eigenschaft „Nicht lesen“ fest oder setzen Sie sie zurück. Andernfalls wird ein Fehler ausgelöst
Lesen Sie eine Datei mit diesem Eigenschaftssatz. Der Standardwert ist zurückgesetzt (dh „do-read“).

--virtual-sandbox
Schreiben Sie keine Build-Informationen von Dateien neu, die nicht durch diesen Makepp-Prozess erstellt wurden. Das
ist nützlich, wenn Sie und Sie gleichzeitig makepp-Prozesse mit überlappenden Sandboxes ausführen
sind sicher, dass keine zwei Prozesse versuchen werden, dasselbe Ziel zu erstellen. Makepp wird es tun
Unterlassen Sie es dann, zusätzliche Informationen zu den gelesenen Dateien zwischenzuspeichern, weil
Möglicherweise gibt es andere gleichzeitige Leser.

Jede dieser drei Eigenschaften gilt für den gesamten Teilbaum, auch für Dateien, bei denen dies nicht der Fall ist
existieren noch. Spezifischere Pfade überschreiben weniger spezifische Pfade. Ein angegebener Pfad kann ein sein
einzelne Datei, auch wenn die Datei noch nicht existiert.

Wenn eine Eigenschaft auf genau demselben Pfad sowohl festgelegt als auch zurückgesetzt wird, wird die angezeigte Option angezeigt
Ganz rechts in der Befehlszeile hat Vorrang.

Sandboxing für BESCHLEUNIGUNG
Wenn Sie verhindern möchten, dass makepp Zeit mit der Verarbeitung von Dateien verschwendet, von denen Sie wissen, dass sie bereits vorhanden sind
aktuell (insbesondere Dateien, die von einem anderen Build-Tool als makepp generiert werden),
dann --dont-build ist die Option für Sie.

Der mit Abstand häufigste Fall für eine solche Optimierung ist, dass man weiß, dass alles nicht stimmt
im oder unterhalb des Startverzeichnisses ist bereits aktuell. Dies kann mitgeteilt werden
makepp mit „--dont-build /. --do-build .".

Sandboxing für Gleichzeitig Prozesse
Eine Technik, die die Build-Latenz reduzieren kann, besteht darin, mehrere makepp-Prozesse laufen zu lassen
am selben Baum. Dies ist um einiges schwieriger zu handhaben als die Verwendung von -j Option,
Es kann aber auch wesentlich effektiver sein, weil:

· Beim Sandboxing können die Prozesse beispielsweise über einen Job auf mehreren Hosts laufen
Warteschlangensystem. Erhöhung der -j limit erschöpft schließlich die CPU-Ressourcen eines
einzelner Host und kann aufgrund übermäßiger Prozessverzweigung sogar den Build verlangsamen.

· -j Parallelisiert derzeit einige der zeitaufwändigen Aufgaben von makepp, wie z. B. das Laden, nicht
Makefiles, Scannen, Erstellen impliziter Abhängigkeiten beim Scannen und Überprüfen
Abhängigkeiten.

Das größte Risiko bei diesem Ansatz besteht darin, dass der Build nichtdeterministisch werden kann, wenn
Prozesse, die möglicherweise gleichzeitig ablaufen, interagieren miteinander. Dies führt zu Build-Systemen
die sporadisch zu falschen Ergebnissen führen und für die es keinen einfachen Mechanismus gibt, um festzustellen, warum
es passiert.

Um diesem Risiko zu begegnen, empfiehlt es sich, den Baum auf gleichzeitig ablaufende Prozesse aufzuteilen
Wenn also ein Prozess unsachgemäß auf das Dateisystem zugreift, liegt ein Fehler vor
sofort deterministisch erhöht. Normalerweise erfolgt dies durch Zuweisung zu jedem einzelnen
gleichzeitiger Prozess eine „Sandbox“, in der geschrieben werden darf, wobei die Sandboxen von Nr
Zwei gleichzeitig ablaufende Prozesse können sich überlappen.

Darüber hinaus markiert jeder Prozess die Sandboxes aller anderen möglicherweise gleichzeitig ablaufenden Prozesse
als „nicht lesen“. Wenn ein Prozess eine Datei liest, ist ein anderer gleichzeitiger Prozess dafür verantwortlich
zum Schreiben (und die daher möglicherweise noch nicht geschrieben wurden), wird ein Fehler ausgelöst
sofort.

Sandboxing für Sequenziell Prozesse
Wenn der Build für gleichzeitige Makepp-Prozesse partitioniert ist, gibt es normalerweise auch eine
sequentielle Beziehung zwischen verschiedenen Prozesspaaren. Beispielsweise kann es eine geben
Dutzende gleichzeitige Kompilierungsprozesse, gefolgt von einem einzelnen Linkprozess, der nicht gestartet werden kann
bis alle Kompilierungsvorgänge abgeschlossen sind. Solche sequentiellen Beziehungen müssen sein
wird durch den Mechanismus erzwungen, der die verschiedenen Makepp-Prozesse orchestriert (z. B.
das Job-Warteschlangensystem).

Wenn Prozesse eine bekannte sequentielle Beziehung haben, besteht normalerweise keine Notwendigkeit, eine auszulösen
Fehler, wenn sie auf denselben Teil des Baums zugreifen, da das Ergebnis trotzdem ist
deterministisch.

Im Allgemeinen ist es jedoch sinnvoll, dies zu spezifizieren --dont-build Optionen für den Abhängigen
Prozess (der Link-Prozess in unserem Beispiel), der ihn über die Bereiche benachrichtigt, die dies bereits getan haben
durch die erforderlichen Prozesse (in unserem Beispiel die Kompilierungsjobs) aktualisiert wurden. In diesem
Auf diese Weise vermeiden wir den Großteil der unnötigen Arbeit, die mit der Nullerstellung von Zielen verbunden war
aktualisiert.

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