DE202012013461U1

DE202012013461U1 - Vorrichtungen zur Berechnung von Prüfsummen für effektives Caching bei konzinuierlich verteilten Builds

Info

Publication number: DE202012013461U1
Application number: DE202012013461.2U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2011-10-28
Filing date: 2012-10-26
Publication date: 2017-01-27
Anticipated expiration: 2022-10-27
Also published as: EP2771788B1; EP2771788A1; WO2013063376A1; US8863084B2; EP2771788A4; CN103999050A; US20130111440A1; CN103999050B

Abstract

System, das Folgendes umfasst: einen oder mehrere Computer; ein computerlesbares Medium, das mit dem einen oder mehreren Computer(n) gekoppelten ist und auf dem Anweisungen gespeichert sind, die bei Ausführung durch den einen oder mehrere Computer dazu führen, dass der eine oder mehrere Computer Operationen wie folgt ausführen: das Erstellen einer ersten Kompilierungsstrategie für ein erstes Build; das Erbringen des genannten ersten Builds unter Verwendung dieser ersten Kompilierungsstrategie; das Berechnen einer ersten Prüfsumme für diesen ersten Build; das Speichern der genannten ersten Kompilierungsstrategie und dieser ersten Prüfsumme; das Berechnen einer zweite Prüfsumme für ein zweites Build; das Ermitteln, ob diese zweite Prüfsumme mit dieser erster Prüfsumme identisch ist; das Erstellen – bei Ermittlung, dass diese zweite Prüfsumme nicht mit dieser ersten Prüfsumme identisch ist – einer zweiten Kompilierungsstrategie; das Speichern dieser zweiten Kompilierungsstrategie und dieser zweiter Prüfsumme, und das Erbringen des zweiten Builds unter Verwendung dieser zweiten Kompilierungsstrategie; und das Abrufen – bei Ermittlung, dass diese zweite Prüfsumme mit dieser erster Prüfsumme identisch ist – dieser erster Kompilierungsstrategie und Erbringen des diesen zweiten Builds unter Verwendung dieser erster Kompilierungsstrategie.

Description

