DE19581754B4

DE19581754B4 - System und Verfahren zum bedingten Kompilieren einer Software-Kompiliereinheit

Info

Publication number: DE19581754B4
Application number: DE19581754T
Authority: DE
Inventors: Shankar Campbell Unni; Andrew J. Mountain View Palay
Original assignee: Silicon Graphics Inc
Current assignee: Graphics Properties Holdings Inc
Priority date: 1994-08-26
Filing date: 1995-08-02
Publication date: 2005-12-29
Anticipated expiration: 2015-08-03
Also published as: GB2307073A; GB2307073B; JP3802058B2; JPH10507016A; GB9703860D0; WO1996007137A1; DE19581754T1; US5692196A

Abstract

Verfahren zum bedingten Rekompilieren einer Kompiliereinheit mit mehreren Quellcodebausteinen, mit den folgenden Schritten:
(1) Auswahl eines der Quellcodebausteine;
(2) Feststellen, ob eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß;
(3) Erzeugen einer neuen verdichteten Darstellung des ausgewählten Quellcodebausteins in Abhängigkeit von der Feststellung im Schritt (2); und
(4) Erkennung von Änderungen zwischen der neuen verdichteten Darstellung des ausgewählten Quellcodebausteins und einer alten verdichteten Darstellung des ausgewählten Quellcodebausteins; gekennzeichnet durch
(5) Klassifikation jeder der Änderungen als kompatible Änderung bzw. inkompatible Änderung,
wobei eine inkompatible Änderung eine Änderung ist, die ausgewählt ist aus der Gruppe bestehend aus (a) Hinzufügen eines Elements zu einem Satz oder zu einer Klasse, (b) Löschen eines Elements aus einem Satz oder einer Klasse, (c) Typänderung eines Elements eines Satzes oder einer Klasse, (d) Hinzufügen einer neuen Variablen, (e) Hinzufügen eines neuen Datentyps, (f) Modifizieren eines vorhandenen Datentyps und (g)...

Description

Ausganssituation der Erfindung
Technisches Gebiet der Erfindung
Die Erfindung betrifft allgemein das Kompilieren einer Kompiliereinheit und insbesondere das erneute bzw. Rekompilieren einer Kompiliereinheit nur dann, wenn sich Komponenten der Kompiliereinheit auf inkompatible Weise verändert haben.

Eine Software-Kompiliereinheit weist typischerweise ein "Haupt"-Softwareprogramm und eine oder mehrere Vorsatz- bzw. Kopfdateien auf. Kopfdateien werden unter Verwendung geeigneter Software-Anweisungen, die im "Haupt"-Programm (oder in den Kopfdateien selbst) untergebracht sind, explizit in die Kompiliereinheit aufgenommen. In der bekannten Computerprogrammiersprache C werden z. B. "include"- bzw. Einfügungsanweisungen verwendet, um Kopfdateien in die Kompiliereinheit aufzunehmen. Beispielsweise wird die Anweisung
#include "a.h."
in das "Haupt"-Programm eingefügt, um eine mit "a.h." bezeichnete Kopfdatei in die Kompiliereinheit aufzunehmen. Da die Kopfdateien mit Hilfe von "include-" bzw. Einfügungsanweisungen in die Kompiliereinheit eingefügt werden, bezeichnet man Kopfdateien auch als "Einfügungsdateien". Diese Begriffe (d. h. "Kopfdateien" und "Einfügungsdateien") sind hier austauschbar.

Herkömmlicherweise wird das "Haupt"-Programm zuzüglich aller Kopfdateien jedesmal dann kompiliert, wenn die Kompiliereinheit kompiliert wird. Das bekannte UNIX-Dienstprogramm "make" arbeitet so, daß es eine Kompiliereinheit nur dann kompiliert, wenn irgendeine ihrer Komponenten (d. h. das "Haupt"-Programm und/oder irgendeine der Kopfdateien) sich geändert hat.

Die US 5,201,050 A beschreibt ein computerunterstütztes Softwareentwicklungssystem das Programme enthält zum Ändern, Kompilieren, Verbinden und Ablaufen lassen von Sequenzen. Der Kompilierer arbeitet dabei zeilenweise, sodass jeweils nur eine Zeile, die bei einer Änderung modifiziert wurde, rekompiliert wird, wenn kein anderer Code davon betroffen ist. In dieser Softwareentwicklungsumgebung wird die Bearbeitungszeit, die als Zyklus zum Ändern, Kompilieren, Verbinden und Ablaufen lassen definiert ist, optimiert, nachdem ein Entwickler eine kleine Änderung an den Quellcode durchgeführt hat. Mit dem System wird eine Änderung in einer Quellcodezeile identifiziert ohne die Größe oder die Art der Änderung näher zu bestimmen.

Oft ist es jedoch nicht nötig, die Kompiliereinheit zu rekompilieren, selbst wenn sich eine oder mehrere ihrer Komponenten seit der letzten Kompilierung der Kompiliereinheit geändert haben. Wenn zum Beispiel nur Formatierungsänderungen an den Komponenten der Kompiliereinheit vorgenommen wurden, dann ist das Rekompilieren der Kompiliereinheit nicht notwendig. Herkömmlicherweise wird jedoch die Kompiliereinheit jedesmal rekompiliert, wenn irgendwelche Änderungen an ihren Komponenten ausgeführt worden sind. Folglich führen herkömmliche Kompilierer unnötige Kompilieroperationen aus. Daraus ergibt sich eine unrationelle Nutzung von Systemquellen durch herkömmliche Kompilierer.

Zusammenfassung der Erfindung

Die vorliegende Erfindung betrifft ein System und ein Verfahren zum bedingten Rekompilieren e er Kompiliereinheit mit mehreren Quellcodebausteinen gemäß den Ansprüchen 1 und 2. Die vorliegende Erfindung funktioniert, indem sie einen der Quellcodebausteine auswählt und feststellt, ob eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß. Eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins wird erzeugt, wenn festgestellt wird, daß diese Darstellung notwendig ist. Die vorliegende Erfindung erkennt dann Änderungen zwischen der neuen verdichteten Darstellung des ausgewählten Quellcodebausteins und einer alten verdichteten Darstellung des ausgewählten Quellcodebausteins. Jede dieser Änderungen wird entweder als kompatible Änderung oder als inkompatible Änderung klassifiziert. Eine inkompatible Änderung ist eine Änderung, die ein Rekompilieren der Kompiliereinheit erfordert. Eine kompatible Änderung ist eine Änderung, die kein Rekompilieren der Kompiliereinheit erfordert. Die vorliegende Erfindung gibt das Rekompilieren der Kompiliereinheit nur dann frei, wenn irgendeine der Änderungen als inkompatible Änderung klassifiziert wird.

Weitere Merkmale und Vorteile der vorliegenden Erfindung sowie die Struktur und Arbeitsweise verschiedener Ausführungsformen der Erfindung werden nachstehend anhand der beigefügten Zeichnungen näher erläutert. In den Zeichnungen be zeichnen gleiche Bezugszeichen identische oder funktionell ähnliche Elemente.

