makepp_build_cache_control – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

makepp_build_cache – So richten Sie Build-Caches ein und verwenden sie

BESCHREIBUNG

C: reinigen,
schaffen, M: makepp_build_cache_control,
mppbcc, S: Show,
Statistik

A bauen Cache-Speicher ist ein Verzeichnis, das Kopien früherer Ziele enthält, die bereits erstellt wurden
gebaut. Wenn makepp aufgefordert wird, ein neues Ziel zu erstellen, prüft es, ob es es bereits erstellt hat
woanders unter den gleichen Bedingungen, und wenn ja, verlinken oder kopieren Sie es stattdessen einfach
es wieder aufzubauen.

Ein Build-Cache kann unter folgenden Umständen nützlich sein:

· Sie arbeiten an einem Programm und kompilieren es optimiert. Dann entdecken Sie einen Fehler,
und das Ganze im Debug-Modus neu kompilieren. Sie haben den Fehler gefunden und möchten ihn nun beheben
Kompilieren Sie es im optimierten Modus neu. Die meisten Dateien werden identisch sein. Wenn Sie a verwendet haben
Wenn Sie in allen Ihren Kompilierungen einen Cache erstellen, ruft makepp einfach die unveränderten Dateien ab
aus dem Build-Cache, anstatt sie neu zu kompilieren.

Eine ähnliche Situation liegt vor, wenn Sie normalerweise an einer Architektur arbeiten, aber kurzzeitig wechseln
eine andere Architektur, und dann wechselt man zurück. Wenn die alten Dateien noch in der sind
Wenn Sie den Cache erstellen, muss makepp nichts neu kompilieren.

· Sie haben mehrere Kopien eines bestimmten Programms aus Ihrer Versionskontrolle ausgecheckt
System und haben an jeder Verzeichnishierarchie unterschiedliche Änderungen vorgenommen. (z. B. du bist
Beheben verschiedener Fehler in verschiedenen Verzeichnishierarchien.) Die meisten Dateien werden es sein
in beiden Verzeichnishierarchien identisch. Wenn Sie beide mit einem Build-Cache erstellen, wird der
Build in der zweiten Verzeichnishierarchie kann die Dateien einfach aus dem kopieren
Erstellen Sie einen Cache, anstatt identische Dateien neu zu kompilieren.

· Sie haben mehrere Entwickler, die an denselben Quellen arbeiten. Jeder Entwickler ist
Änderungen vornehmen, aber die meisten Dateien sind zwischen den Entwicklern identisch. Wenn alle
Entwickler teilen sich einen Build-Cache. Wenn der Build eines Entwicklers eine Datei kompiliert, dann eine beliebige
Build eines anderen Entwicklers, der die identische Datei (mit derselben Datei) kompilieren muss
Includes usw.) können einfach die zwischengespeicherte Datei kopieren, anstatt die Kompilierung erneut auszuführen.

Ein Build-Cache kann hilfreich sein, wenn alle der folgenden Bedingungen zutreffen:

· Sie haben ausreichend Speicherplatz. Normalerweise speichert makepp viele Kopien von zwischen
jede Datei, die sich ändert, weil es keine Ahnung hat, welche tatsächlich verwendet werden.
Sie können den Build-Cache für bestimmte Dateien deaktivieren, wenn der Build-Cache dies jedoch tun soll
überhaupt nützlich sein, es müssen wahrscheinlich viele Dateien darin enthalten sein.

· Das Erstellen Ihrer Dateien dauert deutlich länger als das Kopieren. Wenn sich der Build-Cache auf dem befindet
Wenn Sie dasselbe Dateisystem verwenden, versucht makepp, Hardlinks zu verwenden, anstatt die Datei zu kopieren.
Makepp muss die Datei verknüpfen oder in den Cache kopieren, wenn die Datei erstellt wird, und dann
muss die Datei verknüpfen oder aus dem Cache kopieren, wenn sie erneut benötigt wird. Außerdem,
Es ist ein geringer Aufwand erforderlich, zu prüfen, ob die benötigte Datei tatsächlich vorhanden ist
den Build-Cache und das Kopieren der Build-Informationen über die Datei sowie die Datei
sich.

Möglicherweise stellen Sie beispielsweise fest, dass sich die Verwendung eines Build-Cache zum Kompilieren nicht lohnt
kleine Module. Es lohnt sich mit ziemlicher Sicherheit nicht, wenn Befehle eine statische Aufladung erzeugen
Bibliothek (eine Archivdatei, libxyz.a), es sei denn, Sie verwenden Links, um Speicherplatz zu sparen.

· Es besteht eine hohe Wahrscheinlichkeit, dass einige Dateien in einem anderen erneut benötigt werden
Zusammenstellung. Wenn Sie eine Software nur einmal kompilieren, ist dies mit Build-Caches möglich
verlangsamen Sie die Dinge nur.

Die Verwendung eines Build-Cache erfordert ein wenig Einrichtungs- und Wartungsaufwand. Bitte nicht
Versuchen Sie, einen Build-Cache zu verwenden, bis Sie verstehen, wie sie funktionieren, wie man sie erstellt und wie man sie erstellt
Verhindern Sie, dass sie ständig wachsen und den gesamten verfügbaren Speicherplatz auf Ihrem Computer beanspruchen
System funktionieren.

Wie a bauen Cache-Speicher PayDay
Wenn Sie einen Build-Cache aktivieren, speichert makepp jedes Mal, wenn eine Datei erstellt wird, eine Kopie in einem
Cache erstellen. Der Name der Datei ist ein Schlüssel, der ein Hash der Prüfsummen aller Dateien ist
Eingaben und der Build-Befehl und die Architektur. Das nächste Mal will Makepp neu aufbauen
Wenn Sie die Datei öffnen, wird geprüft, ob sich im Build-Cache bereits eine Datei mit denselben Prüfsummen befindet.
Wenn ja, wird die Datei aus dem Build-Cache kopiert.

Wenn sich der Build-Cache im selben Dateisystem wie der Build befindet, führen Sie aus Effizienzgründen makepp aus
kopiert die Datei nicht wirklich; Stattdessen wird eine feste Verbindung hergestellt. Das ist schneller und
verbraucht keinen zusätzlichen Speicherplatz. Ebenso, wenn makepp eine Datei herausziehen möchte
Im Build-Cache wird nach Möglichkeit ein Hardlink verwendet oder bei Bedarf kopiert.

WARNUNG: Wichtige Mitteilung Makepp niemals Löscht Dateien aus einem Build-Cache, sofern nicht ausdrücklich dazu aufgefordert wird.
Das bedeutet, dass Ihre Build-Caches unbegrenzt weiter wachsen, sofern Sie sie nicht bereinigen
aktualisieren Sie sie regelmäßig (Einzelheiten siehe unten).

Bauen Caches und Repositories

Durch das Erstellen von Caches und Repositorys (siehe makepp_repositories) können ähnliche Probleme gelöst werden. Für
In manchen Situationen ist ein Repository besser geeignet, während in anderen ein Build-Cache besser geeignet ist
angemessen.