Aufgabengebiet:
_Aspekte der vorliegenden Erfindung beziehen sich auf Systeme und computerlesbare Medien zur Erstellung von Software. Insbesondere Aspekte der vorliegenden Erfindung in Bezug auf die Berechnung von Prüfsummen zur Bestimmung, ob eine Build-Strategie, die für eine frühere Konfigurationsdatei berechnet wurde, für eine spätere Konfigurationsdatei wiederverwendet werden kann.
Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
Hintergrund:
Bei der Entwicklung von Software wird diese oft zunächst als Programmcode in einer Programmiersprache geschrieben, die für Menschen leicht zu verstehen ist. Der Programmiercode geht durchläuft dann einen Kompilierungsprozess, um den ausführbaren Code zu erstellen, den der Computer leicht verstehen kann. Ein Kompilier- und Linkprozess wird durchgeführt, um den ausführbaren Code zu generieren. Computer folgen Sie den Anweisungen im ausführbaren Code, um alle Computerfunktionen ausführen, einschließlich der Anzeige der Benutzeroberfläche, Verbindung mit dem Internet und Ausführung anderer Computergaben wie die Ermöglichung von Textverarbeitung und Surfen im Internet, Bereitstellung von Webdiensten usw.
Programmierer verwenden zum Schreiben der Computersoftware einen Editor ähnlich einem Textverarbeitungsprogramm. Der Editor ermöglicht es dem Programmierer in der Regel, ihr Programm einzugeben, es zu kompilieren und dann zum Testen auszuführen. Um große Softwareprogramme zu verwalten, werden die Programme oft in separate Einheiten unterteilt, sogenannte Module. Ein Modul ist Computercode, der geschrieben wird, um eine oder mehrere damit verbundene Aufgaben zu bearbeiten; der Code kann oft zusammen als eine einzelne Einheit verwaltet werden. Zur Verwaltung bestimmter Aufgaben können dann verschiedene Module geschrieben werden. Um beispielsweise eine Programm zum Surfen im Internet zu schreiben, kann es ein Modul zur Verwaltung von Lesezeichen geben, ein Modul zur Abwicklung der Kommunikation mit Webdiensten usw.
Ein Softwareprogramm oder ein Modul, das in Programmcode geschrieben ist, kann auf andere Softwareprogramme oder Module verweisen. Dies ist ein effizienter Weg, ein Computerprogramm zu schreiben, da es einem Computerprogrammierer ermöglicht, bereits erstellten Code zu verweisen, und er somit nicht den gesamten Code von Grund auf neu erstellen muss. Stattdessen kann der Programmierer Teile von Codebibliotheken einbinden oder nutzen, die zuvor von anderen geschrieben worden sein können. Der Programmierer kann sich dann auf das Schreiben der operativen Teile seiner eigenen, spezifischen Softwaremodule konzentrieren.
Wenn aus dem Programmiercode ausführbarer Code generiert wird, muss der Codegenerator wissen, in welcher Reihenfolge die Module kompiliert werden müssen. Ein erstes Modul, das auf einem zweiten Modul beruht, muss nach dem zweiten Modul kompiliert werden. Programmierer schreiben Konfigurationsdateien, um dem Codegenerator mitzuteilen, welche Konfigurationsdateien auf andere Konfigurationsdateien angewiesen oder davon abhängig sind. Eine Konfigurationsdatei ist ein Dokument, in dem die Abhängigkeiten der Module deklariert werden, damit der Codegenerator die Kompilierung der Module in der richtigen Reihenfolge vornehmen kann. Somit deklarieren die Konfigurationsdateien die Abhängigkeiten der Softwaremodule. Die Abhängigkeiten der Softwaremodule können die Reihenfolge beeinflussen, in der die Module kompiliert werden. In einigen Fällen sind Module nicht voneinander abhängig und können daher parallel kompiliert werden.
Traditionell wird ein Modul als ein Satz definiert, bei dem die Elemente einzelne Dateien bzw. anderen Modulen sind. Wenn es eine Änderung bei einem der Elemente in einem Modul gibt, muss das komplette Modul neu kompiliert werden. Folglich müssen alle Module, die von einem bestimmten, neu kompilierten Modul abhängig sind, ebenfalls neu kompiliert werden. Ferner erfolgt bei jeder Neukompilierung der Module eine Neuberechnung eines Kompilierungsplans mit einer Strategie für das Kompilieren, Linken und andere Aufgaben.
Solche Neukompilierungen können bei großen Softwareprodukten rechenintensiv sein und wertvolle Zeit und Ressourcen kosten. Eine bessere Technik der Neukompilierung zur Reduzierung des Rechenaufwands ist daher wünschenswert. Ein Ansatz ist die Prüfung der Zeitstempel von Dateien, um zu ermitteln, ob eine erneute Kompilierung erforderlich ist. Wenn sich der Zeitstempel seit einer vorhergehenden Kompilierung nicht geändert hat, kann der Kompilierungsvorgang übersprungen werden, weil es keine Aktualisierungen oder Änderungen an einem Softwaremodul vorgenommen wurden. Ein Nachteil einer solchen Vorgehensweise ist jedoch Folgendes: Wenn die Zeitstempel nicht aktualisiert werden, würden die Änderungen am Programmcode im Softwaremodul nicht im ausführbaren Code aktualisiert. Außerdem können Abweichungen bei den Zeitstempeln, z. B. bei Computern mit unterschiedlichen Zeiteinstellungen, zu nicht hermetischen Builds führen, bei denen einige Abhängigkeiten nicht enthalten sind, was zu unerwünschten Ergebnissen führen kann. Angesichts solcher Nachteile wird nach einem besseren Ansatz zur Reduzierung der des Rechenaufwands bei der erneuten Kompilierung gesucht.
Zusammenfassung
Bei einem Aspekt der vorliegenden Erfindung kann die Erfindung ein von einer Datenverarbeitungsvorrichtung ausgeführtes Verfahren enthalten, das Folgendes beinhaltet: Erstellen einer ersten Kompilierungsstrategie für ein erstes Build; Erbringen des ersten Builds mithilfe der erste Kompilierungsstrategie; Berechnen einer erste Prüfsumme für das erste Build; Speichern der ersten Kompilierungsstrategie und der ersten Prüfsumme; Berechnen einer zweiten Prüfsumme für das zweite Build; Ermitteln, ob die zweite Prüfsumme mit der ersten Prüfsumme identisch ist; bei Feststellung, dass die zweite Prüfsumme nicht mit der ersten Prüfsumme identisch ist: Erstellen einer zweiten Kompilierungsstrategie; Speichern der zweiten Kompilierungsstrategie und der zweiten Prüfsumme und Erbringen des zweiten Builds mithilfe der zweiten Kompilierungsstrategie; und bei Feststellung, dass die zweite Prüfsumme mit der ersten Prüfsumme identisch ist: Abrufen der ersten Kompilierungsstrategie und Erbringen des zweiten Builds mithilfe der ersten Kompilierungsstrategie.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren enthalten, bei dem die erste Prüfsumme die Prüfsumme eines globalen Builds ist; und die Prüfsumme des globalen Builds wird anhand einer oder mehrerer lokaler Build-Prüfsummen berechnet.
Bei einem weiteren Aspekt der vorliegenden Erfindung beinhaltet das Verfahren die Ermittlung, ob sich eine für das erste Build berechnete lokale Build-Prüfsumme für das zweite Build nicht geändert hat, und Wiederverwendung von Teilen der ersten, mit der lokalen Build Prüfsumme verknüpften Kompilierungsstrategie bei der zweiten Kompilierungsstrategie.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren enthalten, bei dem die Informationen des Dateisystems nach Pfadnamen sortiert werden, um die lokalen Build-Prüfsummen zu berechnen.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren enthalten, bei dem die Dateisysteminformationen eine Prüfsumme enthalten.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren enthalten, das Folgendes umfasst: Erbringen des ersten Builds mithilfe der erste Kompilierungsstrategie und darüber hinaus die Untersuchung des Inhalts einer Konfigurationsdatei, um die Abhängigkeiten zu ermitteln; und das Berechnen einer lokalen Build-Prüfsumme für jede Abhängigkeit der Konfigurationsdatei.
Bei einem weiteren Aspekt der vorliegenden Erfindung beinhaltet das Verfahren die Berechnung eines transitiven Abschlusses auf der Basis der Abhängigkeiten der Konfigurationsdateien.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren enthalten, bei dem für jede Konfigurationsdatei des berechneten transitiven Abschlusses eine lokale Build-Prüfsumme berechnet wird.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren enthalten, bei dem die Prüfsumme mithilfe einer XOR-Funktion berechnet wird.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren enthalten, bei dem die Berechnung der ersten Prüfsumme zusätzlich die Durchführung einer deterministischen Sortierung beinhaltet; Berechnen einer lokalen Build-Prüfsumme mit der deterministischen Sortierung; und Berechnen der ersten Prüfsumme anhand der lokalen Build-Prüfsumme, wobei die erste Prüfsumme die Prüfsumme eines globalen Builds ist.
Bei einem weiteren Aspekt der vorliegenden Erfindung kann die Erfindung Folgendes enthalten: ein aus einem oder mehreren Computer bestehendes System; ein computerlesbares Medium, das für den oder die Computer eines zusammengestellt ist, und auf dem Anweisungen gespeichert sind, die bei der Ausführung durch den bzw. die Computer dazu führen, dass von dem bzw. den Computer(n) die folgenden Operationen ausgeführt werden: Erstellen einer ersten Kompilierungsstrategie für ein erstes Build; Erbringen des ersten Builds mithilfe der erste Kompilierungsstrategie; Berechnen einer erste Prüfsumme für das erste Build; Speichern der ersten Kompilierungsstrategie und der ersten Prüfsumme; Berechnen einer zweiten Prüfsumme für das zweite Build; Ermitteln, ob die zweite Prüfsumme mit der ersten Prüfsumme identisch ist; bei Feststellung, dass die zweite Prüfsumme nicht mit der ersten Prüfsumme identisch ist: Erstellen einer zweiten Kompilierungsstrategie; Speichern der zweiten Kompilierungsstrategie und der zweiten Prüfsumme und Erbringen des zweiten Builds mithilfe der zweiten Kompilierungsstrategie; und bei Feststellung, dass die zweite Prüfsumme mit der ersten Prüfsumme identisch ist: Abrufen der ersten Kompilierungsstrategie und Erbringen des zweiten Builds mithilfe der ersten Kompilierungsstrategie.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein System, enthalten, bei dem die erste Prüfsumme die Prüfsumme eines globalen Builds ist; und die Prüfsumme des globalen Builds wird anhand einer oder mehrerer lokaler Build-Prüfsummen berechnet.
Bei einem weiteren Aspekt der vorliegenden Erfindung beinhaltet das computerlesbare Medium des Systems zusätzliche, darauf gespeicherte Anweisungen, die bei der Ausführung durch den bzw. die Prozessor(en) dazu führen, dass von dem bzw. den Prozessor(en) die folgenden zusätzlichen Operationen ausgeführt werden: die Ermittlung, ob sich eine für das erste Build berechnete lokale Build-Prüfsumme für das zweite Build nicht geändert hat, und Wiederverwendung von Teilen der ersten, mit der lokalen Build Prüfsumme verknüpften Kompilierungsstrategie bei der zweiten Kompilierungsstrategie.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein System enthalten, bei dem die Informationen des Dateisystems nach Pfadnamen sortiert werden, um die lokalen Build-Prüfsummen zu berechnen.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein System enthalten, bei dem die Dateisysteminformationen eine Prüfsumme enthalten.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein System enthalten, das Folgendes umfasst: Erbringen des ersten Builds mithilfe der erste Kompilierungsstrategie und darüber hinaus die Untersuchung des Inhalts einer Konfigurationsdatei, um die Abhängigkeiten zu ermitteln; und das Berechnen einer lokalen Build-Prüfsumme für jede Abhängigkeit der Konfigurationsdatei.
Bei einem weiteren Aspekt der vorliegenden Erfindung beinhaltet das computerlesbare Medium des Systems zusätzliche, darauf gespeicherte Anweisungen, die bei der Ausführung durch den bzw. die Prozessor(en) dazu führen, dass von dem bzw. den Prozessor(en) die folgenden zusätzlichen Operationen ausgeführt werden: die Berechnung eines transitiven Abschlusses auf der Basis der Abhängigkeiten der Konfigurationsdateien.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein System enthalten, bei dem für jede Konfigurationsdatei des berechneten transitiven Abschlusses eine lokale Build-Prüfsumme berechnet wird.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein System enthalten, bei dem die Prüfsumme mithilfe einer XOR-Funktion berechnet wird.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein System enthalten, bei dem die Berechnung der ersten Prüfsumme zusätzlich die Durchführung einer deterministischen Sortierung beinhaltet; Berechnen einer lokalen Build-Prüfsumme mit der deterministischen Sortierung; und Berechnen der ersten Prüfsumme anhand der lokalen Build-Prüfsumme, wobei die erste Prüfsumme die Prüfsumme eines globalen Builds ist.
Bei einem weiteren Aspekt der vorliegenden Erfindung kann die Erfindung ein mit einem oder mehreren Prozessoren gekoppeltes computerlesbare Medium enthalten, auf dem Anweisungen gespeichert sind, die bei der Ausführung durch den bzw. die Prozessor(en) dazu führen, dass von dem bzw. den Prozessor(en) die folgenden Operationen ausgeführt werden: Erstellen einer ersten Kompilierungsstrategie für ein erstes Build; Erbringen des ersten Builds mithilfe der erste Kompilierungsstrategie; Berechnen einer erste Prüfsumme für das erste Build; Speichern der ersten Kompilierungsstrategie und der ersten Prüfsumme; Berechnen einer zweiten Prüfsumme für das zweite Build; Ermitteln, ob die zweite Prüfsumme mit der ersten Prüfsumme identisch ist; bei Feststellung, dass die zweite Prüfsumme nicht mit der ersten Prüfsumme identisch ist: Erstellen einer zweiten Kompilierungsstrategie; Speichern der zweiten Kompilierungsstrategie und der zweiten Prüfsumme und Erbringen des zweiten Builds mithilfe der zweiten Kompilierungsstrategie; und bei Feststellung, dass die zweite Prüfsumme mit der ersten Prüfsumme identisch ist: Abrufen der ersten Kompilierungsstrategie und Erbringen des zweiten Builds mithilfe der ersten Kompilierungsstrategie.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein computerlesbares Medium, enthalten, bei dem die erste Prüfsumme die Prüfsumme eines globalen Builds ist; und die Prüfsumme des globalen Builds wird anhand einer oder mehrerer lokaler Build-Prüfsummen berechnet.
Bei einem weiteren Aspekt der vorliegenden Erfindung beinhaltet das computerlesbare Medium zusätzliche, darauf gespeicherte Anweisungen, die bei der Ausführung durch den bzw. die Prozessor(en) dazu führen, dass von dem bzw. den Prozessor(en) die folgenden zusätzlichen Operationen ausgeführt werden: die Ermittlung, ob sich eine für das erste Build berechnete lokale Build-Prüfsumme für das zweite Build nicht geändert hat, und Wiederverwendung von Teilen der ersten, mit der lokalen Build Prüfsumme verknüpften Kompiliemngsstrategie bei der zweiten Kompilierungsstrategie.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein computerlesbares Medium enthalten, bei dem die Informationen des Dateisystems nach Pfadnamen sortiert werden, um die lokalen Build-Prüfsummen zu berechnen.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein computerlesbares Medium enthalten, bei dem die Dateisysteminformationen eine Prüfsumme enthalten.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein computerlesbares Medium enthalten, das Folgendes umfasst: Erbringen des ersten Builds mithilfe der erste Kompilierungsstrategie und darüber hinaus die Untersuchung des Inhalts einer Konfigurationsdatei, um die Abhängigkeiten zu ermitteln; und das Berechnen einer lokalen Build-Prüfsumme für jede Abhängigkeit der Konfigurationsdatei.
Bei einem weiteren Aspekt der vorliegenden Erfindung beinhaltet das computerlesbare Medium zusätzliche, darauf gespeicherte Anweisungen, die bei der Ausführung durch den bzw. die Prozessor(en) dazu führen, dass von dem bzw. den Prozessor(en) die folgenden zusätzlichen Operationen ausgeführt werden: die Berechnung eines transitiven Abschlusses auf der Basis der Abhängigkeiten der Konfigurationsdateien.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein computerlesbares Medium enthalten, bei dem für jede Konfigurationsdatei des berechneten transitiven Abschlusses eine lokale Build-Prüfsumme berechnet wird.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein computerlesbares Medium enthalten, bei dem die Prüfsumme mithilfe einer XOR-Funktion berechnet wird.
Bei einem weiteren Aspekt der vorliegenden Erfindung ist ein computerlesbares Medium enthalten, bei dem die Berechnung der ersten Prüfsumme zusätzlich die Durchführung einer deterministischen Sortierung beinhaltet; Berechnen einer lokalen Build-Prüfsumme mit der deterministischen Sortierung; und Berechnen der ersten Prüfsumme anhand der lokalen Build-Prüfsumme, wobei die erste Prüfsumme die Prüfsumme eines globalen Builds ist.
Der weitere Anwendbarkeitsbereich der beschrieben Verfahren, Vorrichtungen und computerlesbaren Speichermedien wird aus der nachfolgenden detaillierten Beschreibung ersichtlich. Es sollte jedoch verstanden werden, dass die detaillierte Beschreibung und spezifische Beispiele bei der Angabe von Ausführungsformen nur zur Veranschaulichung gegeben sind, da verschiedene Änderungen und Modifikationen im Sinn und Umfang der hier offengelegten Konzepte denen offensichtlich werden, die auf dem Gebiet aus dieser detaillierten Beschreibung qualifiziert sind.
Kurzbeschreibung der Zeichnungen:
Die beschriebenen Systeme und Verfahren lassen sich vollständiger verstehen anhand der detaillierten Beschreibung, die hierin weiter unten gegeben ist, und den begleitenden Zeichnungen, die nur zur Veranschaulichung gegeben sind und somit nicht einschränkend sind, und wobei Folgendes gilt:
Die Zeichnungen werden im Detail im Verlauf der detaillierten Beschreibung beschrieben.
1 ist ein Blockdiagramm, das exemplarische Abhängigkeiten der Konfigurationsdateien gemäß einer Ausführungsform veranschaulicht.
2 ist ein Ablaufdiagramm, das die Schritte für die Erstellung einer Kompilierungsstrategie gemäß einer Ausführungsform veranschaulicht
3 ist ein Ablaufdiagramm, das die Schritte für die Bestimmung, ob eine zuvor berechnete Kompilierungsstrategie wiederverwendet werden kann, gemäß einer Ausführungsform veranschaulicht.
4 ist ein Ablaufdiagramm, das die Schritte für die Berechnung einer lokalen Build-Prüfsumme gemäß einer Ausführungsform veranschaulicht.
5 ist ein Ablaufdiagramm, das die Schritte für die Kompilierung einer globalen Build-Prüfsumme gemäß einer Ausführungsform veranschaulicht.
6 veranschaulicht ein file_info-Array, gemäß einer Ausführungsform.
7 ist ein Blockdiagramm, das eine exemplarische Ausführungsform eines Build-Servers veranschaulicht.
Detailbeschreibung:
Die folgende detaillierte Beschreibung bezieht sich auf die begleitenden Zeichnungen. Die gleichen Bezugsziffern in verschiedenen Zeichnungen können die gleichen oder ähnliche Elemente identifizieren. Auch beschränkt sich die folgende detaillierte Beschreibung nicht auf die erläuterten Konzepte. Stattdessen wird der Umfang der hierin diskutierten Konzepte durch die beigefügten Ansprüche und Äquivalente davon definiert.
ÜBERBLICK
Wenn Benutzer (z. B. Computerprogrammierer) ausführbaren Code aus dem Programmcode erstellen möchten, initiieren sie den Build-Prozess auf einem Build-Server-Computersystem, das einen Plan (d. h. die Kompilierungsstrategie) für die Kompilierung des Programmiercodes erstellt. Das Build-Server-Computersystem kann ein beliebiges Computersystem sein, das den Build-Prozess durchführen kann. Während des Build-Prozesses können die Build-Module die Konfigurationsdateien bearbeiten, um eine Kompilierungsstrategie zu bestimmen. Die anfangs verarbeiteten Konfigurationsdateien können auf andere Konfigurationsdateien verweisen. Bei einigen Ausführungsformen werden referenzierten zu Konfigurationsdateien vor der verweisenden Konfigurationsdatei verarbeitet. Einige der Konfigurationsdateien werden in serieller Reihenfolge verarbeitet, und andere können parallel verarbeitet werden. Der Build-Server nutzt den Inhalt der Konfigurationsdateien, um die Kompilierungsstrategie zu bestimmen. In einigen Fällen ändert sich die Kompilierungsstrategie nicht gegenüber einer vorherigen Berechnungsstrategie. Zum Beispiel: In einigen Fällen haben sich möglicherweise die Abhängigkeiten in der Konfigurationsdatei nicht verändert, und somit ändert sich die Kompilierungsstrategie nicht. Um Zeit und Rechnerressourcen zu sparen, sollte die Kompilierungsstrategie möglichst wiederverwendet werden.
Um zu ermitteln, ob eine Kompilierungsstrategie wiederverwendet werden kann, führen wir den Begriff der ”globalen Build-Prüfsummen” ein. Intuitiv ist dies ein Wert, der den Zustand des Build-Eingabe und der Abhängigkeiten erfasst. Wenn sich dieser Wert nicht ändert, ist es sicher, die vorherige Kompilierungsstrategie wiederzuverwenden. Wenn sich dieser Wert ändert, ist es nicht sicher, die vorherige Kompilierungsstrategie wiederzuverwenden. Durch den Vergleich einer für ein aktuelles globales Build berechneten globalen Build-Prüfsumme mit der vorherigen globalen Build-Prüfsumme für ein früheres globales Build kann der Build-Server bestimmen, dass die Wiederverwendung der Kompilierungsstrategie möglich ist.
Eine ”Prüfsumme” ist ein Wert, der mithilfe eines Algorithmus für beliebige Daten berechnet wird. Der Wert der Prüfsumme ändert sich für eine nachfolgende Berechnung, wenn sich die Daten ändern. Solche Daten könnten zum Beispiel die Daten sein, die eine Konfigurationsdatei repräsentieren. Bei einigen Ausführungsformen ist der zur Berechnung der Prüfsumme verwendete Algorithmus der MD5-Algorithmus. Ausführungsformen der Erfindung sind nicht auf die Nutzung des MD5-Algorithmus beschränkt. Andere Algorithmen können ebenfalls zum Berechnen der Prüfsumme verwendet werden. Wenn die Prüfsummen von zwei Konfigurationsdateien unterschiedlich sind, dann sind die Inhalte der beiden Konfigurationsdateien unterschiedlich. Da weiterhin eine Prüfsumme für beliebige Daten berechnet werden kann, kann eine Prüfsumme auch für eine Sammlung von Konfigurationsdatei-Prüfsummen berechnet werden.
Bei einer Ausführungsform der vorliegenden Erfindung wird eine globale Build-Prüfsumme für einen Satz lokaler Build-Prüfsummen ermittelt. Wenn sich die globale Build-Prüfsumme für ein späteres Build von der globalen Build-Prüfsumme für ein früheres Build unterscheidet, dann muss die Kompilierungsstrategie des späteren Build sich möglicherweise von der Kompilierungsstrategie des früheren Build unterschieden. Da die globale Build-Prüfsumme Prüfsummen der lokalen Builds enthält, spiegelt die globale Build Prüfsumme alle Änderungen wider, die im lokalen Build vorkommen. Somit ist es möglich, Änderungen bei den Abhängigkeiten der lokalen Builds anhand der lokalen Build-Prüfsumme zu erkennen, und es ist auch möglich, die Änderungen mithilfe der globalen Build-Prüfsumme zu erkennen. Zum Beispiel: Wenn bei einer Ausführungsform eine Datei gelöscht und ein Verzeichnis mit dem gleichen Namen wie die Datei erstellt wird, dann muss die Kompilierungsstrategie (auch als Build-Strategie bezeichnet) neu berechnet werden. Bei einer solchen Ausführungsform muss sich die lokale Build-Prüfsumme bei der Berechnung wegen der Änderung von Datei zu Verzeichnis unterschiedlich sein.
Bei einigen Ausführungsformen können Teile einer für ein früheres Build berechneten Kompilierungsstrategie bei einer Kompilierungsstrategie für ein späteres Build wiederverwendet werden, auch wenn die das frühere Build und das spätere Build verschiedenen globalen Build-Prüfsummen haben. Die Prüfsummen (z. B. lokale Build Prüfsummen) können untersucht werden, um zu ermitteln, welche Teile des früheren Builds wiederverwendet werden können. Die Teile des ersten Build und die Teile des zweiten Build, der dieselbe erste lokale Build-Prüfsumme und dieselbe zweite lokale Build-Prüfsumme aufweisen, können wiederverwendet werden. Somit können Teile der ersten Kompilierungsstrategie wiederverwendet werden, auch wenn sich die erste globale Prüfsumme und zweite globale Prüfsumme unterscheiden.
Bei einer Ausführungsform wird der Satz der lokalen Build-Prüfsummen, die für die Berechnung der globalen Build-Prüfsumme verwendet werden können, auf der Grundlage der Konfigurationsdateien {b_1, ... b_n} im ”transitiven Abschluss der Konfigurationsdateien berechnet. Ein ”Satz” ist eine Sammlung von Dingen. Die hierin verwendete Notation b_1 kann verstanden werden als das erste b (”b_1”), das zweite b (”b_2”), das n-te b (”b_n”) usw. Formell ist der transitive Abschluss eines gelenkten Graph G = (V, E), wobei V der Satz der Vertikalen und E der Satz der Kanten ist, ein Graph G+ = (V, E+), sodass es für alle v, w in V eine Kante (v, w) in E gibt, wenn, und nur wenn in G ein Nicht-Null-Pfad von v nach w vorhanden ist. Der transitive Abschluss enthält jede Ecke und Kante, die von einem Knoten in einem gerichteten Graphen erreichbar ist.
Der transitive Aspekt der Terminologie ”transitiver Abschluss” bedeutet im Grunde ein Knotenpaar X und Y, wenn eine gerichtete Kante von X nach Y im Graph G vorhanden ist, und wenn ein Knotenpaar Y und Z vorhanden ist, und wenn eine gerichtete Kante von Y nach Z im Graph G vorhanden ist, ist auch eine gerichtete Kante von X nach Z im Graph G+ vorhanden.
Der ”Abschuss”-Aspekt wird am besten durch die Beschreibung der Sammlung von Eckpunkten verstanden. Wir beginnen mit einem Satz bestehend aus dem einzelnen Eckpunkt R, dann sammeln wir alle Kanten (X, Y) aus dem Graphen, die X = R erfüllen, wodurch wir zusätzliche Eckpunkte (die Ys des Paars (X, Y)) erhalten, die wir auch zum ursprünglichen Satz hinzufügen. Das wiederholen wir für alle Elemente des Satzes, bis keine weiteren hinzuzufügenden Kanten mehr im Graphen vorhanden sind; an dem Punkt haben wir den Abschluss erreicht. Wir haben im Grunde jeden Eckpunkt im Graphen verbunden, der vom ursprünglichen Kantenpunkt R entlang der vorhandenen Kanten im Graphen erreicht werden kann.
Zum Beispiel ist hier ein Satz von Flügen zwischen Städten in den USA: {(Seattle, Chicago), (Chicago, New York)). Hier ist ein exemplarischer transitiver Abschluss für die gleichen Städte: {(Seattle, Chicago), (Chicago, New York), (Seattle, New York)). (Seattle, New York) ist ein Teil des Satzes des transitiven Abschlusses, weil (Seattle, Chicago) und (Chicago, New York) im ursprünglichen Satz vorhanden sind. In Bezug auf Konfigurationsdateien, wenn Build-A abhängig ist von Build-B, d. h. (A, B). und Build B abhängig ist von Build-C: d. h. (B, C), dann ist (A, C) ebenfalls Teil des transitiven Abschlusses.
Mit dem transitiven Abschluss von Konfigurationsdateien kann das Build-Modul bestimmen, ob Änderungen an Abhängigkeiten zwischen Konfigurationsdateien vorgenommen wurden. Build-Modul 114 kann bestimmen, ob Änderungen der Eingänge für die Konfigurationsdateien vorgenommen wurden oder ob Abhängigkeiten geändert wurden, sodass die Kompilierungsstrategie neu berechnet werden muss gemäß einer Ausführungsform der Erfindung.
Weil das Build-Modul feststellen kann, ob es irgendwelche Änderungen an den Konfigurationsdateien vorgenommen wurden, einschließlich der Abhängigkeiten zwischen den Konfigurationsdateien, kann das Build-Modul den Schritt zur Erstellung der Kompilierungsstrategie überspringen, wenn keine Änderungen vorhanden sind, die die Gültigkeit der Kompilierungsstrategie beeinflussen würden. Software-Ingenieure müssen nicht mehr länger auf die Neuberechnung der Kompilierungsstrategie warten, wenn die Kompilierungsstrategie nicht geändert werden muss. Build-Strategien können von verschiedenen Programmierern wiederverwendet werden. Die Wiederverwendung einer zuvor erstellten Kompilierungsstrategie spart viel Rechenzeit und Kosten, vor allem in einem großen Unternehmen, wo regelmäßig große Builds durchgeführt werden.
1 ist ein Blockdiagramm, das exemplarische Abhängigkeiten der Konfigurationsdateien gemäß einer Ausführungsform veranschaulicht. Wie in 1, eine Konfigurationsdatei (CF) 102 verweist auf und ist abhängig von CF 104 und 106. CF 106 ist abhängig von CF 108. In einer Ausführungsform wird CF 108 vor CF 106 verarbeitet. CF 104, 106 und 108 können vor CF 102 verarbeitet werden. Konfigurationsdateien deklarieren die Abhängigkeiten der Softwaremodule. Jede der Konfigurationsdateien kann von einen Build-Modul (BM) verarbeitet werden. Diejenigen Konfigurationsdateien, die auf andere Konfigurationsdateien verweisen, und die abhängig sind von den anderen Konfigurationsdateien, kann das Build-Modul auch die anderen Konfigurationsdateien laden.
Das Build-Modul kann ein Server sein, der Software zur Ausführung des Build-Prozesses ausführt. Wie in 1, CF 102 kann von einem BM 114 verarbeitet werden. CF 104 kann von einem BM 116 verarbeitet werden. CF 106 und CF 108 können von einem BM 120 verarbeitet werden. Bei einigen Ausführungsformen können eins oder mehrere der separaten Build-Module als ein einzelnes Build-Modul implementiert werden. Bei einigen Ausführungsformen können alle Build-Module als ein einzelnes Build-Modul implementiert werden. Zum Beispiel: BM 114 BM kann auch ein einzelnes Build-Modul sein, das den Build-Prozess für alle Konfigurationsdateien durchführt. Zur Vereinfachung der Beschreibung: Das eine oder mehrere Build-Module, die die hierin beschriebenen Aktionen ausführen, werden als von BM 114 durchgeführt beschreiben, aber bei unterschiedlichen Ausführungsformen eine kann jede beliebige Anzahl oder Kombination von Build-Modulen, wie z. B. BM 114 in Verbindung mit BM 116 und BM 120, die hierin beschriebenen Prozesse auszuführen.
ERSTELLEN EINER KOMPILIERUNGSSTRATEGIE
2ist ein Ablaufdiagramm, das die Schritte für die Erstellung einer Kompilierungsstrategie gemäß einer Ausführungsform veranschaulicht.
In Schritt 202 lädt Build-Modul 114 die Konfigurationsdateien für die Kompilierungsziele. Build-Modul 114 lädt einen ersten Satz von Konfigurationsdateien. Diese Konfigurationsdateien sind Top-Level-Konfigurationsdateien und einige der Konfigurationsdateien können von anderen Konfigurationsdateien abhängig sein. Zum Beispiel kann Build-Modul 114 die Konfigurationsdatei CF 102 laden aus 1.
In Schritt 204 lädt Build-Modul 114 die Konfigurationsdateien für alle verwiesenen Ziele. Build-Modul 114 lädt auch andere Konfigurationsdateien, auf die von dem anfangs geladenen Satz von Konfigurationsdateien verwiesen wird. Build-Modul 114 untersucht den Inhalt des ursprünglich geladenen Satzes von Konfigurationsdateien, um die anderen zu ladenden Konfigurationsdateien zu ermitteln. Zum Beispiel: Build-Modul 114 (oder Build-Modul 120 in einigen Ausführungsformen) kann CF 104 und CF 106 laden, weil auf diese Konfigurationsdateien von CF 102 verwiesen wird.
In Schritt 206 wiederholt Build-Modul 114 das Laden der Konfigurationsdateien, bis der transitive Abschluss oder die für die Kompilierungsziele geladen sind. Zum Beispiel: Build-Modul 114 (oder Build-Modul 120 in einigen Ausführungsformen) kann CF 108 basierend auf einem Abhängigkeitslink von CF 106 laden. In einigen Ausführungsformen der transitiven Abschluss zu laden, wenn eine Konfigurationsdatei A auf eine Konfigurationsdatei B verweist und die Konfigurationsdatei B auch auf eine Konfigurationsdatei C verweist, die Konfigurationsdatei C basierend auf einer Verbindung zwischen Konfigurationsdatei A und Konfigurationsdatei C im transitiven Abschluss geladen. Konfigurationsdatei C wird auch basierend auf einer Verbindung zwischen Konfigurationsdatei A und Konfigurationsdatei B geladen. Build-Modul 114 lädt die Konfigurationsdateien, bis alle Konfigurationsdateien geladen sind, auf die von anderen Konfigurationsdateien verwiesen wird. Auf diese Weise bleiben beim Ladevorgang keine Abhängigkeiten unberücksichtigt. Der transitive Abschluss kann mithilfe eines beliebigen konventionellen Algorithmus berechnet werden. Der transitive Abschluss kann basierend auf Abhängigkeiten der Konfigurationsdateien berechnet werden. Die Abhängigkeiten können durch Untersuchung der Konfigurationsdateien ermittelt werden. Sobald alle Konfigurationsdateien geladen wurden, und wenn alle Abhängigkeiten ebenfalls untersucht worden sind, dann wird das Laden des transitiven Abschlusses der Kompilierungsziele abgeschlossen.
In Schritt 208 berechnet Build-Modul 114 die Kompilierungsstrategie. Die Kompilierungsstrategie ist ein Plan für die Schritte der Kompilierung des Quellcodes, die Verknüpfung von Objektdateien und anderen Schritten, die zum Abschluss der Kompilierung erforderlich sind. Einige der Schritte, wie z. B. das Kompilieren von bestimmtem Quellcode, können parallel ausgeführt werden. In einigen Fällen, wenn zwei Softwaremodule voneinander unabhängig sind, können die beiden Softwaremodule unabhängig voneinander kompiliert werden. Andere Schritte können nur sequenziell ausgeführt werden. Bei einigen Ausführungsformen, wenn die Kompilierung eines Softwaremodul aufs dem Abschluss der Kompilierung eines anderen Softwaremoduls aufbaut, können die Kompilierungsschritte nur sequenziell durchgeführt werden. Die Kompilierungsstrategie kann angeben, welche Ein- und Ausgabedateien in jeder Phase vorhanden sein müssen. Die Kompilierungsstrategie kann angeben, welche Phasen der Kompilierung parallel durchgeführt werden können, und welche Phasen der Kompilierung nacheinander durchgeführt werden müssen. Die Kompilierungsstrategie kann auch Quellcode-Kompilierung. Verknüpfung und andere auszuführende Schritte angeben. Die Kompilierungsstrategie kann auch auszuführende Arbeiten und in einer Cloud von Build-Maschinen auszuführende Aktionen geographisch planen.
BESTIMMUNG, OB EINE ZUVOR BERECHNETE KOMPILIERUNGSSTRATEGIE WIEDERVERWENDET WERDEN KANN
3 ist ein Ablaufdiagramm, das die Schritte für die Bestimmung, ob eine zuvor berechnete Kompilierungsstrategie wiederverwendet werden kann, gemäß einer Ausführungsform veranschaulicht.
In Schritt 302 lädt Build-Modul 114 Konfigurationsdateien für Kompilierungsziele. Dieser Schritt entspricht Schritt 202 aus 2. Build-Modul 114 lädt einen ersten Satz von Konfigurationsdateien. Diese Konfigurationsdateien sind Top-Level-Konfigurationsdateien und einige der Konfigurationsdateien können von anderen Konfigurationsdateien abhängig sein. Zum Beispiel kann Build-Modul 114 die BF 102 laden.
In Schritt 304 lädt Build-Modul 114 die Konfigurationsdateien für alle referenzierten Ziele. Dieser Schritt entspricht Schritt 204 aus 2. Build-Modul 114 lädt auch andere Konfigurationsdateien, auf die von dem anfangs geladenen Satz von Konfigurationsdateien verwiesen wird. Build-Modul 114 untersucht den Inhalt des ursprünglich geladenen Satzes von Konfigurationsdateien, um die anderen zu ladenden Konfigurationsdateien zu ermitteln. Zum Beispiel: Build-Modul 114 kann CF 104 und CF 106 laden, weil auf diese Konfigurationsdateien von CF 102 verwiesen wird.
In Schritt 306 wiederholt Build-Modul 114 das Laden der Konfigurationsdateien, bis der transitive Abschluss oder die für die Kompilierungsziele geladen sind. Dieser Schritt entspricht Schritt 206 aus 2. Build-Modul 114 lädt die Konfigurationsdateien, bis alle Konfigurationsdateien geladen sind, auf die von anderen Konfigurationsdateien verwiesen wird. Zum Beispiel kann Build-Modul 114 die CF 108 laden.
In Schritt 308 berechnet Build-Modul 114 für jede Konfigurationsdatei im transitiven Abschluss die lokale Build-Prüfsumme. Um Schritt 308 auszuführen, führt Build-Modul 114 Schritte aus. wie beschrieben in 4. Build-Modul 114 berechnet die lokalen Build-Prüfsummen, die bei der Berechnung der globalen Build-Prüfsumme verwendet werden.
In Schritt 310 berechnet Build-Modul 114 die globale Build-Prüfsumme unter Verwendung der lokalen Build Prüfsummen. Um Schritt 310 auszuführen, führt Build-Modul 114 Schritte aus. wie in 5. In 5 beschrieben, Build-Modul 114 sortiert die lokalen Build Prüfsummen und berechnet die globale Build-Prüfsumme unter Verwendung der sortierten lokalen Build Prüfsummen. Die globale Build-Prüfsumme wird mit einer vorherigen globalen Build-Prüfsumme verglichen, um zu bestimmen, ob eine neue Kompilierungsstrategie erforderlich ist. Wenn sich die globale Build-Prüfsumme geändert hat, dann muss eine neue Kompilierungsstrategie berechnet werden.
BERECHNEN EINER LOKALEN BUILD-PRÜFSUMME
4 ist ein Ablaufdiagramm, das die Schritte für die Berechnung einer lokalen Build-Prüfsumme gemäß einer Ausführungsform veranschaulicht. Die lokalen Build Prüfsummen können für alle Konfigurationsdateien im transitiven Abschluss berechnet werden, um die globale Build-Prüfsumme zu berechnen.
In Schritt 402 ermittelt Build-Modul 114 eine Liste der in der Konfigurationsdatei deklarierten Eingaben. Eine Konfigurationsdatei kann auf andere Konfigurationsdateien oder Verzeichnisse verweisen. Die referenzierten Konfigurationsdateien oder Verzeichnisse, die in einer Konfigurationsdatei deklariert sind, können als {in_1, in_m}, für m Referenzen dargestellt werden. Für das Beispiel von CF 102 kann in_1 beispielsweise /dir3 file2 sein, in_2 kann /dir1/file1 und IN_3 kann /dir2 sein. Bei einigen Ausführungsformen In kann Build-Modul 114 eine Liste der referenzierten Konfigurationsdateien oder Verzeichnisse durch Untersuchung des Inhalts der Konfigurationsdatei ermitteln. Bei einigen Ausführungsformen kann Build-Modul 114 während des Build-Prozesses Build-Dateien untersuchen, um zu ermitteln, auf welche Dateien zugegriffen wird, um die Liste der referenzierten Dateien oder Verzeichnisse zu bestimmen.
In Schritt 404 ermittelt Build-Modul 114 eine Liste der Dateisysteminformationen für die Konfigurationsdatei. Bei einer Ausführiungsform wird die Liste der Dateisysteminformationen in einem file_info-Array gespeichert. Zum Beispiel verweist file_info(1) auf den ersten Slot des file_info-Arrays und kann /dir3/file2 speichern, file_info(2) kann /dir1/file1 speichern, und file_info(3) kann /dir2 speichern. Bei einigen Ausführungsformen enthält jeder Slot Inhalt einer Typstruktur. Die Typstruktur kann zum Beispiel eine Zeichenfolge sein, die den Pfadnamen darstellt. Die Typstruktur kann auch eine Ganzzahl- oder Boolean-Typ oder ein anderer Typ sein, der angibt, ob der Dateiinformationssystem-Slot Daten für eine Datei oder ein Verzeichnis speichert. Bei einigen Ausführungsformen können die file_info()-Slots alle Informationen für die Dateien speichern, die die Neuberechnung von Build-Schritten auslösen können.
Bei einer Ausführungsform weist ein file_info-Array m Slots auf, wie gezeigt in 6. Auf die Slots in file_info kann jeweils als file_info(1), file_info(2), file_info(3), ... file_info(k), ... file_info (m) verwiesen werden. k repräsentiert einen Slot in der Mitte des Arrays. Build-Modul 114 kann den Inhalt der Konfigurationsdatei prüfen, um das file_info-Array zu füllen.
Jeder der Slots von file_info kann Informationen über eine Eingabe der Konfigurationsdatei speichern. Die gespeicherten Informationen können Dateisysteminformationen sein, die einen Pfad und Daten enthalten, die angeben, ob die Eingabe ein Verzeichnis oder eine Datei ist. Für jede Eingabe in_k kann Build-Modul 114 einem file_info-Array die folgenden Informationen an der Array-Position für in_k zuweisen 1) einen Pfad zu einer Datei und 2) Daten, die angeben, ob die Eingabe eine Datei oder ein Verzeichnis ist. Zum Beispiel: Bei einer Art von Computersystem kann ein Pfad ”C:\root\builds\configuration file 102.cf” sein, der zu file_info(1) zugewiesen werden kann. Ein weiteres Beispiel: Bei einer anderen Art von Computersystems kann ein Pfad ”/root/u/joe123/configuration file 102.cf” sein. Andere Variationen von Pfadformaten existieren, und Ausführungsformen der Erfindung sind nicht auf bestimmte Formate der Pfade beschränkt.
Bei einer Ausführungsform können die Daten, die angeben, ob die Eingabe eine Datei oder ein Verzeichnis ist, in einer Variablen gespeichert werden. Eine solche Variable kann eine boolesche Variable, eine ganzzahlige Variable oder ein beliebiger anderer Variablentyp sein. Beispielsweise kann file_info(1) kann einen Wert haben, der eine Datei angibt.
Wenn der Pfad ein Verzeichnis ist, d. h. ”C:\root\builds\build 102” oder ”/root/builds/build 102”, kann file_info(1) auch einen Wert speichern, der ein Verzeichnis angibt. Zum Beispiel: file_info(1) kann 7dir3/file2” speichern, was ein Pfad zu einer Datei ist, und kann auch Daten speichern, die angeben, dass file_info(1) eine Datei speichert.
In Schritt 406 sortiert Build-Modul 114 optional die Liste der Dateisysteminformationen. Bei einer Ausführungsform sortiert Build-Modul 114 Folgendes zusammen für eine Konfigurationsdatei c_i:

1) file_info(in_k) für alle Eingaben {in_1, in_m}. Mit anderen Worten: Die Slots von file_info speichern in jedem Slot Daten bezüglich einer Eingabe der Konfigurationsdatei c_i
2) checksum(c_i). Mit anderen Worten: Der Prüfsummenwert für die Konfigurationsdatei c_i und
3) file_info(c_i). Mit anderen Worten: die file_info der Konfigurationsdatei c_i, die den Pfad der Konfigurationsdatei c_i und Daten, die enthalten kann, die angeben, dass die Konfigurationsdatei c_i eine Datei ist. Bei einigen Ausführungsformen kann die Sortierung mithilfe eines beliebigen Algorithmus durchgeführt werden, der eine kanonische Reihenfolge erzeugt. Eine kanonische Reihenfolge kann auch durch Techniken der deterministischen Sortierung erzielt werden. Die Sortierung ist deterministisch, wenn die Sortierung dieselben Ergebnisse aus denselben Eingaben zurückgibt, auch wenn sich die Reihenfolge der Eingaben ändert. Beispielsweise bei folgenden Werten für den file_info-Slot: file_info(1): ”/root/u/joe123/configuration file HO.cf” file_info(2): ”/root/u/joe123/configuration file 144.cf” file_info(3): ”/root/u/joe123/configuration file 122.cf” file_info(4): ”/root/u/joe123/configuration file 111.cf” file_info-Daten der lokalen Konfigurationsdatei: ”/root/u/joe123/configuration file 34.cf” Prüfsumme von c_i lokale Konfigurationsdatei checksum(c_i): 234233