Kurze Beschreibung der Zeichnungen
Die vorliegende Erfindung wird nachstehend anhand der Zeichnungen beschrieben. Dabei zeigen:
1 ein Blockschaltbild eines Computersystems nach einer bevorzugten Ausführungsform der vorliegenden Erfindung;
2, 3A-3C und 4-7 die Dateitypen, die in einer Speichereinrichtung des Computersystems von 1 gespeichert werden können, und die bevorzugten Formate solcher Dateien;
8-10 Ablaufdiagramme, welche die bevorzugte Arbeitsweise der vorliegenden Erfindung darstellen;
11-14 Zeitdiagramme, die zur Erläuterung der Arbeitsweise der vorliegenden Erfindung dienen;
15 eine Tabelle, in der die Analyse bezüglich des Zeitdiagramms in 14 zusammengefaßt ist.
Detaillierte Beschreibung der bevorzugten Ausführungsformen
1 zeigt ein Blockschaltbild eines Computersystems 102 nach einer bevorzugten Ausführungsform der Erfindung. Vorzugsweise ist das Computersystem 102 eine Indy Workstation, die mit dem Irix 5.2-Betriebssystem arbeitet, hergestellt von Silicon Graphics, Inc., Mountain View, CA; allerdings könnte alternativ irgendein anderes geeignetes Computersystem verwendet werden. Das Computersystem 102 weist einen Prozessor 104 auf, der mit einem Bus 106 verbunden ist. Der Prozessor 104 ist vorzugsweise eine Zentraleinheit (CPU) der Serie MIPS R4000, hergestellt von Silicon Graphics, Inc., wobei alternativ irgendeine andere geeignete Zentraleinheit verwendet werden könnte.
Außerdem ist an den Bus 106 eine Speichereinrichtung 108 angeschlossen, die einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), sekundäre Speichereinrichtungen (wie z. B. Festplattenlaufwerke) oder irgendeine Kombination der obigen Speicher darstellen kann.
Der Prozessor 104 arbeitet gemäß der Steuerlogik 110. Diese Steuerlogik 110 repräsentiert vorzugsweise ein oder meh rere Computerprogramme, wie z. B. einen Software-Kompilierer 112 und einen Kompilierer-Vorprozessor (bzw. -Vorkompilierer) 114, die in der Speichereinrichtung 108 gespeichert sind. Folglich arbeitet der Prozessor 104 nach Anweisungen, die in derartigen Computerprogrammen enthalten sind. Solche Computerprogramme werden vorzugsweise in C, C++, Pascal und/oder Assembler geschrieben, wobei alternativ irgendeine andere geeignete Computerprogrammiersprache benutzt werden könnte.
Zu beachten ist, daß der Software-Kompilierer 112 und der Kompilierer-Vorprozessor 114 Teile eines einzigen Computerprogramms oder verschiedene Computerprogramme darstellen können. Außerdem ist zu beachten, daß die Steuerlogik 110 alternativ als Maschine im Hardware-Zustand implementiert werden kann.
In einer Ausführungsform ist die vorliegende Erfindung ein Computerprogramm-Produkt mit einem computerlesbaren Medium, auf dem die Steuerlogik 110 aufgezeichnet ist. Die Steuerlogik 110 wird unter Verwendung irgendeiner bekannten Einrichtung in die Speichereinrichtung 108 geladen und durch den Prozessor 104 ausgeführt.
Außerdem sind in der Speichereinrichtung 108 Quelldateien 116 gespeichert. Wie in 2 dargestellt, können die Quelldateien 116 z.B. eine "Haupt"-Quelldatei 202 aufweisen (in 2 als "main.c" bzw. "Haupt.c" bezeichnet). Ein Teil einer als Beispiel dienenden "Haupt"-Quelldatei 202 ist in 4 dargestellt. Dieses Beispiel einer "Haupt"-Quelldatei 202 schließt drei "include"- bzw. Einfügungsanweisungen ein, die auf bekannte Weise so funktionieren, daß der Code von Einfügungsdateien "a.h", "b.h" und "c.h" in die "Haupt"-Quelldatei 202 aufgenommen wird.
Wie wiederum aus 1 erkennbar, speichert die Speichereinrichtung 108 auch Kopfdateien 120 (die auch als Einfügungsdateien und Quellcodebausteine bezeichnet werden). Wie in 3B dargestellt, können Kopfdateien 120 die Kopfdateien "a.h", "b.h", "c.h", "d.h" bzw. "e.h" einschließen, die durch die Bezugszeichen 304, 306, 308, 310 bzw. 312 bezeichnet werden. Ein Teil einer Musterkopfdatei, wie z. B. der "a.h"-Kopfdatei 304, ist in 5 dargestellt. Diese "a.h"-Musterkopf datei 304 weist verschiedene Vereinbarungsanweisungen auf (in 5 als <erste Vereinbarungen> und <zweite Vereinbarungen>) bezeichnet). Diese "a.h"-Musterkopfdatei 304 weist außerdem zwei "include"- bzw. Einfügungsanweisungen auf, die auf bekannte Weise so funktionieren, daß der Code der "d.h"- und "e.h"-Kopfdateien 310 und 312 in die "a.h"-Kopfdatei 304 aufgenommen wird. Wie man einsehen wird, stellen die Kopfdateien 120 Quellcodebausteine dar, da sie einen Quellcode (statt beispielsweise einen Binärcode) aufweisen.
Wie wiederum aus 1 ersichtlich, sind in der Speichereinrichtung 108 auch vorkompilierte Kopfdateien 122 gespeichert. Wie der Fachmann erkennen wird, ist eine vorkompilierte Kopfdatei eine verdichtete Binärdarstellung einer Kopfdatei. Die Form einer vorkompilierten Kopfdatei ist vorzugsweise identisch mit der Form, die von Kompilierern zur internen Darstellung von Quellprogramm- bzw. Primäranweisungen während des Kompilierens benutzt wird. Solche vorkompilierten Kopfdateien lassen sich schneller in den Kompilierer einlesen als die ursprüngliche Kopfdatei, da ein großer Teil der internen Verarbeitung des Kompilierers für die Vereinbarungen in den vorkompilierten Kopfdateien zuvor ausgeführt worden ist (beim Erstellen der vorkompilierten Kopfdatei). Wie in 3C dargestellt, weisen die vorkompilierten Kopfdateien 122 die vorkompilierten "a.x"-, "b.x"-, "c.x"- bzw. "d.x"-Kopfdateien 314, 316, 318 bzw. 320 auf, die den "a.h"-, "b.h"-, "c.h"- bzw. "d.h"- Kopfdateien 304, 306, 308 bzw. 310 entsprechen.
6 stellt eine vorkompilierte Musterkopfdatei dar, wie z. B. die "a.x"-Datei 314. Die "a.x"-Datei 314 schließt Felder 606 und 610 ein, die kompiliererinterne Darstellungen der Vereinbarungen enthalten, die in der "a.h"-Kopfdatei 304 enthalten sind (in 5 als <erste Vereinbarungen> und <zweite Vereinbarungen> bezeichnet). Die "a.x"-Datei 314 weist außerdem Felder 608 und 612 auf, die Informationen zur Freigabe der Einfügung (während der Ausführung des Software-Binderprogramms) der "d.h"- und "e.h"- Kopfdateien 310, 312 enthalten. Die "a.x"-Datei 314 enthält ferner ein Kopffeld 604. Das Kopffeld 604 enthält historische Informationen über frühere Versionen der "a.x"-Datei 314. Dieses Kopffeld 604 wird weiter unten ausführlicher erörtert.
Wie wiederum aus 1 erkennbar, sind in der Speichereinrichtung 108 auch Objekt- bzw. Sekundärdateien 118 gespeichert. Eine Objektdatei ist eine Kollektion von Maschinenbefehlen. Eine oder mehrere Objektdateien können miteinander verknüpft werden, um ein ablauffähiges Programm zu bilden. Wie in 3A dargestellt, können solche Objektdateien 118 eine "Haupt"-Objektdatei 302 aufweisen (in 3 als "main.o" bzw. "Haupt.o" bezeichnet), die eine kompilierte Binärversion der "Haupt"-Quelldatei 202 und ihrer Kopfdateien ist.
Nach einer bevorzugten Ausführungsform der vorliegenden Erfindung arbeiten der Kompilierer-Vorprozessor 114 und der Software-Kompilierer 112 so, daß sie eine Kompiliereinheit kompilieren, um eine kompilierte Objektcode-Version der Kompiliereinheit (d. h. eine Objektdatei) zu erzeugen. Dann kann ein Software-Binder (nicht dargestellt) benutzt werden, um auf bekannte Weise aus der Objektcode-Version der Kompiliereinheit eine ablauffähige Datei zu erzeugen. Der Software-Binder bildet keinen Teil der vorliegenden Erfindung und soll daher nicht weiter beschrieben werden. Die ablauffähige Datei kann durch ein Computersystem ausgeführt werden, wie z. B. durch das in 1 dargestellte Computersystem 102.
Nachstehend sollen die Arbeitsweise des Kompilierer-Vorprozessors 114 und des Software-Kompilierers 112 allgemein beschrieben werden. Zu Erläuterungszwecken wird angenommen, daß die zu kompilierende Kompiliereinheit die folgenden Software-Elemente aufweist: die "Haupt"-Quelldatei 202, wie in 4 dargestellt, und die in 3B dargestellten "a.h"-, "b.h"-, "c.h"-, "d.h"- und "e.h"-Kopfdateien 304, 306, 308, 310, 312, wobei die Details der "a.h"-Kopfdatei 304 der Darstellung in 5 entsprechen.
Das Kompilieren dieser Kompiliereinheit geht im allgemeinen wie folgt vonstatten. Zunächst analysiert der Kompilierer-Vorprozessor 114 die Kompiliereinheit, um festzustellen, ob die Kompiliereinheit rekompiliert werden muß. Allgemein gesagt, braucht die Kompiliereinheit nicht rekompiliert zu werden, wenn sich die Kompiliereinheit nicht verändert hat, seit dem sie zuletzt kompiliert wurde. Außerdem braucht nach der vorliegenden Erfindung die Kompiliereinheit auch dann nicht rekompiliert zu werden, wenn sich die Kompiliereinheit verändert hat, seitdem sie zuletzt kompiliert wurde, solange solche Änderungen "kompatible Änderungen" sind. Was "kompatible Änderungen" sind, wird weiter unten diskutiert.
Dann kompiliert der Kompilierer 112 die Kompiliereinheit, wenn diese Kompilierung als notwendig betrachtet wurde. Der Kompilierer 112 kompiliert die Kompiliereinheit unter Anwendung irgendwelcher bekannter und geeigneter Kompilierverfahren. Derartige Kompilierverfahren sind sprachenspezifisch. Wenn z. B. die zu kompilierenden Kopfdateien in der Computerprogrammiersprache C++ geschrieben sind, dann führt der Kompilierer 112 seine Kompilierfunktion unter Anwendung irgendwelcher bekannter Kompilierverfahren aus, die für die Computerprogrammiersprache C++ geeignet sind.
Nachstehend soll anhand eines in 8 dargestellten Ablaufdiagramms 802 beschrieben werden, auf welche Weise der Kompilierer-Vorprozessor 114 eine Kompiliereinheit analysiert, um festzustellen, ob die Kompiliereinheit rekompiliert werden muß. Zu Erläuterungszwecken soll das obige Beispiel auf geeignete Weise zur Beschreibung des Operationsablaufs des Ablaufdiagramms 802 benutzt werden. Präzise gesagt, in der nachstehenden Diskussion wird angenommen, daß die zu kompilierende Kompiliereinheit die in 4 dargestellte "Haupt"-Quelldatei 202 und die in 3B dargestellten "a.h"-, "b.h"-, "c.h"-, "d.h"- und "e.h"- Kopfdateien 304, 306, 308, 310, 312 aufweist, wobei die Details der "a.h"-Kopfdatei 304 der Darstellung in 5 entsprechen. Das Ablaufdiagramm 802 beginnt mit dem Schritt 804, wobei die Ablaufsteuerung unmittelbar zum Schritt 805 übergeht.
Im Schritt 805 stellt der Kompilierer-Vorprozessor 114 fest, ob eine Objektcode-Version (d. h. eine Objektdatei) der Quelldatei existiert. Außerdem stellt der Kompilierer-Vorprozessor 114 fest, ob die Quelldatei und die darin verzeichneten Makros unverändert geblieben sind, seit die Kompiliereinheit zuletzt kompiliert wurde. Wenn entweder (1) keine Objektcode-Version der Quelldatei existiert oder (2) die Quelldatei und/oder die darin verzeichneten Makros sich geändert haben, seitdem die Kompiliereinheit zuletzt kompiliert wurde, dann wird der Schritt 807 ausgeführt, in dem der Kompilierer-Vorprozessor 114 ein (weiter unten beschriebenes) Rekompilierflag auf "true" (wahr) setzt. Andernfalls wird der (weiter unten beschriebene) Schritt 806 ausgeführt. Im gegenwärtigen Beispiel stellt der Kompilierer-Vorprozessor 114 im Schritt 805 fest, daß "main.o" 302 (3A), d. h, die Objektdatei-Darstellung von "main.c" 202 (2), existiert. Es wird angenommen, daß "main.c" 202 und die darin verzeichneten Makros unverändert sind, seit "main.c" 202 zuletzt kompiliert wurde. Folglich wird der Schritt 806 ausgeführt.
Gemäß der vorliegenden Erfindung ist mit jeder Kompiliereinheit ein Rekompilierflag verbunden. Das Rekompilierflag wird vorzugsweise in einem Direktzugriffsspeicher (RAM) verwaltet, wie z. B. in der Speichereinrichtung 108. Das Rekompilierflag gibt an, ob die Kompiliereinheit rekompiliert werden muß. Präzise gesagt, wenn das Rekompilierflag gesetzt ist (d. h. auf einen Wert "1" gesetzt ist), dann muß die Kompiliereinheit kompiliert werden (in dem weiter unten beschriebenen Schritt 816). Wenn das mit der Kopfdatei verbundene Rekompilierflag gelöscht ist, dann braucht diese Kopfdatei nicht kompiliert zu werden (Schritt 815, beschrieben weiter unten).
Im Schritt 806 löscht der Kompilierer-Vorprozessor 114 das mit der Kompiliereinheit verbundene Rekompilierflag (d. h. er setzt es auf einen Wert null oder den logischen Wert "false" (falsch)).
Im Schritt 808 wählt der Kompilierer-Vorprozessor 114 zur Analyse eine der in der Kompiliereinheit verzeichneten Kopfdateien 304, 306, 308, 310, 312 aus. Zu Erläuterungszwecken wird angenommen, daß in diesem Schritt 808 die "d.h" – Kopfdatei 310 ausgewählt wird.
Im Schritt 810 analysiert der Kompilierer-Vorprozessor 114 die im Schritt 808 ausgewählte Kopfdatei (d. h. die "d.h"-Kopfdatei 310), um festzustellen, ob die Kompiliereinheit wegen Änderungen in dieser Kopfdatei rekompiliert werden muß. Wenn der Kompilierer-Vorprozessor 114 feststellt, daß die Kompiliereinheit rekompiliert werden muß, dann setzt der Vorpro zessor 114 das Rekompilierflag auf den logischen Wert "true" (wahr). Wie der Vorprozessor 114 den Schritt 810 ausführt, wird weiter unten ausführlich beschrieben.
Im Schritt 812 stellt der Vorprozessor 114 fest, ob irgendwelche weiteren Kopfdateien 304, 306, 308, 310, 312 zu verarbeiten sind. Kopfdateien 304, 306, 308, 310, 312, die vorher im Schritt 808 ausgewählt und im Schritt 810 analysiert worden sind, brauchen nicht nochmals verarbeitet zu werden. Wenn noch weitere Kopfdateien zu verarbeiten sind, kehrt die Ablaufsteuerung zum Schritt 808 zurück, um eine der übrigen Kopfdateien auszuwählen.
Im Schritt 814, nachdem alle Kopfdateien verarbeitet worden sind (wie im Schritt 812 ermittelt), stellt der Vorprozessor 114 fest, ob das (mit der Kompiliereinheit verbundene) Rekompilierflag auf den logischen Wert "true" (wahr) gesetzt ist. Wenn das Rekompilierflag nicht gesetzt ist, dann braucht die Kompiliereinheit nicht rekompiliert zu werden, wie durch den Schritt 815 angezeigt wird.
Wenn das Rekompilierflag gesetzt ist, dann weist der Vorprozessor 114 im Schritt 816 den Kompilierer 112 an, die Kompiliereinheit zu kompilieren.
Nach Ausführung des Schritts 815 oder 816 ist der Operationsablauf des Ablaufdiagramms 802 beendet, wie im Schritt 818 angezeigt wird.
Nachstehend wird anhand eines Ablaufdiagramms 902 in 9 beschrieben, wie der Kompilierer-Vorprozessor 114 im Schritt 810 die ausgewählte Kopfdatei (ausgewählt im Schritt 808) analysiert. Das Ablaufdiagramm 902 stellt den Operationsablauf des Vorprozessors 114 bei der Ausführung des Schritts 810 dar. Das Ablaufdiagramm 902 beginnt mit dem Schritt 904, wobei die Ablaufsteuerung unmittelbar zum Schritt 906 übergeht.
Im Schritt 906 stellt der Vorprozessor 114 fest, ob eine vorkompilierte Kopfdatei (VKD) existiert, die der ausgewählten Kopfdatei entspricht. Existiert eine solche vorkompilierte Kopfdatei, dann wird der Schritt 908 ausgeführt. Sonst wird der Schritt 930 ausgeführt.
Als Beispiel wird angenommen, daß im Schritt 808 ( 8) die "e.h"-Kopfdatei 312 ausgewählt wurde. In diesem Falle stellt der Vorprozessor 114 im Schritt 906 fest, daß keine vorkompilierte Kopfdatei existiert, die der ausgewählten Kompiliereinheit (d. h. der "e.h"- Kopfdatei 312) entspricht (siehe 3C). Infolgedessen wird der Schritt 930 ausgeführt. Im Schritt 930 veranlaßt der Vorprozessor 114 den Kompilierer 112, mit Hilfe bekannter, sprachenspezifischer Kompilierverfahren eine vorkompilierte Kopfdatei (genannt "e.x") zu erzeugen, die der ausgewählten Kopfdatei (d. h. der "e.h"-Kopfdatei 312) entspricht. Diese neue vorkompilierte Kopfdatei wird mit den anderen vorkompilierten Kopfdateien 122 in der Speichereinrichtung 108 gespeichert. Im Schritt 932 setzt der Vorprozessor 114 das Rekompilierflag. Nach der Ausführung des Schritts 932 ist der Operationsablauf des Ablaufdiagramms 902 beendet, wie durch den Schritt 916 angezeigt wird.
Als Beispiel wird angenommen, daß im Schritt 808 ( 8) die "b.h"-Kopfdatei 306 ausgewählt wurde. In diesem Falle stellt der Vorprozessor 114 im Schritt 906 fest, daß eine vorkompilierte Kompiliereinheit existiert, die der ausgewählten Kopfdatei (d. h. der "b.h"-Kopfdatei 306) entspricht (siehe 3C). Infolgedessen wird der Schritt 908 ausgeführt.
Im Schritt 908 stellt der Vorprozessor 114 fest, ob die vorkompilierte Kopfdatei, die der ausgewählten Kopfdatei entspricht, eine Anzahl vordefinierter Voraussetzungen erfüllt. Wenn die vorkompilierte Kopfdatei alle vordefinierten Voraussetzungen erfüllt, dann braucht eine vorkompilierte Kopfdatei für die Kopfdatei nicht regeneriert zu werden. Wenn stattdessen die vorkompilierte Kopfdatei nicht alle vordefinierten Voraussetzungen erfüllt, dann muß eine vorkompilierte Kopfdatei für die Kopfdatei regeneriert werden, da die aktuelle vorkompilierte Kopfdatei veraltet ist.
Wie der Vorprozessor 114 den Schritt 908 ausführt, ist durch ein Ablaufdiagramm 1002 in 10 dargestellt. Dieses Ablaufdiagramm 1002 beginnt mit dem Schritt 1004, wobei die Ablaufsteuerung sofort zum Schritt 1006 übergeht.
Im Schritt 1006 stellt der Vorprozessor 114 fest, ob die vorkompilierte Kopfdatei neuer ist als die ausgewählte Kopfdatei (d. h. ob das Erstellungsdatum der vorkompilierten Kopfdatei jünger ist als das Erstellungasdatum der ausgewählten Kopfdatei). Im wesentlichen stellt der Vorprozessor 114 im Schritt 1006 fest, ob die ausgewählte Kopfdatei seit der letzten Erstellung der vorkompilierten Kopfdatei modifiziert worden ist. Ist die Kopfdatei seit der letzten Erstellung der vorkompilierten Kopfdatei modifiziert worden (d. h. wenn die vorkompilierte Kopfdatei nicht neuer ist als die ausgewählte Kopfdatei), dann stellt der Vorprozessor 114 fest, daß für die ausgewählte Kopfdatei eine vorkompilierte Kopfdatei regeneriert werden muß. Dementsprechend stellt der Vorprozessor 114 fest, daß die vorkompilierte Kopfdatei die Voraussetzungen nicht erfüllt (Schritt 1012). Andernfalls wird der Schritt 1008 ausgeführt, um die vorkompilierte Kopfdatei im Hinblick auf die nächste Voraussetzung zu beurteilen.
Der Operationsablauf des Vorprozessors 114 während des Schritts 1006 wird durch Musterzeitdiagramme 1102 bzw. 1202 erläutert, die in 11 bzw. 12 dargestellt sind. Wir betrachten zunächst das in 12 dargestellte Zeitdiagramm 1202. Im Zeitdiagramm 1202 wurde die ausgewählte Kopfdatei (d.h. die "b.h"-Kopfdatei 306) zum Zeitpunkt t1 erstellt und zum Zeitpunkt t3 modifiziert. Die entsprechende vorkompilierte Kopfdatei (d. h. die vorkompilierte "b.x"-Kopfdatei 316) wurde zuletzt zum Zeitpunkt t2 erzeugt. Der Vorprozessor 114 führt zum Zeitpunkt t4 den Schritt 1006 aus. Bezüglich des Zeitdiagramms 1202 stellt der Vorprozessor im Schritt 1006 fest, daß die vorkompilierte Kopfdatei nicht neuer ist als die ausgewählte Kopfdatei. Folglich wird der (oben beschriebene) Schritt 1012 ausgeführt.
Im Zeitdiagramm 1102 von 11 wurde die ausgewählte Kopfdatei (die "b.h"-Kopfdatei 306) zum Zeitpunkt t1 erstellt. Die entsprechende vorkompilierte Kopfdatei (die vorkompilierte "b.x"-Kopfdatei 316) wurde zuletzt zum Zeitpunkt t2 erzeugt. Der Vorprozessor 114 führt den Schritt 1006 zum Zeitpunkt t3 aus. Bezüglich des Zeitdiagramms 1102 stellt der Vorprozessor 114 im Schritt 1006 fest, daß die vorkompilierte Kopfdatei neuer ist als die ausgewählte Kopfdatei. Folglich wird der Schritt 1008 ausgeführt.
Im Schritt 1008 stellt der Vorprozessor 114 fest, ob die in der ausgewählten Kopfdatei enthaltenen Makros (falls vorhanden) die gleichen sind wie bei der letzten Erzeugung der entsprechenden vorkompilierten Kopfdatei. Ein Makro ist typischerweise wie folgt definiert:
#define Makro-Name Erweiterungs-Tokens
oder
#define Makro-Name (Parameter, Parameter) Erweiterungs-Tokens
wobei Erweiterungs-Tokens eine Kollektion von Tokens (Wörtern, Symbolen usw.) bedeutet, die in der gerade kompilierten Sprache zulässig sind. Wenn der Kompilierer 112 in der Quelle (irgendwo nach dieser Definition) ein Wort erkennt, das mit einer dieser Makro-Namen übereinstimmt, dann ersetzt er das Wort und etwaige anschließende Parameterlisten durch die in den Makrodefinitionen spezifizierten Erweiterungs-Tokens. Makros sind Fachleuten auf diesem Gebiet wohlbekannt.
Wenn die in der ausgewählten Kopfdatei enthaltenen Makros nicht die gleichen sind wie bei der letzten Erzeugung der entsprechenden vorkompilierten Kopfdatei, dann stellt der Vorprozessor 114 fest, daß eine vorkompilierte Kopfdatei für die ausgewählte Kopfdatei regeneriert werden muß. Dementsprechend stellt der Vorprozessor 114 fest, daß die vorkompilierte Kopfdatei die Voraussetzungen nicht erfüllt (Schritt 1012). Wenn im anderen Falle die in der ausgewählten Kopfdatei enthaltenen Makros die gleichen sind wie bei der letzten Erzeugung der entsprechenden vorkompilierten Kopfdatei, dann stellt der Vorprozessor 114 fest, daß alle Voraussetzungen erfüllt worden sind (Schritt 1010).
Wie wiederum aus 9 erkennbar, wird der Schritt 918 ausgeführt, wenn der Vorprozessor 114 im Schritt 908 feststellt, daß die vorkompilierte Kopfdatei die Voraussetzungen nicht erfüllt. Im Schritt 918 veranlaßt der Vorprozessor 114 den Kompilierer 112, die vorkompilierte Kopfdatei für die ausgewählte Kopfdatei unter Anwendung bekannter, sprachspezifischer Kompilierverfahren zu regenerieren. Diese neue vorkompilierte Kopfdatei wird mit den anderen vorkompilierten Kopfdateien 122 in der Speichereinrichtung 108 gespeichert. Zu diesen vorkompilierten Kopfdateien 122 gehört auch die alte vorkompilierte Kopfdatei (die mit der ausgewählten Kopfdatei verbunden ist), die im Schritt 908 analysiert wurde.
Im Schritt 920 vergleicht der Vorprozessor 114 die neue vorkompilierte Kopfdatei mit der alten vorkompilierten Kopfdatei und stellt die Änderungen zwischen den beiden fest (diese Änderungen spiegeln die Änderungen in der ausgewählten Kopfdatei wider, seitdem diese zuletzt kompiliert wurde). Im Schritt 922 klassifiziert der Vorprozessor 114 jede dieser Änderungen entweder als kompatible oder als inkompatible Änderung. Eine inkompatible Änderung ist eine Änderung, die ein Rekompilieren der Kompiliereinheit erforderlich macht. Mit anderen Worten, wenn die ausgewählte Kopfdatei irgendwelche inkompatiblen Änderungen enthält, dann muß die Kompiliereinheit rekompiliert werden (d. h. solche Änderungen sind mit der Kompiliereinheit inkompatibel, so daß die Kompiliereinheit rekompiliert werden muß). Eine kompatible Änderung ist eine Änderung, die kein Rekompilieren der Kompiliereinheit erforderlich macht. Mit anderen Worten, wenn die ausgewählte Kopfdatei nur kompatible Änderungen und keine inkompatiblen Änderungen enthält, dann braucht die Kompiliereinheit nicht rekompiliert zu werden (d. h. solche Änderungen sind mit der Kompiliereinheit kompatibel, so daß keine Rekompilierung notwendig ist).
Was Änderungen als kompatibel bzw. inkompatibel charakterisiert, ist programmsprachenspezifisch. In der bekannten Computerprogrammiersprache C sind z. B. die folgenden Änderungen kompatibel: (1) Hinzufügen neuer Typen und neuer Vereinbarungen von externen Routinen oder Variablen; (2) Hinzufügen neuer Makros, die einen etwa vorhandenen Quellcode in irgendwelchen Quell- oder Einfügungsdateien nicht verändern; und (3) Formatierungsänderungen. Die obigen Änderungen repräsentieren im allgemeinen auch kompatible Änderungen für die bekannte Computerprogrammiersprache C++, In der Computerprogrammiersprache C sind, wie in vielen anderen Sprachen, die folgenden Änderungen inkompatibel: Hinzufügen eines Elements zu einem Satz oder zu einer Klasse (für objektorientierte Sprachen, wie z. B. C++), Löschen eines Elements aus einem Satz oder einer Klasse, Typänderung eines Elements eines Satzes oder einer Klasse, Hinzufügen einer neuen Variablen, Hinzufügen eines neuen Datentyps, Modifizieren eines vorhandenen Datentyps und Hinzufügen einer neuen Funktion. Weitere kompatible und inkompatible Änderungen für irgendeine spezielle Computerprogrammiersprache sind für den Fachmann offensichtlich.
Im Schritt 924 aktualisiert der Vorprozessor 114 den Vorsatz bzw. Kopf 604 (6) der neuen vorkompilierten Kopfdatei (erzeugt im Schritt 918) mit Statusinformationen, die sich auf die im Schritt 920 erkannten und im Schritt 922 klassifizierten Änderungen beziehen. Das bevorzugte Format des Kopfes 604 ist in 7 dargestellt. In einem ersten Feld 702 des Kopfes 604 speichert der Vorprozessor 114 vorzugsweise das Datum und die Uhrzeit der Erzeugung der neuen vorkompilierten Kopfdatei. Mit anderen Worten, der Vorprozessor 114 speichert in diesem ersten Feld 702 Datum und Uhrzeit der Ausführung des Schritts 918. In einem zweiten Feld 704 des Kopfes speichert der Vorprozessor 114 Datum und Uhrzeit der Ausführung der letzten kompatiblen Änderung. Wenn zum Beispiel die neue vorkompilierte Kopfdatei eine kompatible Änderung aufweist, dann werden Datum und Uhrzeit der Erzeugung der neuen vorkompilierten Kopfdatei (d. h. Datum und Uhrzeit der Ausführung des Schritts 918) im zweiten Feld 704 gespeichert. Wenn im anderen Falle die neue vorkompilierte Kopfdatei keine kompatible Änderung enthält, dann fragt der Vorprozessor 114 die Datum- und Uhrzeitinformation aus dem zweiten Feld 704 im Kopf 604 der alten vorkompilierten Kopfdatei ab und speichert diese Information im zweiten Feld 704 im Kopf 604 der neuen vorkompilierten Kopfdatei.
In einem dritten Feld 706 des Kopfes 604 speichert der Vorprozessor 114 Datum und Uhrzeit der Ausführung der letzten inkompatiblen Änderung. Wenn zum Beispiel die vorkompilierte Kopfdatei eine inkompatible Änderung aufweist, dann werden Datum und Uhrzeit der Erzeugung der neuen vorkompilierten Kopfdatei (d. h. Datum und Uhrzeit der Ausführung des Schritts 918) im dritten Feld 706 gespeichert. Wenn im anderen Fall die neue vorkompilierte Kopfdatei keine inkompatible Änderung aufweist, dann fragt der Vorprozessor 114 die Datum- und Uhr zeitinformation aus dem dritten Feld 706 im Kopf 604 der alten vorkompilierten Kopfdatei ab und speichert diese Information im dritten Feld 706 im Kopf 604 der neuen vorkompilierten Kopfdatei.
Im Schritt 926 stellt der Vorprozessor 114 fest, ob irgendwelche Änderungen im Schritt 922 als inkompatible Änderungen klassifiziert wurden. Wenn keine Änderungen als inkompatible Änderungen klassifiziert wurden, ist der Operationsablauf des Ablaufdiagramms 902 beendet, wie durch den Schritt 916 angezeigt. Wenn stattdessen eine oder mehrere Änderungen als inkompatible Änderungen klassifiziert wurden, dann wird der Schritt 928 ausgeführt. Im Schritt 928 setzt der Vorprozessor 114 das Rekompilierflag auf den logischen Wert "true" (wahr). Nach Ausführung des Schritts 928 ist der Operationsablauf des Ablaufdiagramms 902 beendet, wie durch den Schritt 916 angezeigt.
Wir nehmen nochmals Bezug auf Schritt 908. Wenn, wie oben erörtert, der Vorprozessor 114 im Schritt 908 feststellt, daß die vorkompilierte Kopfdatei, die der ausgewählten Kopfdatei entspricht, eine Anzahl vordefinierter Voraussetzungen erfüllt, dann wird der Schritt 910 ausgeführt.
Im Schritt 910 stellt der Vorprozessor 114 fest, ob die vorkompilierte Kopfdatei erstellt wurde, seit die Kompiliereinheit zuletzt kompiliert wurde. Wenn die Kopfdatei seit der letzten Kompilierung der Kompiliereinheit erstellt wurde, dann kann es notwendig sein, die Kompiliereinheit zu rekompilieren. Anderenfalls braucht die Kompiliereinheit nicht rekompiliert zu werden.
Betrachten wir zum Beispiel ein Musterzeitdiagramm 1302 in 13, und nehmen wir an, daß im Schritt 808 (8) die "a.h"-Kopfdatei 304 ausgewählt wurde. In diesem Zeitdiagramm 1302 wurden die "Haupt"-Quelldatei 202 und die "a.h"-Kopfdatei 304 (d. h. die ausgewählte Kopfdatei) zum Zeitpunkt t1 erstellt und zum Zeitpunkt t2 kompiliert. Folglich stellt der Zeitpunkt t2 den Zeitpunkt dar, zu dem die Kompiliereinheit zuletzt kompiliert wurde. Die "a.h"-Kopfdatei 304 wurde zum Zeitpunkt t3 modifiziert. Die vorkompilierte "a.x"-Kopfdatei 314 wurde zum Zeitpunkt t4 regeneriert. Der Vorprozessor 114 führt den Schritt 910 zum Zeitpunkt t5 aus. In diesem Musterzeitdiagramm 1302 würde der Vorprozessor 114 im Schritt 910 feststellen, daß die vorkompilierte "a.x"-Kopfdatei 314 seit der letzten Kompilierung der Kompiliereinheit (zum Zeitpunkt t2) erstellt wurde (zum Zeitpunkt t4).
Wenn der Vorprozessor 114 im Schritt 910 feststellt, daß die vorkompilierte Kopfdatei nicht seit der letzten Kompilierung der Kompiliereinheit erstellt wurde, dann ist der Operationsablauf des Ablaufdiagramms 902 beendet, wie durch den Schritt 916 angezeigt. Wenn stattdessen der Vorprozessor 114 feststellt, daß die vorkompilierte Kopfdatei seit der letztem Kompilierung der Kompiliereinheit erstellt wurde (wie im Zeitdiagramm 1302 von 13 dargestellt), dann wird der Schritt 912 ausgeführt.
Im Schritt 912 stellt der Vorprozessor 114 fest, ob seit der letzten Kompilierung der Kompiliereinheit nur kompatible Änderungen an der ausgewählten Kopfdatei ausgeführt worden sind. Diese Feststellung erfolgt anhand des Kopfes 604 (siehe 7) der zuletzt erzeugten, mit der ausgewählten Kopfdatei verbundenen vorkompilierten Kopfdatei. Wenn nur kompatible Änderungen ausgeführt worden sind (und keine inkompatiblen Änderungen vorgenommen worden sind), dann braucht die Kompiliereinheit nicht rekompiliert zu werden. Wenn stattdessen irgendwelche inkompatiblen Änderungen ausgeführt worden sind, dann muß die Kompiliereinheit rekompiliert werden.
Betrachten wir zum Beispiel ein Musterzeitdiagramm 1402, das in 14 dargestellt ist. Außerdem nehmen wir an, daß die "a.h"-Kopfdatei 304 im Schritt 808 (8) ausgewählt wurde. In diesem Zeitdiagramm 1402 wurden die "Haupt"-Quelldatei 202 und die "a.h"-Kopfdatei 304 (d. h. die ausgewählte Kopfdatei) zum Zeitpunkt t1 erstellt und zum Zeitpunkt t2 kompiliert. Die "a.h"-Kopfdatei 304 wurde zum Zeitpunkt t4 mit inkompatiblen Änderungen modifiziert. Die vorkompilierte "a.x"-Kopfdatei 314 wurde zum Zeitpunkt t5 regeneriert. Die "a.h"-Kopfdatei 304 wurde zum Zeitpunkt t7 nur mit kompatiblen Änderungen modifiziert, und die vorkompilierte "a.x"-Kopfdatei 314 wurde zum Zeitpunkt t8 regeneriert. Der Vorprozessor 114 führt zum Zeitpunkt t10 den Schritt 912 aus.
Die im Schritt 912 ausgeführte Analyse ist davon abhängig, wann die Kompiliereinheit zuletzt kompiliert wurde. Wenn die Kompiliereinheit zum Zeitpunkt t3 (oder vor dem Zeitpunkt t3, wie z. B. zum Zeitpunkt t2) zuletzt kompiliert wurde, dann muß die Kompiliereinheit rekompiliert werden. Dies ist der Fall, da seit der letzten Kompilierung der Kompiliereinheit (zum Zeitpunkt t3) an der "a.h"-Kopfdatei 304 eine oder mehrere inkompatible Änderungen ausgeführt worden sind (zum Zeitpunkt t4).
Wenn die Kompiliereinheit zum Zeitpunkt t6 zuletzt kompiliert wurde, dann braucht die Kompiliereinheit nicht rekompiliert zu werden. Dies ist der Fall, da seit der letzten Kompilierung der Kompiliereinheit (zum Zeitpunkt t6) an der "a.h"-Kopfdatei 304 nur kompatible Änderungen ausgeführt wurden (zum Zeitpunkt t7).
Wenn die Kompiliereinheit zum Zeitpunkt t9 zuletzt kompiliert wurde, dann braucht die Kompiliereinheit nicht rekompiliert zu werden. Dies ist der Fall, da die vorkompilierte "a.x"-Kopfdatei 314 zuletzt zum Zeitpunkt t8 erstellt wurde, und dieser liegt vor dem Zeitpunkt t9, als die Kompiliereinheit zuletzt kompiliert wurde (siehe Schritt 910).
Die obige Analyse des Zeitdiagramms 1402 wird in Tabelle 1502 zusammengefaßt, die in 15 dargestellt ist.
Wenn im Schritt 912 der Vorprozessor 114 feststellt, daß seit der letzten Kompilierung der Kompiliereinheit an der ausgewählten Kopfdatei nur kompatible Änderungen ausgeführt worden sind, dann ist der Operationsablauf des Ablaufdiagramms 902 beendet, wie durch den Schritt 916 angezeigt. Wenn stattdessen der Vorprozessor 114 feststellt, daß seit der letzten Kompilierung der Kompiliereinheit an der ausgewählten Kopfdatei eine oder mehrere inkompatible Änderungen ausgeführt worden sind, dann wird der Schritt 914 ausgeführt. Im Schritt 914 setzt der Vorprozessor 114 das Rekompilierflag. Nach Ausführung des Schritts 914 ist der Operationsablauf des Ablaufdiagramms 902 beendet, wie durch den Schritt 916 angezeigt.
Vorstehend sind zwar verschiedene Ausführungsformen der vorliegenden Erfindung beschrieben worden; es versteht sich aber, daß diese nur als Beispiele dargestellt wurden und keine Einschränkung bedeuten. Folglich sollten die Ausdehnung und der Schutzumfang der vorliegenden Erfindung nicht durch irgendeine der oben beschriebenen beispielhaften Ausführungsformen eingeschränkt, sondern nur gemäß den folgenden Patentansprüchen und deren Äquivalenten definiert werden.