Sie können beides auch kombinieren. Wenn Sie eine riesige Verzeichnisstruktur mit vielen haben
Quellen, von denen Sie nicht möchten, dass jeder Entwickler eine Kopie hat, können Sie diese bereitstellen
als Aufbewahrungsort. Die erzeugten Dateien mit unterschiedlichen Debug-Optionen usw. können dann erstellt werden
flexibler verwaltet durch einen Build-Cache.

Die Hauptunterschiede zwischen einem Build-Cache und einem Repository sind:

· Ein Build-Cache kann nur Dateien speichern, die durch die Build-Prozedur erstellt wurden. Ein Repository kann
haben auch Original-Quelldateien.

· Dateien in einem Repository sollten nicht Änderung im Laufe eines Builds. Ein Build-Cache
gibt es keine solche Einschränkung.

· Dateien in einem Repository müssen in derselben relativen Position vorhanden sein wie die Dateien in
das Build-Verzeichnis. Zum Beispiel, wenn makepp die Datei benötigt Unterverzeichnis1/Unterverzeichnis2/xyz.abc, dann es
schaut nur an Repository-Stammverzeichnis/subdir1/subdir2/xyz.abc. Dateien in einem Build-Cache haben
Alle Informationen zur Verzeichnishierarchie sind verloren gegangen und werden nur auf Grundlage der Eingaben gesucht
und der Befehl, der zu ihrer Herstellung erforderlich war.

· Dateien in einem Repository werden per Softlink mit ihren neuen Speicherorten im Build verknüpft
Verzeichnisse. Dateien in einem Build-Cache werden entweder kopiert oder fest mit ihrem neuen verknüpft
Standorte. Wenn eine Kopie erforderlich ist, ist ein Repository sicherlich schneller.

· Das Erstellen von Caches kostet etwas Zeit, um Dateien darin abzulegen. Ein Repository ist nicht vorhanden
eventuelle Extrakosten (für die aktuelle Auflage, d. h. es fielen natürlich die Kosten für die Erstellung an).
(es ist vorher nicht möglich), erfordert aber oft etwas mehr Vorausplanung.

Im Allgemeinen ist ein Repository nützlicher, wenn Sie einen einzelnen zentralen Build haben möchten
alle Entwickler, von denen sie Dateien übernehmen können. Ein Build-Cache ist das, was Sie brauchen, wenn Sie einen haben
dezentrales System, bei dem ein Entwickler kompilierte Dateien von einem anderen ausleihen sollte
Entwickler.

Sowohl Build-Caches als auch Repositorys können bei Varianten-Builds hilfreich sein. Zum Beispiel, wenn Sie möchten
um alle deine Quellen optimiert zu kompilieren, dann nochmal mit Debugging, dann nochmal optimiert,
Sie können das erneute Kompilieren aller optimierten Dateien vermeiden, indem Sie entweder ein Repository oder ein verwenden
Cache erstellen. Um dies mit einem Repository zu tun, muss man vorausdenken und es explizit sagen
makepp, um ein Repository für die Debugging-Kompilierung zu verwenden, sonst wird Ihr Repository gelöscht
erste optimierte Kompilierung. Mit einem Build-Cache macht makepp weiter und löscht den
Ursprünglich optimierte Kompilierung, kann aber schnell wiederhergestellt werden.

Bauen Cache-Speicher Gruppierung
Eine Gruppe ist eine lose Kopplung von Build-Caches. Es ist locker in dem Sinne, dass Makepp dies nicht tut
damit umgehen, damit die Build-Cache-Verwaltung nicht verlangsamt wird. Davon profitieren Sie
Sie müssen das Offline-Dienstprogramm verwenden. Insbesondere führt der Befehl „clean“ auch Folgendes aus
Reproduzieren. Wenn Sie ein unrealistisches Reinigungskriterium wie „--mtime=+1000“ angeben, nein
Es erfolgt eine Reinigung, nur eine Replikation.

Durch die Gruppierung können Sie Dateien mit mehr Personen teilen, insbesondere wenn Sie über Build-Caches verfügen
auf den Festplatten der Entwickler, um von der harten Verlinkung zu profitieren, die Übermittlungszeit spart und
Festplattenplatz. Die reine Festverknüpfung ist jedoch auf die Vorteile pro Festplatte beschränkt.

Durch die Gruppierung wird die Datei irgendwann nach der Übermittlung durch makepp repliziert
Cache erstellen. Das bedeutet, dass die Datei für alle Datenträger zusammen nur einmal erstellt wird.

Auf Dateisystemen, die eine feste Verknüpfung mit symbolischen Links ermöglichen – was darauf beschränkt zu sein scheint
Linux und Solaris – die Datei ist außerdem physisch nur auf einer Festplatte vorhanden.
Darüber hinaus verbleibt es auf jeder Festplatte, auf der es vor der Replikation erstellt wurde, jedoch nur als
solange es auf diesen Festplatten verwendet wird. In diesem Szenario mit Symlinks können Sie einen oder auswählen
mehr Dateisysteme, auf denen Sie Ihre Dateien lieber physisch haben möchten. Beachten Sie, dass
Erfolgreich erstellte Dateien sind möglicherweise nicht mehr verfügbar, wenn die Festplatte, auf der sie sich befinden, physisch ausfällt
offline. Durch einen Wiederaufbau wird hier Abhilfe geschaffen, und die Auswirkungen können durch eine Ausbreitung abgemildert werden
Dateien auf mehrere bevorzugte Festplatten verteilen.

Die Replikation hat mehrere interessante Einsatzmöglichkeiten:

NFS (auch beim Kopieren möglich)
Sie verfügen über einen zentralen NFS-Server, der den bevorzugten Build-Cache bereitstellt. Jede Maschine
und die Entwicklerfestplatte verfügt über einen lokalen Build-Cache für eine schnelle Übermittlung. Entweder Sie steigen zurück
Laden Sie alle Entwicklerfestplatten auf den NFS-Server und führen Sie die Replikation und Bereinigung durch
zentral, oder Sie replizieren lokal auf jedem NFS-Client-Rechner und behandeln nur den Teil
der dort sichtbaren Gruppe.

Unsicherer Datenträger (auch beim Kopieren möglich)
Wenn Sie auf einer RAM-Disk kompilieren (hoffentlich bearbeiten Sie Ihre Quellen in einem Repository auf einem Safe).
Festplatte) können Sie die sicheren Festplatten als bevorzugte festlegen. Dann erfolgt die Replikation
Migrieren Sie die Dateien auf die sicheren Festplatten, wo sie einen Neustart überleben. Nach jedem Neustart
Sie müssen den RAM-Disk-Build-Cache neu erstellen und zur Gruppe hinzufügen (was auch der Fall sein wird).
Geben Sie eine Warnung aus, die in diesem Fall harmlos ist, da sich die anderen Gruppenmitglieder noch daran erinnern
es).

Vollständige Festplatte (harte Verknüpfung nur zu symbolischen Links)
Wenn eine Ihrer Festplatten notorisch voll ist, können Sie die Build-Caches auf allen erstellen
Andere Festplatten sind vorzuziehen. Auf diese Weise werden die Dateien bei der Replikation von der Datei migriert
volle Festplatte, zufällig auf eine der anderen.

Wie zu - a bauen Cache-Speicher
Wie zu erzählen machenpp zu - bauen Cache-Speicher