Nach Durchführung der Sortierung kann das Ergebnis der Sortierung bei dem Beispiel wie folgt sein: {234233, ”/root/u/joe123/configuration file 34.cf”, ”/root/u/joe123/configuration file HO.cf”, 7root/u/joe123/configuration file 111.cf”, ”/root/u/joe123/configuration file 122.cf”, 7root/u/joe123/configuration file 144.cf”}
In Schritt 408 berechnet Build-Modul 114 die Prüfsumme über die sortierte Liste der Dateisysteminformationen. Die sortierten Daten für die Berechnung der lokale Build-Prüfsumme enthält das file_info-Array mit sortierten Werten, die file_info der Konfigurationsdatei c_i und die Prüfsumme über den Inhalt der Konfigurationsdatei. Build-Modul 114 kann das Ergebnis der sortierten Daten als Eingabe in einen Algorithmus verwenden, der eine Prüfsumme berechnet. Bei einigen Ausführungsformen nutzt Build-Modul 114 einen MD5-Algorithmus zur Berechnung der Prüfsumme. Zum Beispiel: Die Eingabe für die Berechnung der lokalen Build-Prüfsumme kann /dir1/file1, /dir2, /dir3/file2, /package 1/configurationfile1 und eine Prüfsumme (in der Regel ein numerischer Wert) enthalten. Die Prüfsumme kann eine Zahl wie z. B. 2342342 sein, und die Prüfsumme ist anders, wenn die Eingabe in die Prüfsummenberechnung anders ist.
Bei einigen Ausführungsformen berechnet Build-Modul 114 eine von der Reihenfolge unabhängig Prüfsumme ohne Sortierung. Zum Beispiel kann Build-Modul 114 eine XOR-Funktion zur Berechnung der Prüfsumme nutzen. Bei solchen Ausführungsformen überprüft Build-Modul 114, ob keine doppelten Einträge in einer Liste vorhanden sind, die für die Berechnung der Prüfsummen verwendet wird.
BERECHNEN EINER GLOBALEN BUILD-PRÜFSUMME
5 ist ein Ablaufdiagramm, das die Schritte für die Kompilierung einer globalen Build-Prüfsumme gemäß einer Ausführungsform veranschaulicht. Build-Modul 114 kann die Schritte aus 5 ausführen, um zu ermitteln, ob eine vorherige Kompilierungsstrategie wiederverwendet werden kann. Wenn die vorherige Kompilierungsstrategie nicht wiederverwendet werden kann, dann muss eine neue Kompilierungsstrategie berechnet werden.
In Schritt 502 ruft Build-Modul 114 eine Liste der lokalen Build-Prüfsummen ab. Um die globale Build-Prüfsumme zu berechnen, ruft Build-Modul 114 lokale Build-Prüfsummen ab, die berechnet wurden. Die lokalen Build-Prüfsummen können aus einem Satz von Konfigurationsdateien {b_1, ..., b_n} im transitiven Abschluss stammen. Bei einer Ausführungsform kann jede lokale Build-Prüfsumme ein numerischer Wert sein, der für eine bestimmte Konfigurationsdatei berechnet wurde. Zum Beispiel können die für BF 104, BF 102 und BF 106 berechneten lokalen Build-Prüfsummen 980456, 234231 bzw. 343243 sein.
In Schritt 504 sortiert Build-Modul 114 die Liste der lokalen Build-Prüfsummen. Bei einigen Ausführungsformen sortiert Build-Modul 114 nach Paketnamen (auch Modulnamen oder Zielnamen genannt). Die Sortierung der lokalen Build-Prüfsummen nach Paketnamen kann zu eine Liste der lokalen Build Prüfsummen führen, die z. B. als 234231, 980456 und 343243 sortiert werden.
In Schritt 506 berechnet Build-Modul 114 die Prüfsumme über die sortierten Daten. Build-Modul 114 kann die sortierten lokalen Build Prüfsummen verarbeiten, um eine globale Prüfsumme zu berechnen. Wenn der Sortieralgorithmus deterministisch ist, ist die Eingabe für die Berechnung der globalen Prüfsummen dieselbe, solange sich die Konfigurationsdatei-Prüfsummen nicht ändern. Zum Beispiel: Bei Verwendung der sortierte Liste der lokalen Prüfsummen, sortiert als 234231, 343243 und 980456, kann eine berechnete globale Build-Prüfsumme 108934 sein.
Bei Schritt 508 speichert Build-Modul 114 die Prüfsumme als eine globale Prüfsumme. Build-Modul 114 kann die globale Prüfsumme speichern. Build-Modul 114 kann dann die globale Prüfsumme mit der vorherigen globalen Prüfsumme vergleichen, die berechnet wurde, um zu bestimmen, ob eine neue Kompilierungsstrategie erstellt werden muss. Wenn die globale Prüfsumme dieselbe wie die vorherige globale Prüfsumme ist, kann die Kompilierungsstrategie wiederverwendet werden. Wenn die globale Prüfsumme sich von der vorherigen globalen Prüfsumme unterscheidet, wird die Kompilierungsstrategie neu berechnet. Zum Beispiel: Wenn die vorherige globale Build-Prüfsumme 546675 und die aktuell berechnete globale Build-Prüfsumme 108934 ist, dann muss der Kompilierungsplan neu berechnet werden, weil die veränderte Prüfsumme anzeigt, dass der vorherige Kompilierungsplan nicht mehr gültig sein kann, z. B. weil sich einige Abhängigkeiten geändert haben oder die Art der Eingaben sich geändert hat.
FILE INFO-ARRAY
6 veranschaulicht ein file_info-Array, gemäß einer Ausführungsform. Wie in 6, file_info 600 hat m-Slots. Jeder der Slots kann als file_info(k) referenziert werden, wobei ”k” sich auf den k-ten Slot bezieht. Zum Beispiel verweist file_info(1) auf den ersten Slot des file_info-Arrays, file_info(2) bezieht sich auf den zweiten Slot des file_info-Arrays usw. File_info(m) bezieht sich auf den letzten Slot des file_info-Arrays.
DATEISYSTEMDIENST
In einigen Ausführungsformen kann die Berechnung der lokalen und globalen Build Prüfsummen Build Prüfsummen können als Dienst in einem Dateisystem hinzu. Dieses Dateisystem kann geringen Aufwand für die Berechnung und die Überwachung dieses Dienstes hinzufügen. In dieser Ausführungsform ist das Abrufen des Dateisystems für die globale Build-Prüfsumme eines Build-Ziels ist berechnungsmäßig kostengünstig und kann vor der Berechnung einer Kompilierungsstrategie durchgeführt werden.
Das Dateisystem kann die schritt ausführen aus 4 und 5. Das Dateisystem kann sich aller Änderungen bewusst sein, sobald Änderungen der auftreten, und kann alle Daten zu diesem Zeitpunkt neu berechnen. Zu einem späteren Zeitpunkt können dann die Daten aus dem Dateisystem abgefragt werden, statt sie neu zu berechnet. Ein Dateisystem kann Prüfsummen schneller und kostengünstiger berechnen als jede Anwendung, die im Userspace läuft. Ferner können Kompilierungsstrategien im Cache gespeichert und wiederverwendet werden, und die Kompilierung kann bei parallel arbeitenden Benutzern beschleunigt werden.
BEISPIEL FÜR AUSFÜHRUNGSFORMEN
7 ist ein Blockdiagramm, das eine exemplarische Ausführungsform eines Build-Servers veranschaulicht. Bei einer sehr einfachen Konfiguration 701, enthält Computergerät 700 typischerweise einen oder mehrere Prozessoren 710 und Systemspeicher 720. Ein Speicherbus 730 kann für die Kommunikation zwischen Prozessor 710 und Systemspeicher 720 verwendet werden.
Abhängig von der gewünschten Konfiguration kann der Prozessor 710 eines beliebigen Typs sein, einschließlich, aber nicht beschränkt auf, einen Mikroprozessor (uP), einen Mikrocontroller (uC), einen digitalen Signalprozessor (DSP) oder eine beliebige Kombination davon. Prozessor 710 kann eine weitere Ebenen der Zwischenspeicherung umfassen, beispielsweise einen Level-One-Cache 711 und einen Level Level-Two-Cache 712, einen Prozessorkern 713, und Register 714. Der Prozessorkern 713 kann eine arithmetische Logikeinheit (ALU) enthalten, eine Fließkommaeinheit (FPU), einen digitalen Signalverarbeitungskern (DSP Core) oder eine beliebige Kombination davon. Ein Speichercontroller 715 kann auch mit dem Prozessor 710 eingesetzt werden, oder bei einigen Implementierungen kann der Speichercontroller 715 ein interner Bestandteil des Prozessors 710 sein.
Abhängig von der gewünschten Konfiguration kann der Systemspeicher 720 eines beliebigen Typs sein, einschließlich, aber nicht beschränkt auf, flüchtigen Speicher (wie z. B: RAM), nicht flüchtigen Speicher (wie z. B. ROM, Flash-Speicher usw.) oder eine beliebige Kombination davon. Systemspeicher 720 enthält typischerweise ein Betriebssystem 721, eine oder mehrere Anwendungen 722 und Programmdaten 724. Anwendung 722 enthält einen Mehrzweck-Verarbeitungsalgorithmus für lokale zielgerichtete Werbung 723. Programmdaten 724 enthält Mehrzweck-Verarbeitungsdaten für lokale zielgerichtete Werbung 725, wie weiter unten beschrieben. Bei einigen Ausführungsformen kann Anwendung 722 so eingerichtet werden, dass sie mit Programmdaten 724 auf einem Betriebssystem 721 arbeitet. Dies wird konzeptionell in 7 von den Komponenten innerhalb der gestrichelte Linie 701.
Computergerät 700 kann zusätzliche Funktionen oder Funktionalität sowie zusätzliche Schnittstellen für die Kommunikation zwischen der Basiskonfiguration 701 und allen erforderlichen Geräten und Schnittstellen aufweisen. Beispielsweise kann ein Bus/Schnittstellenkontroller 740 für die Kommunikation zwischen der Grundkonfiguration 701 und einer oder mehrerer Datenspeichergeräte 750 über einen Speicherschnittstellenbus 741 verwendet werden. Die Datenspeichergeräte 750 können davon Wechselspeichergeräte 751, Nicht-Wechselspeichergeräte 752 oder eine Kombination davon sein. Beispiele für Wechselspeicher- und Nicht-Wechselspeichergeräte sind z Magnetplattengeräte, wie z. B. Floppy-Disk-Laufwerke und Festplattenlaufwerke (HDD), optische Plattenlaufwerke, wie beispielsweise Compact Disc CD)-Laufwerke oder Digital Versatile Disk(DVD)-Laufwerke, Solid State-Laufwerke (SSD) und Bandlaufwerke, um nur ein paar zu nennen. Beispielhafte Computerspeichermedien können flüchtige und nichtflüchtige, entfernbare und nicht entfernbare Medien enthalten, die in irgendeinem Verfahren oder einer Technologie zum Speichern von Informationen implementiert sind, wie zum Beispiel computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten.
Systemspeicher 720, Wechselspeicher 751 und Nicht-Wechselspeichergeräte 752 sind Beispiele für Computerspeichermedien. Computerspeichermedien enthalten, sind aber nicht beschränkt auf RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologie, CD-ROM, Digitalversatile-Disks (DVD) oder andere optische Speicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das verwendet werden kann, um die gewünschte Information zu speichern, und auf die durch die Rechenvorrichtung 700 zugegriffen werden kann. Jedes dieser Computer-Speichermedien kann ein Teil des Geräts 700 sein.
Computergerät 700 kann auch eine Schnittstellenbus 742 für die Kommunikation verschiedener Schnittstellengeräte (z. B. Ausgabe-Schnittstellen, Peripherieschnittstellen und Kommunikationsschnittstellen) mit der Basiskonfiguration 701 über den Bus/Schnittstellenkontroller 740 enthalten. Beispiel für Ausgabegeräte 760 sind eine Grafikverarbeitungseinheit 761 und eine Audioverarbeitungseinheit 762, die für die Kommunikation mit verschiedenen externen Geräten, wie beispielsweise einem Display oder Lautsprechern 763 über einen oder mehrere A/V-Ports konfiguriert werden können. Beispiele für Peripherieschnittstellen 770 sind ein Seriell-Schnittstellenkontroller 771 oder eine Parallel-Schnittstellenkontroller 772, die für die Kommunikation mit externen Geräten, wie beispielsweise Eingabegeräten (z. B. Tastatur, Maus, Stift, Spracheingabegerät, Touch-Eingabegerät usw.) oder anderen Peripheriegeräte (z. B. Drucker, Scanner usw.) über einen oder mehrere I/O-Ports 773 konfiguriert werden können. Ein Beispiel für Kommunikationsgerät 780 ist ein Netzwerkkontroller 781, der für die Kommunikation mit einem oder mehreren anderen Computergeräten 790 über eine Netzwerkkommunikation über einen oder mehrere Kommunikationsports 782 eingerichtet werden kann. Die Kommunikationsverbindung ist ein Beispiel für Kommunikationsmedien. Kommunikationsmedien können typisch sein für die Darstellung von Computer lesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten mit einem angepassten Datensignal wie einer Trägerschwingung oder anderen Transportmechanismus und schließt jede Information der gelieferten Medien mit ein. Ein 'angepasstes Datensignal' kann ein Signal sein, dass eine oder mehrere Charakteristika setzt oder wechselt, um Informationen in den Signalen zu entschlüsseln. Zum Beispiel, und nicht begrenzt, Kommunikationsmedien können kabelgebundene Medien miteinschließen wie kabelgebundene Netzwerke oder direkt verkabelte Verbindung und kabellose Medien wie Akustik, Radiofrequenzen (RF), Infrarot (IR) und andere kabellose Medien. Das Computerprogramm lesbarer Medien wie es hier benutzt wird, kann beides miteinschließen, Speichermedien und Kommunikationsmedien.
Computergerät 700 kann als Teil eines kleinformatigen tragbaren (oder mobilen) elektronischen Geräts, wie z. B. einem Mobiltelefon, einem persönlichen Datenassistenten (PDA), ein Personal-Media-Player-Gerät, ein drahtlose Web-Watch-Gerät, ein persönliches Headset-Gerät, ein anwendungsspezifisches Vorrichtung oder ein Hybridgerät sein, die eine der obigen Funktionen enthalten. Computergerät 700 kann auch als ein Personal Computer einschließlich Laptop- und Nicht-Laptop-Computer-Konfigurationen implementiert werden.
Es gibt nur wenig Unterschied zwischen Hardware- und Software-Implementierungen der Aspekte der Systeme; die Verwendung von Hardware oder Software ist in der Regel (aber nicht immer, da bei bestimmten Zusammenhängen die Wahl zwischen Hardware und Software kann bedeutsam werden kann) eine Designauswahl, die Kosten gegenüber Effizienz-Kompromissen darstellt. Es gibt dabei verschiedene Fahrzeuge, welche die Verfahren und Systeme und/oder andere Technologien beschreiben, die durchgeführt werden können (zum Beispiel Hardware, Software und/oder Firmware) und dass das bevorzugte Fahrzeug sich in dem Zusammenhang unterscheiden wird, in dem die Verfahren und/oder Systeme und/oder andere Technologien entwickelt werden. Zum Beispiel, wenn ein implementiertes bestimmt, dass die Geschwindigkeit und Genauigkeit entscheidend sind, der Überträger kann für eine Haupthardware und/oder Firmware-Fahrzeuge optieren; wenn er flexibel ist, kann er eine Hauptsoftware implementieren oder, wiederum, alternativ, der Überträger kann für eine Kombination optieren von Hardware, Software und/oder Firmware.
Die vorhergehende detaillierte Beschreibung hat verschiedene Ausführungsformen der Geräte und/oder Prozesse durch Blockdiagramme, Flussdiagramme und/oder Beispiele dargelegt. Insoweit, wie diese Blockdiagramme, Flowcharts und/oder Beispiele eine oder mehrere Funktionen und/oder Operationen beinhalten, werden sie von Fachleuten aus der Wissenschaft dahingehend verstanden, das jede Funktion und/oder Operation mit solchen Blockdiagrammen, Flowcharts oder Beispielen implementiert werden können, individuell und/oder kollektiv, durch ein weites Angebot von Hardware, Software, Firmware der irgendeiner virtuellen Kombination davon. In einer Ausführungsform können einige Teile des hier beschriebenen Gegenstands über anwendungsspezifische integrierte Schaltungen (ASICs), Field Programmable Gate Arrays (FPGAs), digitale Signalprozessoren (DSPs) oder andere integrierte Formate implementiert werden. Wie auch immer, diese in der Wissenschaft eingerichteten werden erkennen, dass einige Aspekte der Verkörperung eingeschlossen sind, im Ganzen oder in Teilen, können äquivalent implementiert im integrierten Kreislauf, als ein oder mehrere Computerprogramme laufen auf einem oder mehreren Computer (beispielsweise als ein oder mehrere Programme auf einem oder mehreren Computersystemen) wie auf einem oder mehreren Programmen laufen auf einem oder mehreren Prozessoren (beispielsweise als ein oder mehrere Programme laufen auf einem oder mehreren Mikroprozessoren) als Firmware oder virtuelle Kombinationen und dass die gestalteten Schaltkreise und/oder für die Software geschriebenen Codes und/oder Firmware würde gut mit den Fähigkeiten eines oder den Fähigkeiten in der Beleuchtungskunst zusammenpassen. In Ergänzung wird diese Kunst zu schätzen wissen, dass die Mechanismen der Subjekte, die hier beschrieben werden, hauptsächlich dazu dienen als ein Programm in verschiedenen Formen und dass ein illustrierter Inbegriff der Subjekte, die hier beschrieben werden, die einzelnen Arten von Signalen, die das Medium tragen, zur aktuellen Übertragung dienen. Beispiele von Signal übertragenden Medien eingeschlossen, aber nicht begrenzt, das Folgende: ein tragbarer Medientyp wie eine Floppydisk, eine Harddisk, eine Compactdisk (CD), eine Digitale Video Disk (DVD), ein digitales Band, ein Computer Memory usw.; und ein Übertragungsmedium wie digitale und/oder analoge Kommunikationsmedien (beispielsweise einen Lichtwellenleiter, einen Wellenführer, eine verkabelte Kommunikationsverbindung, eine kabellose Kommunikationsverbindung usw.).
Fachleute auf dem Gebiet werden erkennen, dass es in der Branche üblich ist, Geräte und/oder Prozesse in der hier dargelegten Art und Weise zu beschreiben und danach Engineering-Verfahren zu verwenden, um die derart beschriebenen Geräte und/oder Prozesse in Datenverarbeitungssysteme umzusetzen. Das ist wenigstens eine Menge der Geräte und/oder Prozesse, die beschrieben wurden, können integriert werden in das Datensystem über eine begründeten Betrag von Experimenten. Diese, die in der Wissenschaft befähigt sind, werden erkennen, dass ein typisches Datenprozesssystem gewöhnlich eine oder mehrere Systemeinheiten beinhaltet, ein Videodisplay-Gerät, ein Memory wie flüchtige und nichtflüchtige Memory, Prozessoren wie Mikroprozessoren und digitale Signalprozessoren, computerbasierte Einheiten, wie Operatoren, Treiber, graphische Nutzerkarten, und App-Programme, eine oder mehrere Interaktionsgeräte wie ein Touchpad oder Screen und/oder Kontrollsysteme einschließlich Rückkopplungsschleifen und Kontrollmotoren (beispielsweise Rückkopplung für Abtastpositionen und/oder Geschwindigkeit; Kontrollmotoren für Bewegung und/oder Ausrichtungskomponenten und/oder Mengen). Ein typisches Datenprozesssystem kann gewöhnliche kommerziell erhältliche Komponenten implementieren wie typische Datencomputerkommunikation und/oder Netzwerkcomputerkommunikationssysteme.
In Bezug auf die Verwendung von im Wesentlichen jedem Plural- und/oder Singularbegriff hierin, können Fachleute auf dem Gebiet je nach Kontext und/oder Anwendung passend Plural in Singular und/oder Singular in Plural übersetzen. Die verschiedenen Singular-/Plural-Permutationen können hierin ausdrücklich aus Gründen der Klarheit dargelegt.
Exemplarische Ausführungsformen sind in der vorliegenden Offenbarung beschrieben. Es versteht sich, dass die Ausführungsformen im Rahmen des erfinderischen Konzepts, wie hierin ausgedrückt, in verschiedenen anderen Kombinationen und Umgebungen eingesetzt und in der geändert oder modifiziert werden können. Einige dieser Variationen können Programme sein, die auf nicht flüchtigen computerlesbaren Medien gespeichert werden, damit Computer und/oder Computersystemen unseren Teil oder alle der oben beschriebenen Verfahrensvarianten tragen können. Diese Variationen sind nicht als Abweichung vom Sinn und Umfang der Erfindung zu betrachten, und alle derartigen Modifikationen, wie sie für Fachleute Fachmann auf dem Gebiet offensichtlich sind, sind dazu gedacht, in den Umfang der folgenden Ansprüche aufgenommen zu werden:

Claims

System, das Folgendes umfasst: einen oder mehrere Computer; ein computerlesbares Medium, das mit dem einen oder mehreren Computer(n) gekoppelten ist und auf dem Anweisungen gespeichert sind, die bei Ausführung durch den einen oder mehrere Computer dazu führen, dass der eine oder mehrere Computer Operationen wie folgt ausführen: das Erstellen einer ersten Kompilierungsstrategie für ein erstes Build; das Erbringen des genannten ersten Builds unter Verwendung dieser ersten Kompilierungsstrategie; das Berechnen einer ersten Prüfsumme für diesen ersten Build; das Speichern der genannten ersten Kompilierungsstrategie und dieser ersten Prüfsumme; das Berechnen einer zweite Prüfsumme für ein zweites Build; das Ermitteln, ob diese zweite Prüfsumme mit dieser erster Prüfsumme identisch ist; das Erstellen – bei Ermittlung, dass diese zweite Prüfsumme nicht mit dieser ersten Prüfsumme identisch ist – einer zweiten Kompilierungsstrategie; das Speichern dieser zweiten Kompilierungsstrategie und dieser zweiter Prüfsumme, und das Erbringen des zweiten Builds unter Verwendung dieser zweiten Kompilierungsstrategie; und das Abrufen – bei Ermittlung, dass diese zweite Prüfsumme mit dieser erster Prüfsumme identisch ist – dieser erster Kompilierungsstrategie und Erbringen des diesen zweiten Builds unter Verwendung dieser erster Kompilierungsstrategie.
System nach Anspruch 1, worin diese erste Prüfsumme eine globale Build-Prüfsumme ist; und diese globale Build-Prüfsumme unter Verwendung einer oder mehrerer lokalen Build Prüfsummen berechnet wird.
System nach Anspruch 1, wobei die Anweisungen ferner Anweisungen umfassen, die beim Ausführung dazu führen, das der Computer weitere Operationen wie folgt ausführt: das Bestimmen, ob eine für das erste Build berechnete lokale Build-Prüfsumme gegenüber dem zweiten Build unverändert geblieben ist, und das Wiederverwenden von Teilen der ersten, mit der lokalen Build Prüfsumme verknüpften Kompilierungsstrategie in der zweiten Kompilierungsstrategie.
System nach Anspruch 1, worin die Dateisysteminformationen nach Pfadnamen sortiert werden, um lokale Prüfsummen zu berechnen.
System nach Anspruch 4, worin die Dateisysteminformationen eine Prüfsumme enthalten.
System nach Anspruch 1, worin das Erbringen des diesen ersten Builds unter Verwendung dieser ersten Kompilierungsstrategie weiterhin das Untersuchen des Inhalts einer Konfigurationsdatei zur Ermittlung der Abhängigkeiten umfasst; und das Berechnen einer lokalen Build-Prüfsumme für jede Abhängigkeit dieser Konfigurationsdatei.
System nach Anspruch 1, wobei die Anweisungen ferner Anweisungen umfassen, die beim Ausführung dazu führen, das der Computer weitere Operationen wie folgt ausführt: das Berechnung eines transitiven Abschusses basierend auf Abhängigkeiten dieser Konfigurationsdateien.
System nach Anspruch 7, worin eine lokale Build-Prüfsumme für jede Konfigurationsdatei des diesen berechneten transitiven Abschlusses berechnet wird.
System nach Anspruch 1, worin die Prüfsumme mithilfe einer XOR-Funktion berechnet wird.
System nach Anspruch 1, worin das Berechnen dieser erster Prüfsumme die Durchführung einer deterministischen Sortierung beinhaltet; das Berechnen einer lokalen Build-Prüfsumme mit dieser deterministischer Sortierung; und das Berechnen der ersten Prüfsumme mithilfe dieser lokaler Build-Prüfsumme, wobei diese erste Prüfsumme eine globale Build-Prüfsumme ist.