Claims

Verfahren zum bedingten Rekompilieren einer Kompiliereinheit mit mehreren Quellcodebausteinen, mit den folgenden Schritten: (1) Auswahl eines der Quellcodebausteine; (2) Feststellen, ob eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß; (3) Erzeugen einer neuen verdichteten Darstellung des ausgewählten Quellcodebausteins in Abhängigkeit von der Feststellung im Schritt (2); und (4) Erkennung von Änderungen zwischen der neuen verdichteten Darstellung des ausgewählten Quellcodebausteins und einer alten verdichteten Darstellung des ausgewählten Quellcodebausteins; gekennzeichnet durch (5) Klassifikation jeder der Änderungen als kompatible Änderung bzw. inkompatible Änderung, wobei eine inkompatible Änderung eine Änderung ist, die ausgewählt ist aus der Gruppe bestehend aus (a) Hinzufügen eines Elements zu einem Satz oder zu einer Klasse, (b) Löschen eines Elements aus einem Satz oder einer Klasse, (c) Typänderung eines Elements eines Satzes oder einer Klasse, (d) Hinzufügen einer neuen Variablen, (e) Hinzufügen eines neuen Datentyps, (f) Modifizieren eines vorhandenen Datentyps und (g) Hinzufügen einer neuen Funktion, und eine kompatible Änderung eine Änderung ist, die ausgewählt ist aus der Gruppe bestehend aus (a) Hinzufügen neuer Vereinbarungen von externen Routinen oder Variablen, (b) Hinzufügen neuer Makros, die einen etwa vorhandenen Quellcode in irgendwelchen Quell- oder Einfügungsdateien nicht verändern, und (c) Formatierungsänderungen; und (6) Freigabe des Rekompilierens der Kompiliereinheit, wenn irgendeine der Änderungen als inkompatible Änderung klassifiziert wird.
Verfahren nach Anspruch 1, das ferner den folgenden Schritt aufweist: (7) Ausführen der Schritte (1)-(6) für jeden der Quellcodebausteine.
Verfahren nach Anspruch 1, wobei der Schritt (2) die folgenden Schritte aufweist: Feststellen, ob die alte verdichtete Darstellung älter ist als der ausgewählte Quellcodebaustein; und Entscheiden, daß eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß, wenn festgestellt wird, daß die alte verdichtete Darstellung älter ist als der ausgewählte Quellcodebaustein.
Verfahren nach Anspruch 1, wobei der Schritt (2) die folgenden Schritte aufweist: Feststellen, ob Makroanweisungen, die in dem ausgewählten Quellcodebaustein enthalten sind, sich seit der Erzeugung der alten verdichteten Darstellung verändert haben; und Entscheiden, daß eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß, wenn festgestellt wird, daß sich die Makroanweisungen seit der Erzeugung der alten verdichteten Darstellung verändert haben.
Verfahren nach Anspruch 1, wobei die Schritte (5) und (6) die folgenden Schritte aufweisen: Setzen eines mit der Kompiliereinheit verbundenen Rekompilierflags auf einen vordefinierten Wert, wenn irgendeine der Änderungen als inkompatible Änderung klassifiziert wird; und Freigabe der Kompilierung der Kompiliereinheit, wenn das Rekompilierflag auf den vordefinierten Wert gesetzt ist.
Verfahren nach Anspruch 1, das ferner die folgenden, zwischen den Schritten (1) und (2) ausgeführten Schritte aufweist: Feststellen, ob irgendwelche verdichteten Darstellungen des ausgewählten Quellcodebausteins existieren; Erzeugen einer verdichteten Darstellung des ausgewählten Quellcodebausteins, wenn festgestellt wird, daß keine verdichteten Darstellungen des ausgewählten Quellcodebausteins existieren; und Freigabe der Kompilierung der Kompiliereinheit.
Verfahren nach Anspruch 1, das ferner die folgenden Schritte aufweist, die ausgeführt werden, wenn im Schritt (2) festgestellt wird, daß keine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt zu werden braucht: Feststellen, ob die alte verdichtete Darstellung seit der letzten Kompilierung der Kompiliereinheit erzeugt wurde; wenn festgestellt wird, daß die alte verdichtete Darstellung seit der letzten Kompilierung der Kompiliereinheit erzeugt wurde, Feststellen, ob in der alten verdichteten Darstellung irgendwelche inkompatiblen Änderungen gegenüber einer älteren Version der alten verdichteten Darstellung existieren; und Freigabe der Kompilierung der Kompiliereinheit nur dann, wenn festgestellt wird, daß in der alten verdichteten Darstellung mindestens eine inkompatible Änderung vorhanden ist.
System zum bedingten Rekompilieren einer Kompiliereinheit mit mehreren Quellcodebausteinen, welches aufweist: eine Bausteinwähleinrichtung zum Auswählen eines der Quellcodebausteine; eine Bausteinerzeugungs-Entscheidungseinrichtung, um festzustellen, ob eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß; eine Erzeugungseinrichtung für verdichtete Darstellungen zum Erzeugen einer neuen verdichteten Darstellung des ausgewählten Quellcodebausteins in Abhängigkeit von der Entscheidung der Bausteinerzeugungs-Entscheidungseinrichtung; und eine Änderungserkennungseinrichtung zum Erkennen von Änderungen zwischen der neuen verdichteten Darstellung des ausgewählten Quellcodebausteins und einer alten verdichteten Darstellung des ausgewählten Quellcodebausteins; gekennzeichnet durch eine Änderungsklassifiziereinrichtung zum Klassifizieren jeder der Änderungen als kompatible bzw. inkompatible Änderung, wobei eine inkompatible Änderung eine Änderung ist, die ausgewählt ist aus der Gruppe bestehend aus (a) Hinzufügen eines Elements zu einem Satz oder zu einer Klasse, (b) Löschen eines Elements aus einem Satz oder einer Klasse, (c) Typänderung eines Elements eines Satzes oder einer Klasse, (d) Hinzufügen einer neuen Variablen, (e) Hinzufügen eines neuen Datentyps, (f) Modifizieren eines vorhandenen Datentyps und (g) Hinzufügen einer neuen Funktion, und eine kompatible Änderung eine Änderung ist, die ausgewählt ist aus der Gruppe bestehend aus (a) Hinzufügen neuer Vereinbarungen von externen Routinen oder Variablen, (b) Hinzufügen neuer Makros, die einen etwa vorhandenen Quellcode in irgendwelchen Quell- oder Einfügungsdateien nicht verändern, und (c) Formatierungsänderungen; und eine Kompilierungsfreigabeeinrichtung zur Freigabe einer Rekompilierung der Kompiliereinheit, wenn irgendeine der Änderungen als inkompatible Änderung klassifiziert wird.
System nach Anspruch 8, wobei die Bausteinerzeugungs-Entscheidungseinrichtung aufweist: eine Einrichtung zum Feststellen, ob die alte verdichtete Darstellung älter ist als der ausgewählte Quellcodebaustein; und eine Einrichtung zum Entscheiden, daß eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß, wenn festgestellt wird, daß die alte verdichtete Darstellung älter ist als der ausgewählte Quellcodebaustein.
System nach Anspruch 8, wobei die Bausteinerzeugungs-Entscheidungseinrichtung aufweist: eine Einrichtung zum Feststellen, ob Makroanweisungen, die in dem ausgewählten Quellcodebaustein enthalten sind, sich seit der Erzeugung der alten verdichteten Darstellung verändert haben; und eine Einrichtung zum Entscheiden, daß eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß, wenn festgestellt wird, daß sich die Makroanweisungen seit der Erzeugung der alten verdichteten Darstellung verändert haben.
System nach Anspruch 8, wobei die Änderungsklassifiziereinrichtung eine Einrichtung aufweist, um ein mit der Kompiliereinheit verbundenes Rekompilierflag auf einen vordefinierten Wert zu setzen, wenn irgendeine der Änderungen als inkompatible Änderung klassifiziert wird, und wobei die Kompilierungsfreigabeeinrichtung eine Einrichtung aufweist, um Kompilierung der Kompiliereinheit freizugeben, wenn das Rekompilierflag auf den vordefinierten Wert gesetzt ist.
System nach Anspruch 8, das ferner aufweist: eine Einrichtung zum Feststellen, ob eine verdichtete Darstellung des ausgewählten Quellcodebausteins existiert; eine Einrichtung zum Erzeugen einer verdichteten Darstellung des ausgewählten Quellcodebausteins, wenn festgestellt wird, daß keine verdichtete Darstellung des ausgewählten Quellcodebausteins existiert; und eine Einrichtung zur Freigabe der Kompilierung der Kompiliereinheit.
System nach Anspruch 8, das ferner aufweist: eine Einrichtung zum Feststellen, ob die alte verdichtete Darstellung des ausgewählten Quellcodebausteins seit der letzten Kompilierung der Kompiliereinheit erzeugt wurde, wenn durch die Bausteinerzeugungs-Entscheidungseinrichtung festgestellt wird, daß keine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt zu werden braucht; eine Einrichtung zum Feststellen, ob in der alten verdichteten Darstellung irgendwelche inkompatiblen Änderungen gegenüber einer älteren Version der alten verdichteten Darstellung existieren, wenn festgestellt wird, daß die alte verdichtete Darstellung seit der letzten Kompilierung der Kompiliereinheit erzeugt wurde; und eine Einrichtung, welche die Kompilierung der Kompiliereinheit nur dann freigeben soll, wenn festgestellt wird, daß in der alten verdichteten Darstellung mindestens eine inkompatible Änderung vorhanden ist.
Verfahren nach einem der Ansprüche 1 bis 7, das durchgeführt wird mit einem Kompilierer-Vorprozessor zum Feststellen, ob eine Kompiliereinheit mit mehreren Quellcodebausteinen rekompiliert werden muß, wobei der Vorprozessor aufweist: eine Bausteinwähleinrichtung zum Auswählen eines der Quellcodebausteine; eine Bausteinerzeugungs-Entscheidungseinrichtung zum Feststellen, ob eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß; eine Erzeugungseinrichtung für verdichtete Darstellungen zum Erzeugen einer neuen verdichteten Darstellung des ausgewählten Quellcodebausteins in Abhängigkeit von der Entscheidung der Bausteinerzeugungs-Entscheidungseinrichtung; und eine Änderungserkennungseinrichtung zum Erkennen von Änderungen zwischen der neuen verdichteten Darstellung des ausgewählten Quellcodebausteins und einer alten verdichteten Darstellung des ausgewählten Quellcodebausteins; gekennzeichnet durch eine Änderungsklassifiziereinrichtung zum Klassifizieren jeder der Änderungen als kompatible Änderung bzw. inkompatible Änderung, wobei eine inkompatible Änderung eine Änderung ist, die ausgewählt ist aus der Gruppe bestehend aus (a) Hinzufügen eines Elements zu einem Satz oder zu einer Klasse, (b) Löschen eines Elements aus einem Satz oder einer Klasse, (c) Typänderung eines Elements eines Satzes oder einer Klasse, (d) Hinzufügen einer neuen Variablen, (e) Hinzufügen eines neuen Datentyps, (f) Modifizieren eines vorhandenen Datentyps und (g) Hinzufügen einer neuen Funktion, und eine kompatible Änderung eine Änderung ist, die ausgewählt ist aus der Gruppe bestehend aus (a) Hinzufügen neuer Vereinbarungen von externen Routinen oder Variablen, (b) Hinzufügen neuer Makros, die einen etwa vorhandenen Quellcode in irgendwelchen Quell- oder Einfügungsdateien nicht verändern, und (c) Formatierungsänderungen; und eine Kompilierungsfreigabeeinrichtung zur Freigabe der Rekompilierung der Kompiliereinheit, wenn eine der Änderungen als inkompatible Änderung klassifiziert wird.
Verfahren nach Anspruch 14, wobei die Bausteinerzeugungs-Entscheidungseinrichtung aufweist: eine Einrichtung zum Feststellen, ob die alte verdichtete Darstellung älter ist als der ausgewählte Quellcodebaustein; und eine Einrichtung zum Entscheiden, daß eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß, wenn festgestellt wird, daß die alte verdichtete Darstellung älter ist als der ausgewählte Quellcodebaustein.
Verfahren nach Anspruch 14, wobei die Bausteinerzeugungs-Entscheidungseinrichtung aufweist: eine Einrichtung zum Feststellen, ob Makroanweisungen, die in dem ausgewählten Quellcodebaustein enthalten sind, sich seit der Erzeugung der alten verdichteten Darstellung verändert haben; und eine Einrichtung zum Entscheiden, daß eine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt werden muß, wenn festgestellt wird, daß sich die Makroanweisungen seit der Erzeugung der alten verdichteten Darstellung verändert haben.
Verfahren nach Anspruch 14, wobei die Änderungsklassifiziereinrichtung eine Einrichtung aufweist, die ein mit der Kompiliereinheit verbundenes Rekompilierflag auf einen vordefinierten Wert setzen soll, wenn eine der Änderungen als inkompatible Änderung klassifiziert wird, und wobei die Kompilierungsfreigabeeinrichtung eine Einrichtung aufweist, welche die Kompilierung der Kompiliereinheit freigeben soll, wenn das Rekompilierflag auf den vordefinierten ^Wert ^{gesetzt ist.}
Verfahren nach Anspruch 14, wobei der Kompilierer-Vorprozessor ferner aufweist: eine Einrichtung zum Feststellen, ob irgendeine verdichtete Darstellung des ausgewählten Quellcodebausteins existiert; eine Einrichtung zum Erzeugen einer verdichteten Darstellung des ausgewählten Quellcodebausteins, wenn festgestellt wird, daß keine verdichtete Darstellung des ausgewählten Quellcodebausteins existiert; und eine Einrichtung zur Freigabe der Kompilierung der Kompiliereinheit.
Verfahren nach Anspruch 14, wobei der Kompilierer-Vorprozessor ferner aufweist: eine Einrichtung zum Feststellen, ob die alte verdichtete Darstellung seit der letzten Kompilierung der Kompiliereinheit erzeugt wurde, wenn durch die Bausteinerzeugungs-Entscheidungseinrichtung festgestellt wird, daß keine neue verdichtete Darstellung des ausgewählten Quellcodebausteins erzeugt zu werden braucht; eine Einrichtung zum Feststellen, ob in der alten verdichteten Darstellung irgendeine inkompatible Änderung gegenüber einer älteren Version der alten verdichteten Darstellung existiert, wenn festgestellt wird, daß die alte verdichtete Darstellung seit der letzten Kompilierung der Kompiliereinheit erzeugt wurde; und eine Einrichtung, welche die Kompilierung der Kompiliereinheit nur dann freigeben soll, wenn festgestellt wird, daß in der alten verdichteten Darstellung mindestens eine inkompatible Änderung vorhanden ist.