Sobald der Build-Cache erstellt wurde, steht er nun für makepp zur Verfügung. Es gibt einige
Optionen, die Sie während der Erstellung angeben können; Einzelheiten finden Sie unter „So verwalten Sie einen Build-Cache“.

Ein Build-Cache wird mit der Befehlszeilenoption --build-cache angegeben
build_cache-Anweisung innerhalb eines Makefiles oder mit dem Regelmodifikator :build_cache.

Die nützlichsten Möglichkeiten, mit Build-Caches zu arbeiten, die ich bisher gefunden habe, sind:

· Legen Sie den Build-Cache-Pfad in der Umgebungsvariablen MAKEPPFLAGS wie folgt fest (zuerst
Variante für Korn Shell oder Bash, zweite für csh):

export MAKEPPFLAGS=--build-cache=/path/to/build/cache
setenv MAKEPPFLAGS --build-cache=/path/to/build/cache

Jetzt verwendet jeder Build, den Sie ausführen, immer diesen Build-Cache, und das ist nicht nötig
noch etwas ändern.

· Geben Sie den Build-Cache in Ihren Makefiles mit einer Zeile wie dieser an:

BUILD_CACHE := /path/to/build_cache
build_cache $(BUILD_CACHE)

Sie müssen dies in alle Makefiles einfügen, die einen Build-Cache verwenden (oder in ein gemeinsames Include).
Datei, die alle Makefiles verwenden). Oder legen Sie dies in Ihr RootMakeppfile:

BUILD_CACHE := /path/to/build_cache
globaler build_cache $(BUILD_CACHE)

Auf einem Mehrbenutzercomputer können Sie einen Build-Cache pro Home-Festplatte einrichten
Vorteil von Links. Möglicherweise finden Sie es praktischer, eine Anweisung wie diese zu verwenden:

build_cache $(find_upwards our_build_cache)

die vom aktuellen Verzeichnis im aktuellen Dateisystem aufwärts bis dorthin sucht
findet ein Verzeichnis namens our_build_cache. Dies kann für alle die gleiche Aussage sein
Benutzer und verweisen dennoch einzeln auf den Cache auf ihrer Festplatte.

Mit Solaris 10 können Home-Verzeichnisse aufwendig neu bereitgestellt werden. Ihr Zuhause wird es tun
offenbar ein eigener Einhängepunkt sein, genannt /Zuhause/$LOGNAME, obwohl es tatsächlich eingeschaltet ist
einer der /export/home* Festplatten neben denen anderer Benutzer. Weil es nicht so ist
wirklich ein separates Dateisystem, Links funktionieren immer noch. Aber nach oben kann man nicht suchen.
Stattdessen können Sie Folgendes tun:

BUILD_CACHE := ${makeperl }

Bauen Caches und Unterschriften

Makepp sucht Dateien im Build-Cache anhand ihrer Signaturen. Wenn Sie verwenden
Bei der standardmäßigen Signaturmethode (Dateidatum + -größe) ruft makepp nur Dateien aus dem ab
Build-Cache, wenn das Dateidatum der Eingabedateien identisch ist. Je nachdem, wie Sie bauen
funktioniert, sind die Dateidaten möglicherweise nie identisch. Zum Beispiel, wenn Sie Dateien auschecken
Da es sich um zwei unterschiedliche Verzeichnishierarchien handelt, entsprechen die Dateidaten wahrscheinlich dem von Ihnen überprüften Zeitpunkt
Die Dateien werden ausgegeben, nicht der Zeitpunkt, zu dem die Dateien eingecheckt wurden (abhängig natürlich von Ihrem
Versionskontrollsoftware).

Was Sie wahrscheinlich möchten, ist, Dateien aus dem Build-Cache abzurufen, wenn die Datei vorhanden ist Inhalt sind
identisch, unabhängig vom Datum. Wenn dies der Fall ist, sollten Sie irgendeine Art von verwenden
eine inhaltsbasierte Signatur. Makepp führt dies standardmäßig für C- und C++-Kompilierungen durch, aber es
verwendet Dateidaten für alle anderen Arten von Dateien (z. B. Objektdateien oder andere Dateien in
der Build-Prozess wird nicht ausdrücklich als C-Quelle oder Include-Datei erkannt). Falls Sie es wollen
andere Arten von Dateien, die mit dem Build-Cache arbeiten sollen (z. B. wenn Sie möchten, dass er mit ihnen funktioniert).
etwas anderes als C/C++-Kompilierungsbefehle), dann könnten Sie eine Anweisung wie diese eingeben
irgendwo oben in Ihrem Makefile:

Signatur MD5

um makepp zu zwingen, Signaturen basierend auf dem Inhalt von Dateien und nicht auf ihrem Datum zu verwenden.

Wie nicht zu Cache-Speicher sicher Dateien

Möglicherweise gibt es bestimmte Dateien, von denen Sie wissen, dass Sie sie niemals zwischenspeichern möchten. Zum Beispiel, wenn
Wenn Sie einen Datumsstempel in eine Datei einbetten, wissen Sie, dass Sie dies unter keinen Umständen tun werden
Ich möchte wegen des Datumsstempels eine frühere Kopie der Datei aus dem Build-Cache holen
ist anders. In diesem Fall ist es reine Zeit- und Speicherplatzverschwendung, es in das zu kopieren
Cache erstellen.

Oder Sie halten es möglicherweise für höchst unwahrscheinlich, dass Sie die endgültige ausführbare Datei zwischenspeichern möchten.
Möglicherweise möchten Sie einzelne Objekte oder gemeinsam genutzte Objekte zwischenspeichern, die bei der Erstellung verwendet werden
ausführbare Datei, aber es ist oft ziemlich unwahrscheinlich, dass Sie eine erstellen genau identisch
aus identischen Eingaben ausführbar. Auch in diesem Fall ist die Verwendung eines Build-Cache eine Verschwendung
Speicherplatz und Zeit auf der Festplatte, daher ist es sinnvoll, es zu deaktivieren.

Manchmal lässt sich eine Datei sehr schnell erstellen und es ist einfach nur Zeitverschwendung, sie dort abzulegen
den Build-Cache, da er genauso schnell generiert wie kopiert werden kann. Du möchtest vielleicht
Deaktivieren Sie selektiv das Caching dieser Dateien.

Sie können den Build-Cache für bestimmte Regeln deaktivieren, indem Sie „: build_cache none“ angeben
eine Regel, etwa so:

our_executable: dateStamp.o main.o */*.so
: build_cache keine
$(CC) $(LDFLAGS) $(Eingaben) -o $(Ausgabe)

Dieses Flag bedeutet, dass Ausgaben dieser bestimmten Regel niemals in die Datei eingefügt werden
Build-Cache, und makepp wird auch nie versuchen, sie aus dem Build-Cache zu ziehen.

Wie zu verwalten a bauen Cache-Speicher
makepp_build_cache_control Befehl ...
mppbcc Befehl ...

makepp_build_cache_control, mppbcc ist ein Dienstprogramm, das Build-Caches für makepp verwaltet.
Was makepp_build_cache_control tut, wird durch das erste Wort seines Arguments bestimmt.

Tatsächlich ist dieses kleine Skript ein Wrapper für den folgenden Befehl, den Sie vielleicht möchten
Rufen Sie direkt in Ihren Cron-Jobs auf, wo möglicherweise der Pfad zu „makeppbuiltin“ benötigt wird:

makeppbuiltin -MMpp::BuildCacheControl-Befehl ...

Sie können diese Befehle auch aus einem Makefile verwenden, nachdem Sie sie geladen haben, mit einem „&“-Präfix als
Für das Beispiel von „create“ folgt:

perl { use Mpp::BuildCacheControl } # Es ist ein Perl-Modul, also verwenden Sie es anstelle von include.

mein_cache:
&create $(CACHE_OPTIONS) $(output) # Rufen Sie ein geladenes Builtin auf.

build_cache $(my_cache vorab erstellen)

Die gültigen Befehle, die auch einige der in beschriebenen Standardoptionen verwenden
makepp_builtins, sind:

erstellen [Möglichkeit ...] Pfad/zum/Cache ...
Erstellt die Build-Caches mit den angegebenen Optionen. Gültige Optionen sind:

Standardoptionen: „-A, --args-file, --arguments-file=Dateiname, -v, --verbose“

-e Gruppe
--erweitern=Gruppe
--extend-group=Gruppe
Fügen Sie den neuen Build-Cache zur „Gruppe“ hinzu. Möglicherweise handelte es sich dabei um einen Einzelplatz
Cache bisher erstellen.

-f
--Macht
Dadurch kann der Cache auch dann erstellt werden, wenn Pfad/zum/Cache existierte bereits. Wenn es war
eine Datei wird gelöscht. Wenn es ein Verzeichnis war, wird es mit was auch immer wiederverwendet
welchen Inhalt es hatte.

-p
--bevorzugt
Diese Option ist nur dann sinnvoll, wenn Sie Build-Caches in der Gruppe haben, die dies zulassen
Harte Verlinkung zu Symlinks. In diesem Fall werden die Mitglieder durch die Reinigung in die migriert
bevorzugte Festplatte. Mit dieser Option können Sie mehrere Caches innerhalb einer Gruppe erstellen
In diesem Fall werden die Dateien zufällig dorthin migriert.

-s n1,n2,...
--subdir-chars=n1,n2,...
Steuert, wie viele Ebenen von Unterverzeichnissen erstellt werden, um die zwischengespeicherten Dateien zu speichern.
und wie viele Dateien sich in jedem Unterverzeichnis befinden. Der erste n1 Charaktere der
Dateiname bilden den Verzeichnisnamen der obersten Ebene und die Zeichen aus n1 zu n2 unten stehende Formular
der Verzeichnisname der zweiten Ebene usw.

Dateien im Build-Cache werden mithilfe von MD5-Hashes von Daten benannt, die makepp verwendet
Jeder Dateiname besteht aus 22 Base64-Ziffern plus dem ursprünglichen Dateinamen. Wenn ein Build-Cache
Dateiname ist 0123456789abcdef012345_module.o, es wird tatsächlich im Build gespeichert
Cache als 01/23/456789abcdef012345_module.o wenn Sie „--subdir-chars 2,4“ angeben.
Tatsächlich ist „--subdir-chars 2,4“ die Standardeinstellung, die für einen riesigen Build-Cache gilt
von maximal 4096 Verzeichnissen mit 416777216 Unterverzeichnissen. Sogar „--subdir-chars 1,2“ oder
Mit „--subdir-chars 1“ kommen Sie ziemlich weit. Auf einem Dateisystem, das für riesige Datenmengen optimiert ist
Verzeichnissen können Sie sogar „-s ''“ oder „--subdir-chars=" sagen, um alle Dateien dort zu speichern
die oberste Ebene.

-m Dauerwellen
--mode=Dauerwellen
--access-permissions=Dauerwellen
Gibt die Verzeichniszugriffsberechtigungen an, wenn Dateien zum Build hinzugefügt werden
Zwischenspeicher. Wenn Sie möchten, dass andere Personen Dateien in Ihren Build-Cache legen, müssen Sie dies tun
Es ist gruppen- oder weltweit beschreibbar. Berechtigungen müssen in Oktalschreibweise angegeben werden.

Da es sich hierbei um Verzeichnisberechtigungen handelt, müssen Sie, wenn Sie Zugriff gewähren, diesen auch gewähren
Führen Sie den Zugriff aus, sonst erhalten Sie eine Reihe seltsamer Fehler. Dh 0700 bedeutet das
Nur dieser Benutzer darf Zugriff auf diesen Build-Cache haben. 0770 bedeutet, dass dieser Benutzer und
Jeder in der Gruppe kann Schreibzugriff auf den Build-Cache haben. 0777 bedeutet das
Jeder kann Zugriff auf den Build-Cache haben. Die sinnvollen Oktalziffern sind 7
(schreiben), 5 (lesen) oder 0 (keine). 3 (Schreiben) oder 1 (Lesen) ist ebenfalls möglich
Der Cache soll verwendet, aber nicht durchsucht werden, d. h. es wäre für einen schwieriger
Böswillige Benutzer finden Dateinamen, die man manipulieren kann.

In einer Gruppe von Build-Caches hat jeder seinen eigenen Wert dafür, sodass Sie ihn erzwingen können
unterschiedliche Schreibberechtigungen auf verschiedenen Festplatten.

Wenn Sie die Berechtigungen nicht angeben, gelten Ihre umask-Berechtigungen zum Zeitpunkt der Erstellung
gelten während der gesamten Lebensdauer des Build-Cache.

reinigen [Möglichkeit ...] /pfad/zu/cache ...
Bereinigt den Cache. Makepp löscht niemals Dateien aus dem Build-Cache; es liegt an dir
um die Dateien mit diesem Befehl zu löschen. Bei Mehrbenutzer-Caches kann der Sysop dies tun.

Es werden nur Dateien mit einer Linkanzahl von 1 gelöscht (da die Datei sonst nicht abgerufen wird).
sowieso physisch gelöscht – Sie würden einfach eine Datei aus dem Cache entfernen, die anscheinend jemand ist
immer noch interessiert, also könnte es auch jemand anders sein). Die von Ihnen angegebenen Kriterien beziehen sich auf
die tatsächlich zwischengespeicherten Dateien. Jede Build-Infodatei wird gelöscht, wenn ihre Hauptdatei gelöscht wird.
Es bleiben keine leeren Verzeichnisse übrig. Unabhängig von der Linkanzahl und den Optionen, die Sie haben
Geben Sie an, dass jede Datei, die nicht mit ihrer Build-Info-Datei übereinstimmt, gelöscht wird, wenn sie älter ist
als eine Sicherheitsmarge von 10 Minuten.

Die folgenden Optionen benötigen eine Zeitangabe als Argument. Zeitangaben beginnen mit
ein „+“ bedeutet länger her, ein „-“ bedeutet jünger oder nichts bedeutet dazwischen
Nummer, die Sie angeben, und noch eine. Zahlen, die gebrochen sein können, sind standardmäßig Tage.
Ihnen kann jedoch einer der Buchstaben „w“ (Wochen), „d“ (Tage, Standard) oder
„h“ (Stunden), „m“ (Minuten) oder „s“ (Sekunden). Beachten Sie, dass Tage einfach 24 echte Stunden sind
Ignorieren jeglicher Änderung zwischen Sommer- und Winterzeit. Beispiele:

1 vor 24 bis 48 Stunden
24h zwischen 24 und 25 Stunden
0.5 Tage vor 12 bis 36 Stunden
1 W zwischen 7 und 14 Mal vor 24 Stunden
-2 vor weniger als 48 Stunden
+30m vor mehr als 30 Minuten

Alle folgenden Optionen werden mit „und“ kombiniert. Wenn Sie mehrere Sätze wünschen
Bei Kombinationen mit „oder“ müssen Sie diesen Befehl wiederholt mit unterschiedlichen Sätzen aufrufen
Optionen. Führen Sie zuerst diejenigen aus, bei denen Sie die meisten Löschungen erwarten, dann können die anderen dies tun
sei schneller.

Standardoptionen: „-A, --args-file, --arguments-file=Dateiname, -v, --verbose“

-a spec
--eine Zeit spec
--Zugriffszeit spec
Das letzte Mal, als die Datei gelesen wurde. Bei einer verknüpften Datei kann dies jederzeit passieren.
Andernfalls ist dies das letzte Mal, dass die Datei kopiert wurde. Auf schlecht benommenen Systemen
Dies könnte auch der Zeitpunkt der letzten Bandsicherung oder der letzten Erstellung des Suchindex sein. Sie könnten
Versuchen Sie, den Cache von solchen Vorgängen auszuschließen.

Einige Dateisysteme unterstützen das Feld atime nicht, und selbst wenn das Dateisystem
Manchmal schalten Leute die Zugriffszeit auf ihren Dateisystemen aus, weil dadurch mehr Zeit verloren geht
viele zusätzliche Festplatten-I/O-Vorgänge, die bei batteriebetriebenen Notebooks usw. schädlich sein können
Optimierung der Festplattengeschwindigkeit. (Dies kann jedoch möglicherweise behoben werden – siehe
UTIME_ON_IMPORT-Kommentar in Mpp/BuildCache.pm.)

-b
--Mischung
--blend-groups
Normalerweise jeder /pfad/zu/cache Sie geben an, dass die Build-Gruppe separat behandelt wird
Caches, zu denen es gehört. Jede Gruppe wird nur einmal behandelt, auch wenn Sie dies angeben
mehrere Pfade aus derselben Gruppe. Mit dieser Option vermischen Sie vorübergehend alles
die von Ihnen angegebenen Gruppen in einer Gruppe zusammen.

Wenn Sie dies aus Gründen der Sauberkeit tun, kann dies unerwünschte Auswirkungen haben, wenn Sie eine feste Verknüpfung zu Symlinks herstellen können.
weil es dazu führen kann, dass Mitglieder von einer Gruppe in eine andere migrieren. Anschließend nicht gemischt
reinigt, kann es sein, dass sie dann vorzeitig aus der ursprünglichen Gruppe entfernt werden.

-c spec
--ctime spec
--change-time spec
Die letzte Änderungszeit des Inodes der Datei. In einer Verbindungssituation könnte dies der Fall sein
der Zeitpunkt, an dem der letzte Benutzer die Datei anders neu erstellt und damit seinen Link zu getrennt hat
der Cache. Dies könnte auch der Zeitpunkt sein, zu dem die Option „--set-user“ unten verwendet werden musste
den Benutzer ändern. Auf gut funktionierenden Systemen könnte dies auch der Zeitpunkt sein, an dem die
Die letzte Bandsicherung oder die Erstellung eines Suchindex hat ihre Spuren durch das Zurücksetzen verdeckt
eine Zeit.

-m spec
--mtime spec
--modification-time spec
Der letzte Änderungszeitpunkt der Datei. Wie an anderer Stelle erläutert, wird davon abgeraten
damit makepp eine Datei aktualisiert. Die letzte Änderung wird also normalerweise die Zeit sein
der Schöpfung. (Aber in Zukunft kann makepp optional die mtime aktualisieren, wenn
Dateien löschen. Dies dient dazu, dass Links auf Dateisysteme oder Kopien erstellt werden können
verfolgt.)

-g Gruppe
--newgrp=Gruppe
--new-group=Gruppe
Legen Sie die effektive und reale Gruppen-ID auf Gruppe fest (Name oder Zahl). Es darf nur root sein
in der Lage, dies zu tun. Dies ist erforderlich, wenn Sie gruppierte Build-Caches verwenden
Gewähren Sie Schreibzugriff auf die Caches basierend auf der Gruppen-ID. Normalerweise wird das nicht der Fall sein
Ohne dies würde die Root-Gruppe und damit die Replikation nicht beschreibbare Verzeichnisse erstellen
.

Diese Option ist nach dem entsprechenden Dienstprogramm „newgrp“ benannt, das leider nicht so einfach funktioniert
in „Cron“-Jobs oder ähnlichen Setups verwendet werden.

-i
--build-info
--build-info-check
Überprüfen Sie, ob die Build-Informationen mit dem Mitglied übereinstimmen. Dieser Test ist daher ziemlich teuer
Sie könnten darüber nachdenken, diese Option tagsüber nicht anzubieten.

-l
--symlink-check
--symbolic-link-check
Diese Option sorgt dafür, dass jeder symbolische Link, der keine externe Festplatte hat, „sauber“ gelesen wird
Links, um zu überprüfen, ob sie auf das gewünschte Mitglied verweisen. Da dies etwas ist
teuer, es wird empfohlen, dies nur nachts zu tun.

-M spec
--in-mtime spec
--incoming-modification-time spec
Der letzte Änderungszeitpunkt für Dateien im Eingangsverzeichnis. Dieses Verzeichnis ist
Wird für temporäre Dateien mit prozessspezifischen Namen verwendet, die frei geschrieben werden können
Gleichzeitiger Zugriff und dann atomar in den aktiven Teil des Caches umbenannt.
Normalerweise bleiben Dateien hier nur so lange, wie zum Schreiben erforderlich ist, aber das ist möglich
werden verwaist, wenn der Prozess, der sie schreibt, vorher abnormal beendet wird
kann sie entfernen. Dieser Teil des Caches wird zuerst bereinigt, da der Link zählt
im aktiven Teil des Caches können durch verwaiste Dateien unzulässigerweise beeinträchtigt werden.

Die Zeitangabe für „--incoming-modification-time“ muss mit „+“ beginnen und ist der Standardwert
auf „+2h“ (bei Dateien, die mindestens 2 Stunden alt sind, wird davon ausgegangen, dass sie verwaist sind).

-w
--werktags
Dies beeinflusst, wie die Zeitoptionen gezählt werden. Wochenenden werden ignoriert, als ob sie es wären
waren nicht da. Eine Ausnahme besteht, wenn Sie diese Option an einem Wochenende anbieten. Dann das
Wochenende zählt normalerweise. Sie können es also in Cronjobs verwenden, die ab Dienstag laufen
bis Samstag. Die Sommerzeit wird ignoriert. So können Sommerwochenenden ab Samstag beginnen
1:00 Uhr bis Montag 1:00 Uhr oder an Winterwochenenden der südlichen Hemisphäre von Freitag 23:00 Uhr bis
Sonntag 23:00 Uhr oder wie sehr Ihre Zeitzone die Zeit ändert. Feiertage sind auch
nicht berücksichtigt.

-p Perlcode
--perl=Perlcode
--predicate=Perlcode
TODO: Passen Sie diese Beschreibung an Gruppenänderungen an!

Das ist das Schweizer Offiziersmesser. Der Perlcode wird einmal im Skalarkontext aufgerufen
für jeden Cache-Eintrag (also ohne Verzeichnisse und Metainfo-Dateien). Es ist
wird in einer „File::Find“ „gesuchten“ Funktion aufgerufen, also schauen Sie dort nach den Variablen, die Sie finden können
verwenden. Es wurde ein „lstat“ ausgeführt, sodass Sie das Dateihandle „_“ verwenden können.

If Perlcode gibt „undef“ zurück, es ist, als ob es nicht da wäre, das ist das andere
Optionen entscheiden. Wenn es „true“ zurückgibt, wird die Datei gelöscht. Wenn es false zurückgibt, wird die
Die Datei bleibt erhalten.

-s spec
--Größe spec
Die Dateigrößenangabe funktioniert genauso wie die Zeitangabe, mit „+“ für
größer als oder „-“ für kleiner als, mit der Ausnahme, dass die Einheiten „c“ (Bytes) sein müssen
Standard), „k“ (Kilobyte), „M“ (Megabyte) oder „G“ (Gigabyte).

-u Benutzer
--user=Benutzer
--set-user=Benutzer
Diese Option ist sehr unterschiedlich. Es wird nicht angegeben, wann eine Datei gelöscht werden soll. Stattdessen es
gilt für die Dateien, die nicht gelöscht werden. Beachten Sie, dass auf vielen Systemen nur Root möglich ist
darf den Benutzer einer Datei festlegen. Siehe unter „Vorbehalte beim Arbeiten mit Build“.
Caches“, weshalb Sie bei Verwendung möglicherweise den Besitz an einen neutralen Benutzer ändern müssen
Festplattenkontingente.

Diese Strategie funktioniert nur, wenn Sie darauf vertrauen können, dass Ihre Benutzer den Build nicht untergraben
Cache zum Speichern beliebiger (dh nicht entwicklungsbezogener) Dateien, die über ihr Festplattenkontingent hinausgehen.
Der Besitz der zugehörigen Metadatendatei bleibt erhalten, sodass Sie sie jederzeit sehen können
Wer hat eine Datei zwischengespeichert? Wenn Sie diese Option benötigen, müssen möglicherweise mehrere angegeben werden
Zeiten tagsüber.

Je nachdem, wie viel Platz Sie haben und wie viel Platz Sie haben, gibt es verschiedene mögliche Strategien
ob der Build-Cache verknüpfte Dateien enthält oder ob Benutzer nur Kopien haben.
Mehrere Strategien können kombiniert werden, indem sie nacheinander oder unterschiedlich aufgerufen werden
mal. Der Befehl „show“ soll Ihnen dabei helfen, eine geeignete Strategie zu finden.

Bei einer nächtlichen Ausführung (von Dienstag bis Samstag) könnte „--atime +2“ (oder „--mtime“) angegeben werden.
Wenn Sie keine Zeit haben), löschen Sie alle Dateien, die zwei Tage lang niemand gelesen hat.

Wenn Sie Links verwenden, können Sie auch schnelles, nutzloses Wachstum verhindern, das auftritt, wenn
Aufeinanderfolgende Header-Änderungen, die nie einer Versionskontrolle unterliegen, führen zu vielen Objekten
entsteht schnell. So etwas wie ein stündlicher Lauf mit „--mtime=-2h --ctime=+1h“
Tagsüber werden die Typen gefangen, die der Ersteller innerhalb von weniger als einer Stunde gelöscht hat.
und niemand sonst wollte es seitdem.

erklären [Möglichkeit ...] /pfad/zu/cache ...
Dies ist eine Art rekursiver „ls -l“- oder „stat“-Befehl, der den ursprünglichen Besitzer anzeigt
Dies gilt auch für den Fall, dass der Eigentümer der zwischengespeicherten Datei und der Metadatendatei geändert wurde
behält den ursprünglichen Besitzer (gemäß „clean --set-user“). Es zeigt die angegebenen Dateien bzw
alles unter den angegebenen Verzeichnissen.

Die Felder sind in der kurzen Standardform und der langen ausführlichen Form:

MODUS, Modus
Der Oktalmodus der zwischengespeicherten Datei, der normalerweise so ist, wie sie abgelegt wurde, abzüglich der
Bits schreiben.

EL, Ext-Links
Die Anzahl externer Hardlinks zu allen Mitgliedern der Gruppe zusammen.
Nur wenn dieser Wert 0 ist, kann die Datei bereinigt werden.

C, Kopien (nur für gruppierte Build-Caches)
Die Anzahl der Kopien derselben Datei über alle Build-Caches hinweg. Idealerweise dies
ist eines von Systemen, die eine feste Verknüpfung mit symbolischen Links ermöglichen, aber das kann sein
vorübergehend nicht möglich sein, da externe Links zu mehr als einer Kopie vorhanden sind
(In diesem Fall würden wir die Anzahl der Links verlieren, wenn wir sie löschen würden.

S, Symlinks (nur für gruppierte Build-Caches)
Die Anzahl der symbolischen Links zwischen Build-Caches. Idealerweise ist dies die Anzahl der
Erstellen Sie Caches minus eins auf Systemen, die eine feste Verknüpfung mit symbolischen Links ermöglichen.
Aber wie für das vorherige Feld erläutert, kann es sein, dass mehr Kopien als nötig vorhanden sind.
und damit weniger Links.

UID Der Besitzer der zwischengespeicherten Datei. Dies kann mit der Option „clean --user“ geändert werden.

BI-UID
Der Besitzer der Build-Infodatei. Dies wird durch die Reinigung nicht geändert, was sichtbar ist
wer die Datei zuerst erstellt hat.

GRÖßE
Die Größe (einer Kopie) in Bytes.

atime, mtime, ctime
In der langen ausführlichen Form erhalten Sie die Dateizugriffszeit (Lesezeit) und die Änderung
Zeit und die Inode-Änderungszeit (z. B. wenn ein Benutzer seinen externen Link gelöscht hat).
die zwischengespeicherte Datei). In der kurzen Standardform erhalten Sie nur eines der drei Mal
in drei separaten Spalten:

AD, MD, CD
Der Wochentag des Zugriffs, der Änderung oder der Inode-Änderung.

ADATE, MDATE, CDATE
Das Datum des Zugriffs, der Änderung oder der Inode-Änderung.

ATIME, MTIME, CTIME
Die Tageszeit des Zugriffs, der Änderung oder der Inode-Änderung.

MEMBER
Der vollständige Pfad der zwischengespeicherten Datei, einschließlich des Schlüssels, vom Cache-Stammverzeichnis.

Mit „-v, --verbose“ können Sie die für jeden Befehl angezeigten Informationen abrufen
Eindruck, welche Optionen dem Befehl „clean“ gegeben werden sollen. Die Zeiten werden in angezeigt
lesbare Form, sowie die Anzahl der Tage, Stunden oder Minuten das Alter dieser Datei
gerade überschritten hat. Wenn Sie die Option verdoppeln, erhalten Sie zusätzlich die Informationen für jede Option
Gruppenmitglied.

Standardoptionen: „-A, --args-file, --arguments-file=Dateiname, -f, --force, -o,
--output=Dateiname, -O, --outfail, -v, --verbose"

-a
--eine Zeit
--Zugriffszeit
Zeigt die Dateizugriffszeit anstelle der Dateiänderungszeit im nicht ausführlichen Modus an.

-b
--Mischung
--blend-groups
Normalerweise jeder /pfad/zu/cache Sie geben an, dass die Build-Gruppe separat behandelt wird
Caches, zu denen es gehört. Jede Gruppe wird nur einmal behandelt, auch wenn Sie dies angeben
mehrere Pfade aus derselben Gruppe. Mit dieser Option vermischen Sie vorübergehend alles
die von Ihnen angegebenen Gruppen in einer Gruppe zusammen.

-c
--ctime
--change-time
Zeigt die Änderungszeit der Inode-Informationen anstelle der Dateiänderungszeit in nicht ausführlicher Form an
Modus arbeiten können.

-d
--löschbar
Nur löschbare Dateien anzeigen, also solche mit einer externen Linkanzahl von 0.

-p Anleitungen
--muster=Anleitungen
Schnittmuster ist ein Dateinamenmuster im Bash-Stil (z. B. ?, *, [], {,,}), mit dem abgeglichen wird
Mitgliedsnamen nach dem Unterstrich, der sie vom Schlüssel trennt.

-s Liste
- sortieren =Liste
Ändern Sie im nicht ausführlichen Modus die Sortierreihenfolge. Bei der Liste wird die Groß-/Kleinschreibung nicht beachtet
Komma- oder Leerzeichen-getrennte Reihenfolge der Spaltentitel. Es gibt zwei Sonderfälle:
„member“ berücksichtigt nur die Namen nach dem Schlüssel, also die Dateinamen, wie sie sind
außerhalb des Caches. Und es gibt einen speziellen Namen „Alter“, der gruppiert, was auch immer
Datum und Uhrzeit werden angezeigt. Diese Option ist standardmäßig auf „Mitglied, Alter“ eingestellt.

Wenn Sie einen großen Cache haben, dessen Sortierung unerträglich lange dauert oder mehr benötigt wird
Wenn Ihren Prozessen mehr Speicher zur Verfügung steht, können Sie die Sortierung überspringen, indem Sie ein Leerzeichen angeben
Liste.

Statistik [Möglichkeit ...] /pfad/zu/cache ...
Dadurch werden mehrere Statistiktabellen zum Build-Cache-Inhalt ausgegeben. Jeder Tisch
ist in drei Spaltengruppen aufgeteilt. Die erste Spalte variiert für jede Tabelle und ist die
Zeilenüberschrift. Die anderen beiden Gruppen beziehen sich auf die Summe von GRÖßE der Dateien und Anzahl der DATEIEN
für diese Überschrift. Verzeichnisse und Build-Infodateien werden nicht gezählt, daher ist dies ein
Die Größe ist etwas kleiner als die tatsächliche Festplattennutzung und die Anzahl der Dateien etwa halb so groß.

Jede der beiden letztgenannten Gruppen besteht aus drei Spaltenpaaren, einer Spalte mit einem Wert,
und eine für den Prozentsatz der Gesamtsumme, den dieser Wert darstellt. Das erste Paar zeigt
entweder die Größe der Dateien oder die Anzahl der Dateien. Die anderen beiden Paare zeigen das
KUMULeinmal vom Kleinsten zum Größten und einmal umgekehrt.

Die ersten drei Tabellen mit einer ersten Spalte von AD, CD or MD Zugriffszeiten anzeigen, Inode
Änderungszeiten bzw. Änderungszeiten gruppiert nach Tagen. Tage sind eigentlich 24-Stunden-Blöcke
Rückwärtszählen ab der Startzeit des Stats-Befehls. Die Zeile „0“ der ersten
Die Tabelle zeigt somit die Summe der Größen und die Anzahl der Dateien, auf die weniger als einen Tag zugegriffen wurde
vor. Wenn dann auf keine Dateien zugegriffen wurde, gibt es keine Zeile „0“. Zeile „1“ im dritten
In der Tabelle werden die Dateien angezeigt, die zwischen 24 und 48 geändert (d. h. in den Build-Cache geschrieben) wurden
Vor Stunden.

Der nächste Tisch, EL, zeigt externe Links an, also wie viele Build-Bäume eine Datei gemeinsam nutzen
der Build-Cache. Dies ist ein Maß für die Nützlichkeit des Build-Cache. Leider nur
Funktioniert, wenn Entwickler einen Bulk-Cache auf ihrer eigenen Festplatte haben, andernfalls müssen sie ihn kopieren
das keine globale Spur hinterlässt. Je mehr Inhalte über eine größere Anzahl externer Links verfügen, desto
Je größer der Nutzen des Build-Cache.

Wieder der nächste Tisch EL, zeigt die gleichen Informationen wie die vorherige, jedoch gewichtet
nach der Anzahl externer Links. Jedes Byte oder jede Datei mit einer externen Linkanzahl von eins
zählt als eins. Wenn jedoch zehn gezählt wird, werden die Werte zehnmal gezählt. Deshalb
Die Überschriften ändern sich zu *GRÖSSE und *DATEIEN. Dies ist ein hypothetischer Wert, der zeigt, wie
wie viel Festplattennutzung oder wie viele Dateien es gäbe, wenn alle die gleichen Build-Bäume verwendet hätten
kein Build-Cache.

Noch ein Tisch, C: S. kopiert in Symlinks und betrifft nur gruppierte Caches. Im Idealfall alle
Mitglieder existieren in einer Kopie und ein Symlink weniger, als Caches in der Gruppe vorhanden sind.
Symlinks bleiben „0“, bis die Reinigung repliziert wurde. Es kann mehr als eine Kopie geben,
wenn entweder mehrere Personen die identische Datei erstellt haben, bevor sie repliziert wurde, oder wenn
Durch die Replikation wurde die Datei auf einen bevorzugten Datenträger migriert, die Originaldatei befand sich jedoch noch darin
verwenden. Überflüssige Kopien werden zu symbolischen Links, wenn bei der Reinigung festgestellt wird, dass sie nicht mehr vorhanden sind
Externe Links.

Standardoptionen: „-A, --args-file, --arguments-file=Dateiname, -v, --verbose“

-h
--Std
Zeigen Sie die ersten drei Tabellen in viel feinerer Granularität an. Die Spaltenüberschriften
ändern AH, CH or MH entsprechend.

-p Anleitungen
--muster=Anleitungen
Schnittmuster ist ein Dateinamenmuster im Bash-Stil (z. B. ?, *, [], {,,}), mit dem abgeglichen wird
Mitgliedsnamen nach dem Unterstrich, der sie vom Schlüssel trennt. Alle Statistiken
sind auf übereinstimmende Dateien beschränkt.

Vorsichtsmaßnahmen arbeiten, mit bauen Caches
Build-Caches funktionieren unter den folgenden Umständen nicht ordnungsgemäß:

· Wenn der Befehl, den makepp ausführt, tatsächlich nur zum Erstellen einer Datei verwendet wird Aktuelles die Datei und
Baut man es nicht frisch, dann sollte man es tun NICHT Verwenden Sie einen Build-Cache. (Ein Beispiel ist a
Befehl zum Aktualisieren eines Moduls in einer statischen Bibliothek (einer Archivdatei oder einer Datei mit einer
Erweiterung von .a). Wie in makepp_cookbook erläutert, ist dies auf modernen Maschinen fast der Fall
Es ist immer eine schlechte Idee, eine Archivdatei zu aktualisieren – es ist besser, sie von Grund auf neu zu erstellen
jedes Mal aus den unterschiedlichsten Gründen. Dies ist ein weiterer Grund, ein nicht zu aktualisieren
Archivdatei.) Der Grund dafür ist, dass sich der Build-Cache zufällig auf der befindet
Wenn Sie dasselbe Dateisystem verwenden, erstellt makepp einen festen Link, anstatt die Datei zu kopieren. Wenn du dann
Wenn Sie anschließend die Datei ändern, wird die Datei verwendet, die makepp im Build-Cache hat
tatsächlich geändert werden, und Sie könnten möglicherweise die Zusammenstellung eines anderen vermasseln.
In der Praxis kann makepp normalerweise erkennen, dass eine Datei seitdem geändert wurde
Es wird im Build-Cache abgelegt und nicht verwendet, aber manchmal kann es sein, dass es tatsächlich nicht verwendet wird
die Änderung erkennen.

· Zum .o Dateien kann dies leicht falsch sein, da sie (abhängig vom Compiler
und Debug-Level) enthalten den Pfad zur Quelle, aus der sie erstellt wurden. Das kann machen
Debuggen hart. Der Debugger kann Sie dazu auffordern, die Kopie des ursprünglichen Erstellers zu bearbeiten
Quelle oder findet die Datei möglicherweise nicht einmal, wenn der Ersteller keine Kopie mehr hat. Makepp
bietet möglicherweise eines Tages eine Option zum Patchen des Pfads an, was natürlich eine Kopie bedeutet.
statt einer effizienten Verbindung.

· Jede andere Datei, in der ein Pfad kodiert ist, sollte nicht in einen Build-Cache gelegt werden
(Wenn Sie Ihren Build-Cache auf mehrere oder mehrere Verzeichnishierarchien verteilen
Entwickler). In diesem Fall ist das Ergebnis eines Builds in einem anderen Verzeichnis nicht das
Es ist dasselbe, als ob es sich im selben Verzeichnis befände, also ist das gesamte Konzept des Build-Caches so
unzutreffend. Es ist in Ordnung, wenn Sie den Verzeichnispfad beispielsweise in der Befehlszeile angeben
Dies:

&echo prog_path=$(PWD) -o $(output)

denn dann wird die Befehlszeile anders sein und makepp wird das nicht fälschlicherweise abrufen
Datei aus dem Build-Cache. Aber wenn die Befehlszeile nicht anders ist, dann dort
könnte ein Problem sein. Zum Beispiel,

echo prog_path=`pwd` > $(output)

wird nicht richtig funktionieren.

· Bei Verwendung von Links und mit vielen aktiven Entwicklern desselben Projekts auf derselben Festplatte,
Build-Caches können viel Speicherplatz sparen. Aber gleichzeitig für einzelne Benutzer
das Gegenteil kann auch der Fall sein:

Stellen Sie sich vor, Chang wäre der erste, der einen kompletten Bau durchführt. Ching kommt vorbei und bekommt einen Link zu
all diese Dateien. Chang nimmt einige grundlegende Änderungen vor, die dazu führen, dass die meisten Dinge entstehen
wieder aufgebaut. Er checkt sie ein, Chong checkt sie aus und erhält Links zum Build-Cache.
Chang nimmt erneut Änderungen vor, was zu einem dritten Satz Dateien führt.

In diesem Szenario werden unabhängig von der von Ihnen verwendeten Reinigungsstrategie keine Dateien gelöscht.
weil sie alle noch in Gebrauch sind. Das Problem ist, dass sie alle Chang gehören,
Dadurch kann er sein Festplattenkontingent erreichen, und er kann nichts dagegen tun
die meisten Systeme. Siehe den Befehl „clean --set-user“ unter „So verwalten Sie einen Build-Cache“.
Informationen dazu, wie der Systemadministrator die Dateien in einen Cache-Besitzer ohne Kontingent umwandeln könnte.

· Wenn Sie Zeitstempel-/Größensignaturen verwenden, um das Ziel und seinen Build zu überprüfen
info (die Standardeinstellung), dann ist es möglich, einen Signaturalias zu erhalten, wobei nicht-
entsprechende Dateien werden nicht erkannt. Zum Beispiel der Build-Info-Wert MD5_SUM
stimmt möglicherweise nicht mit der MD5-Prüfsumme des Ziels überein. Dies ist normalerweise kein Problem, weil
Aufgrund der Tatsache, dass die Build-Cache-Schlüssel übereinstimmen, wird das Ziel im Build-Cache angezeigt
ist ein Ersatz für das Ziel, das der Build-Info-Datei entsprochen hätte.
Wenn Sie jedoch über Regelaktionen verfügen, die von Build-Informationen abhängen, kann dies zu Problemen führen
in Schwierigkeiten geraten (also tun Sie das nicht). Wenn Sie das beunruhigt, verwenden Sie --md5-check-bc
.

Gleichzeitig Zugang
Build-Caches müssen den gleichzeitigen Zugriff unterstützen, was bedeutet, dass die Implementierung dies tun muss
Sei tolerant gegenüber Rassen. Insbesondere kann es vorkommen, dass eine Datei zwischenzeitlich veraltet (gelöscht) wird
makepp beschließt, ein Ziel zu importieren und gibt den Zeitpunkt an, zu dem der Import abgeschlossen ist.

Darüber hinaus verwenden einige Leute Build-Caches über NFS, was nicht unbedingt kohärent ist. In
Mit anderen Worten, die Reihenfolge der Dateierstellung und -löschung durch den Autor auf einem Host ändert sich nicht
stimmen unbedingt mit der Reihenfolge überein, die ein Leser auf einem anderen Host sieht, und daher Rennen kann keine
Das Problem lässt sich lösen, indem man besonders auf die Reihenfolge der Dateivorgänge achtet. (Aber da ist
Normalerweise beträgt das NFS-Cache-Timeout etwa 1 Minute, was garantiert, dass Schreibvorgänge keine Zeit in Anspruch nehmen
länger als diese Zeitspanne, um sich an alle Leser zu verbreiten. Darüber hinaus typischerweise in
Üben Sie, dass mindestens 99 % der Schreibvorgänge innerhalb einer Sekunde überall sichtbar sind.) Aus diesem Grund
Wir müssen den Fall tolerieren, dass das zwischengespeicherte Ziel und seine Build-Info-Datei dies scheinbar nicht tun
entsprechen. Darüber hinaus gibt es eine besondere Rasse, die auftreten kann, wenn eine Datei gelöscht wird
gleichzeitig gealtert und ersetzt, wobei die Dateien auch nach dem NFS nicht übereinstimmen
Cache-Leerungen. Dies scheint unvermeidbar zu sein.

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