DE19729603A1

DE19729603A1 - Fernkompilierung eines Quellencodes für eine Querentwicklung

Info

Publication number: DE19729603A1
Application number: DE19729603A
Authority: DE
Inventors: Gerald P Duggan; David J Staudacher
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1996-11-26
Filing date: 1997-07-10
Publication date: 1998-05-28
Also published as: GB2321731A; GB9725011D0; GB2321731B; US5881289A; JPH10161885A

Description

Diese Erfindung bezieht sich auf Computersysteme und insbe sondere auf das Kompilieren eines Quellencodes in derartigen Computersystemen. Spezieller bezieht sich die Erfindung auf das entfernte Kompilieren eines Quellencodes auf einem Ziel computer.

Software wird häufig unter Verwendung mehrerer Typen von Computersystemen entwickelt. Beispielsweise besitzen große Organisationen Mainframe-Computer, Workstation-Computer Ab teilungs-Server-Computer und Personalcomputer, die durch einzelne Personen in der Organisation verwendet werden. Ob wohl diese Mannigfaltigkeit eine enorme Flexibilität ermög licht, um Preis- und Verhaltens-Anforderungen für verschie dene Rechenfunktionen zu erfüllen, fügt dieselbe dem Anwen dungsentwicklungsprozeß eine Komplexität hinzu.

Viele Entwicklungsorganisationen benötigen ein Unix^TM-System auf dem Schreibtisch eines Ingenieurs zur Softwareentwick lung, und einen Personalcomputer auf dem gleichen Schreib tisch für Büroautomatisationsaufgaben. Dies verdoppelt die Kosten pro Ingenieur für die Organisation effektiv. Überdies müssen alle diese Computersysteme betreut werden, was die Anzahl der Betreuungstrainings- und Systemadministrations- Belegschaft, die von der Organisation benötigt wird, weiter erhöht. Dies erhöht ferner die Trainingsmenge für Entwick ler, die notwendig ist, um mehrere Entwicklungsumgebungen zu verwenden, und für die neue Technologie.

Bei bekannten Systemen existieren, wenn Software für ein spezielles Zielcomputersystem entwickelt werden muß, zwei Optionen. Die erste Option besteht darin, die Software auf dem Zielcomputersystem unter Verwendung existierender Text editoren, Kompiler usw. für das Zielcomputersystem zu ent wickeln. Dies funktioniert sehr gut, wenn der Code nur für ein Zielcomputersystem entwickelt wird. Wenn jedoch ein Code entwickelt werden muß, der auf mehreren Zielcomputersystemen läuft, ist es erforderlich, daß jedes dieser Computersysteme für den Entwickler zugreifbar ist. Für die effizienteste Verwendung der Entwicklerzeit muß jedes dieser Zielcomputer systeme ferner auf dem Schreibtisch des Entwicklers vorlie gen, was aufwendig und manchmal schwierig einzurichten ist.

Eine Schwierigkeit bei der Entwicklung auf mehreren unter schiedlichen Computersystemen besteht darin, daß der Ent wickler die Umgebung von jedem der Zielcomputersysteme ler nen muß. Dies ist zeitaufwendig, wobei, wenn ein Entwickler häufig zwischen unterschiedlichen Umgebungen wechselt, dies sehr verwirrend werden kann. Ferner muß der Quellencode für das Projekt ebenfalls zu jeder Umgebung bewegt werden, wobei dies in einigen Fällen schwierig oder unmöglich ist.

Eine zweite Option, die verfügbar ist, wenn ein Code für ein Zielcomputersystem entwickelt wird, besteht darin, einen Querkompiler zu verwenden, was ein Kompiler ist, der auf ei nem Computersystem arbeitet, jedoch einen ausführbaren Pro grammiercode für einen zweiten Computersystemtyp erzeugt. Dies kann die einzige Option sein, wenn das Zielcomputersy stem zu klein ist, um einen in demselben enthaltenen Editor oder Kompiler aufzuweisen. Wenn das Zielcomputersystem selbst ein größeres Computersystem ist, sind Querkompiler häufig nicht verfügbar, so daß diese Option nicht möglich ist.

In der Technik besteht ein Bedarf nach einem System, das die Entwicklung eines Codes auf einem Computersystem ermöglicht, während derselbe auf ein zweites Computersystem oder mehr als ein Computersystem abzielt. Es existiert ein weiterer Bedarf in der Technik nach einem solchen System, das den Co de, der kompiliert werden soll, zu dem Zielcomputersystem sendet, wodurch der Bedarf nach einem Querkompiler beseitigt ist. Ein weiterer Bedarf existiert nach einem System, das die Benutzerumgebung des Entwicklungscomputersystems beibe hält, während ein Code für mehr als ein Zielcomputersystem entwickelt wird. Die vorliegende Erfindung erfüllt diese und weitere Bedürfnisse auf dem Gebiet der Technik.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein flexibles Verfahren und eine flexible Vorrichtung zum Kompi lieren eines Codes auf einem Zielcomputersystem zu schaffen.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 und eine Vorrichtung gemäß Anspruch 5 gelöst.

Ein Vorteil der vorliegenden Erfindung besteht darin, einen Quellencode oder einen Verknüpfungsobjektcode, der auf einem Entwicklungscomputersystem entwickelt wird, entfernt auf ei nem Zielcomputersystem zu kompilieren.

Ein weiterer Vorteil der Erfindung besteht darin, Kompiler- oder Verknüpfer-Parameter aus der Entwicklungscomputersy stem-Syntax in die Zielcomputersystem-Syntax zu übersetzen.

Ein weiterer Vorteil der Erfindung besteht darin, Fehlermel dungen und Rückgabecodes, die durch den Zielcomputersystem- Kompiler und -Verknüpfer ausgegeben werden, in ein Format zu übersetzen, das auf dem Entwicklungscomputersystem verwend bar ist.

Die obigen und weitere Aspekte der Erfindung werden in einem System erreicht, das auf einem Entwicklungscomputersystem läuft und Befehle über ein Netzwerk zu einem Zielcomputer system sendet, um zu bewirken, daß das Zielcomputersystem einen Code kompiliert, der auf dem Entwicklungscomputersy stem entwickelt wurde. Das System ersetzt den Kompiler auf dem Entwicklungscomputersystem durch einen Laufkontrollab schnitt (RUNSTUB), der den Befehl unterbricht, um den Code auf dem Entwicklungscomputersystem zu kompilieren oder zu verknüpfen. Wenn der Code auf einem Zielcomputersystem kom piliert oder verknüpft werden soll, wandelt das System sämt liche Befehlszeilen-Kompiler- oder Verknüpfer-Parameter in ein neutrales Parameterformat um, sendet den umgewandelten Befehl über das Netzwerk zu dem Zielcomputersystem und wan delt dann den Befehl in ein Format um, das auf dem Zielcom putersystem verwendbar ist.

Wenn während des Kompilierens oder Verknüpfens Fehler er zeugt werden, wandelt das System die Fehlermeldungen, die durch den Kompiler oder Verknüpfer auf dem Zielcomputersy stem erzeugt werden, in ein neutrales Format um und nachfol gend in ein Format, das durch das Entwicklungscomputersystem verwendbar ist. Folglich führt ein Entwickler, der das Ent wicklungscomputersystem verwendet, das Kompilieren oder Ver knüpfen durch und empfängt Fehlermeldungen, als ob das Kom pilieren oder Verknüpfen auf dem Entwicklungscomputersystem durchgeführt werden würde, während tatsächlich das wirkliche Kompilieren oder Verknüpfen auf dem Zielcomputersystem durchgeführt wurde.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Zeich nungen näher erläutert. Es zeigen:

Fig. 1 ein Blockdiagramm des Entwicklungs- und des Ziel- Computersystems und die Verbindungen derselben;

Fig. 2 ein Flußdiagramm der Laufkontrollabschnittssoftware in dem Entwicklungscomputersystem;

Fig. 3 ein Flußdiagramm des Prozesses des Umwandelns von Parametern; und

Fig. 4 ein Flußdiagramm des Prozesses des Umwandelns von Fehlermeldungen.

Die folgende Beschreibung betrifft die gegenwärtig als am besten betrachtete Art des Durchführens der Erfindung. Diese Beschreibung soll nicht in einem begrenzenden Sinn verwendet werden, sondern dient lediglich dem Zweck der Beschreibung der allgemeinen Grundsätze der Erfindung. Der Bereich der Erfindung sollte durch Bezugnahme auf die beigefügten An sprüche bestimmt werden.

Fig. 1 zeigt ein Blockdiagramm des Entwicklungs- und des Ziel-Computersystems der vorliegenden Erfindung. Wie in Fig. 1 gezeigt ist, weist ein Entwicklungscomputersystem 102 eine Benutzerschnittstelle 104 auf, die die Software der Entwick lungsumgebung ist. Beispielsweise würde die Benutzerschnitt stelle 104 typischerweise einen Texteditor, einen Kompiler, einen Verknüpfer usw. aufweisen, d. h. das, was üblicherweise als eine integrierte Entwicklungsumgebung bezeichnet wird.

Die integrierte Entwicklungsumgebung Visuel C++ von Micro soft ist ein Beispiel einer integrierten Entwicklungsumge bung, die mit der vorliegenden Erfindung arbeitet. Microsoft Visual C++ verwendet ein Entwicklerstudio (Developer Studio) als eine Komponente, die Dateisammlungen und Kompilerein stellungen verwaltet. Wenn das Entwicklerstudio (Developer Studio) hochfährt, fährt dasselbe auf einem Arbeitsraum hoch, der aus einer Sammlung von Projekten besteht. Ein Pro jekt besteht aus einem einzelnen Satz von Dateien und einem Satz von einer oder mehreren Projektkonfigurationen. Benut zer können ohne weiteres Dateien unter Verwendung der gra phischen Benutzerschnittstellenmerkmale (GUI-Merkmale; GUI = graphical user interface) des Entwicklerstudios zu einem Projekt hinzufügen oder von demselben entfernen. Eine Konfi guration spezifiziert die Einstellungen des Kompilers, des Verknüpfers und eines Testers (Debugger), die die endgültige Ausgabe für einen Projektaufbau bestimmen. Diese Einstellun gen umfassen die Optimierung oder den Testpegel für den Kom piler, Bibliotheken, die durch den Verknüpfer (Linker) ge sucht werden sollen, Hochfahroptionen für das Programm, wenn dasselbe getestet wird, und viele andere Einstellungen. Der Benutzer muß eine einzelne Konfiguration für jeden speziel len Aufbau eines Projekts spezifizieren. Das Ändern einer Konfiguration ist eine einfache Art und Weise, eine neue Konfiguration aus einer Balkenliste (pull down list) von verfügbaren Konfigurationen auszuwählen. Das Erzeugen einer Konfiguration ist ähnlich einfach. In einer Konfiguration kann ein Benutzer das Zielcomputersystem, auf dem das Kompi lieren stattfinden soll, spezifizieren.

Unter Verwendung der Benutzerschnittstelle 104 erzeugt ein Entwickler eine Quellencodedatei, die auf einer Platte 106 gespeichert wird, die gemeinsam mit einem Zielcomputersystem 120 verwendet wird. Wenn der Benutzer der Benutzerschnitt stelle anzeigt, daß eine Kompilierung oder Verknüpfung stattfinden soll, ruft die Benutzerschnittstelle das Kompi ler- oder Verknüpfer-Programm, das in dem Entwicklungscompu tersystem enthalten ist, auf. Gemäß der vorliegenden Erfin dung wurden der Kompiler und der Verknüpfer jedoch in neue Namen umbenannt, wobei der ursprüngliche Kompiler/Verknüp fer-Name ebenfalls in RUNSTUB 108 (Laufkontrollabschnitt) umbenannt wurde, um die Kompilier- und Verknüpfungs-Befehle zu unterbrechen. Wenn die Benutzerschnittstelle 104 ver sucht, den Kompiler oder Verknüpfer aufzurufen, ruft daher das Entwicklungscomputersystem statt dessen RUNSTUB 108 auf. RUNSTUB 108 untersucht die Konfiguration, wobei, wenn der Code auf dem Zielcomputersystem kompiliert oder verknüpft werden soll, RUNSTUB 108 über ein Netzwerk mit einer Ziel schnittstelle 122 in dem Zielcomputersystem 120 kommuni ziert. Die Kommunikation über das Netzwerk 110 bewirkt, daß die Zielschnittstelle 122 einen Ziel-Kompiler oder -Verknüp fer 124 in dem Zielcomputersystem aufruft, um die Quelle, oder die Verknüpfungsobjekte, die in der Benutzerschnitt stelle 104 des Entwicklungscomputersystems 102 identifiziert ist oder sind, zu kompilieren.

Vor dem Aufrufen des Zielkompilers übersetzt RUNSTUB 108 al le Parameter aus dem Format des Entwicklungscomputersystems in ein neutrales Format und sendet die Neutralformatparame ter über das Netzwerk, wo die Zielschnittstelle 122 diesel ben aus dem neutralen Format in ein Format, das auf dem Zielcomputersystem 120 verwendbar ist, umwandelt. Fachleute auf dem Gebiet werden jedoch erkennen, daß entweder RUNSTUB 108 oder die Zielschnittstelle 122 die gesamte Übersetzung von dem Entwicklungssystemformat in das Zielsystemformat durchführen könnten.

Zusätzlich übersetzt RUNSTUB 108 Dateinamen, so daß der Zielkompiler 124 auf den Quellencode auf der Platte 106 über das Netzwerk 110 zugreifen kann.

Da der Zielkompiler 124 den Quellencode kompiliert, kann derselbe Fehlermeldungen und Rückgabecodes erzeugen, wobei diese durch das Netzwerk 110 übertragen werden. Die Ziel schnittstelle 122 übersetzt die Rückgabecodes oder Fehler meldungen in ein neutrales Format, wobei RUNSTUB 108 die Neutralformat-Fehlermeldungen in ein Format übersetzt, das durch die Benutzerschnittstelle 104 verwendbar ist. Auf die se Weise erscheint die Kompilierung als ob dieselbe auf dem Entwicklungscomputersystem kompiliert worden wäre, was für einen Benutzer des Entwicklungscomputersystems die bequemste Form ist.

Fig. 2 zeigt ein Flußdiagramm der RUNSTUB-Software 108. Be zugnehmend auf Fig. 2 erhält nach dem Eintritt ein Block 202 die Befehlszeilenparameter, die von der Benutzerschnittstel le 104 (Fig. 1) übertragen werden. Ein Block 204 bestimmt dann, ob die Befehlszeilenparameter einen Parameter aufwei sen, der anzeigt, wo der Zielaufbau stattfinden soll, wobei, wenn der Zielaufbau auf dem lokalen Computersystem stattfin den soll, der Block 204 die Steuerung zu einem Block 216 überträgt, der gemäß der Anforderung durch die Befehlszei lenparameter den lokalen Entwicklungs-Kompiler oder -Ver knüpfer aufruft.

Wenn der Aufbau auf dem Zielcomputersystem stattfinden soll, springt der Block 204 zu einem Block 206, der die Zielüber setzungsparametertabelle von der Platte 106 (Fig. 1) erhält und dann den Block 208, Fig. 3, aufruft, um die Befehlszei lenparameter in Parameter zu übersetzen, die durch das Ziel computersystem verwendbar sind. Nachdem die Befehlszeilenpa rameter übersetzt sind, übersetzt ein Block 210 den Dateina men derart, daß das Zielcomputersystem auf die Quelle und alle anderen Dateien, beispielsweise Einschluß- oder An fangsblock-Dateien, direkt von dem Entwicklungscomputersy stem zugreifen kann. Ein Block 212 sendet dann die Befehls zeile zu dem Zielcomputersystem, um die Kompilierung zu starten.

Während das Zielcomputersystem den Quellencode kompiliert, springt die Steuerung zu einem Block 218, der die Fehler wiedergewinnt, die durch den Zielkompiler 124 (Fig. 1) er zeugt werden. Ein Block 220 ruft dann Fig. 4 auf, um alle Fehler oder Rückgabecodes, die durch das Zielsystem erzeugt wurden, in ein Format zu übersetzen, das durch die Entwick lungsumgebung verwendbar ist, so daß dieselben durch die Be nutzerschnittstelle 104 angezeigt werden können.

Fig. 3 zeigt ein Flußdiagramm des Verfahrens zum Übersetzen von Befehlszeilenparametern, die von dem Block 208 von Fig. 2 aufgerufen werden. Wie in Fig. 3 gezeigt ist, erhält nach dem Eintritt ein Block 302 den ersten oder nächsten Befehl zeilenparameter, wobei ein Block 304 bestimmt, ob derselbe ein gemeinsamer Befehlszeilenparameter ist. Befehlszeilenpa rameter sind solche, die sowohl in dem Entwicklungscompu tersystem als auch dem Zielcomputersystem verfügbar sind, und folglich von dem Entwicklungscomputersystem-Format in das Zielcomputersystem-Format übersetzt werden müssen.

Die vorliegende Erfindung ermöglicht es jedoch, daß ein Be nutzer Befehlszeilenparameter einstellt, die nur auf einem speziellen Zielcomputersystem verfügbar sind. Da diese Para meter speziell für das Zielcomputersystem erzeugt werden, müssen dieselben nicht übersetzt werden. Bei der vorliegen den Erfindung werden, ausschließlich beispielsweise, diese Parametertypen außer Acht gelassen, indem dieselben in Dop pelklammern eingehüllt werden. Folglich werden die gemeinsa men Parameter dadurch bestimmt, ob dieselben von doppelten Klammern umgeben sind oder nicht.

Wenn der Parameter durch Doppelklammern umgeben ist, ist er kein gemeinsamer Parameter, so daß der Block 304 zu einem Block 312 springt, der die Doppelklammern von dem Parameter beseitigt und denselben direkt zu dem Ausgang sendet.

Wenn der Parameter ein gemeinsamer Parameter ist, springt der Block 304 zu einem Block 306, der den Parameter in ein System-neutrales Format umwandelt. Wenn der Entwicklungssy stemkompiler beispielsweise Microsoft Visual C++ ist, ist die Befehlzeilenoption, um normale Testinformationen (de bugging information) zu erzeugen, "/Zi". Die äquivalente Option für ein Zielcomputersystem, das einen Kompiler HP-UX C++ durchführt, "-g". Die vorliegende Erfindung wandelt die Testoption "/Zi" in das Wort "debug" als einem neutralen Format um, und wandelt nachfolgend den Neutralformatparame ter "debug" in "-g" um, wenn das Ziel HP-UX C++ ist. Wenn andererseits das Ziel ein Kompiler ANSI C++ sein soll, lau tet die Testoption (debug option) "-g0". In diesem Fall wür de die Erfindung den Neutralparameter "debug" in den Para meter "-g0" für die Verwendung durch den ANSI C++-Kompiler umwandeln.

Da die vorliegende Erfindung mit jeder Anzahl von Entwick lungscomputersystem-Benutzerschnittstellen arbeiten kann, ebenso wie mit jeder Anzahl von unterschiedlichen Zielcompu tersystem-Kompilern, reduziert die Verwendung des neutralen Formats den Codebetrag, der bei der Übersetzung der Parame ter anfällt, beträchtlich. Beispielsweise würde bei m unter schiedlichen Entwicklungscomputersystemen und n unterschied lichen Zielcomputersystemen das System ohne Verwendung des neutralen Formats m × n unterschiedliche Sätze von Überset zungscodes benötigen. Durch die Verwendung des neutralen Sy stemformats ändert die vorliegende Erfindung dies auf m + n, wodurch der Codebetrag beträchtlich reduziert wird.

Nach dem Umwandeln des Parameters in das neutrale Systemfor mat wandelt ein Block 308 das neutrale Systemformat in das spezielle Zielcomputersystem-Format um. Nach dem Umwandeln des Parameters, oder wenn der Parameter kein gemeinsamer Pa rameter war, springt die Steuerung zu einem Block 310, der bestimmt, ob weitere Parameter umgewandelt werden sollen, wobei, wenn dies der Fall ist, der Block 310 die Steuerung zu dem Block 302 zurückgibt, um den nächsten Parameter umzu wandeln. Nachdem alle Parameter umgewandelt wurden, springt der Block zu Fig. 2 zurück.

Fig. 4 zeigt das Flußdiagramm der Fehlerübersetzungsroutine, die durch den Block 220 von Fig. 2 aufgerufen wird. Wie in Fig. 4 gezeigt ist, erhält nach dem Eintritt ein Block 402 die erste oder die nächste Fehlermeldung, die umgewandelt werden soll. Der Block 404 extrahiert dann den Kompiler-Stu fennamen aus der Fehlermeldung, d. h. den Namen der speziel len Kompilerstufe, die den Fehler erzeugte. Beispielsweise könnte der Fehler durch einen Kompiler oder einen Verknüpfer oder einen Vorprozessor erzeugt worden sein. Nach dem Extra hieren des Kompilerstufennamens extrahiert dann ein Block 406 den Dateinamen der Quellendatei, die den Fehler bewirk te, während ein Block 408 die Zeilen- und Spalten-Nummer in der Datei, an der der Fehler auftrat, extrahiert. Ein Block 410 extrahiert dann den Fehlertyp, die Fehler-ID, beispiels weise eine interne Kennung, die der Kompiler verwendet, um den speziellen Fehlertyp zu identifizieren, wobei der Block 410 ferner den Fehlertext extrahiert, der zu dem Benutzer zurückgeleitet werden soll. Ein Block 412 erzeugt dann eine Neutralformat-Fehlermeldung aus den extrahierten Daten, auf die gleiche Art und Weise, auf die das neutrale Format ver wendet wird, um Befehlszeilenparameter umzuwandeln, wie oben beschrieben wurde. Ein Block 414 wandelt dann die Neutral format-Fehlermeldung in das Format um, das auf dem Entwick lungscomputersystem angenommen werden kann. Ein Block 416 bestimmt dann, ob weitere Fehlermeldungen, die umgewandelt werden sollen, existieren, wobei, wenn dies der Fall ist, die Steuerung zum Block 402 zurückspringt, um die nächste Fehlermeldung zu verarbeiten. Nachdem alle Fehlermeldungen verarbeitet wurden, springt der Block 416 zu Fig. 2 zurück.

Claims

1. Verfahren zum Kompilieren eines Codes auf einem Ziel computersystem (120), wobei der Code auf einem Entwick lungscomputersystem (102) entwickelt wurde, mit folgen den Schritten:

(a) Unterbrechen eines Kompilierbefehls auf dem Ent wicklungscomputersystem (202);
(b) Umwandeln der Kompilierparameter in ein Format, das auf dem Zielcomputersystem (208) verwendbar ist;
(c) Senden eines Kompilierbefehls (212) zu dem Ziel computersystem, um den Code zu kompilieren, wobei der Kompilierbefehl die Parameter enthält, die im Schritt (b) umgewandelt wurden;
(d) Umwandeln aller Fehlermeldungen (220), die auf dem Zielcomputersystem erzeugt werden, in ein Format, das auf dem Entwicklungscomputersystem verwendbar ist; und
(e) Anzeigen der Ergebnisse (108) der Kompilierung auf dem Entwicklungscomputersystem.

2. Verfahren gemäß Anspruch 1, bei dem der Schritt (b) ferner folgende Schritte aufweist:

(b1) Umwandeln (306) der Kompilierparameter in ein Computersystem-neutrales Format; und
(b2) Umwandeln (308) der Kompilierparameter aus dem Computersystem-neutralen Format in das Format, das auf dem Zielcomputersystem verwendbar ist.

3. Verfahren gemäß Anspruch 1 oder 2, bei dem der Schritt (d) ferner folgende Schritte aufweist:

(d1) Umwandeln (412) der Fehlermeldungen in ein Compu tersystem-neutrales Format; und
(d2) Umwandeln (414) der Fehlermeldungen aus dem Com putersystem-neutralen Format in das Format, das auf dem Entwicklungscomputersystem verwendbar ist.

4. Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem der Schritt (c) ferner folgenden Schritt aufweist:

(c1) wenn der Kompilierbefehl anzeigt, daß die Kompi lierung auf dem Entwicklungscomputersystem durch geführt werden soll, Aufrufen (216) eines Kompi lers auf dem Entwicklungscomputersystem, um den Quellencode zu kompilieren.

5. Eine Vorrichtung zum Kompilieren eines Codes auf einem Zielcomputersystem (120), wobei der Code auf einem Ent wicklungscomputersystem (102) entwickelt wurde, mit folgenden Merkmalen:
einem Übersetzungssystem (108) zum Unterbrechen eines Kompilierbefehls auf dem Entwicklungscomputersystem (102) und zum Umwandeln von Kompilierparametern in ein Format, das auf dem Zielcomputersystem (120) verwendbar ist;
einem Computersystemnetzwerk (110) zum Senden eines Kompilierbefehls zu dem Zielcomputersystem (120), um den Quellencode zu kompilieren, wobei der Kompilierbe fehl die Parameter enthält, die durch das Übersetzungs system (108) umgewandelt wurden;
einer Einrichtung in dem Übersetzungssystem (108) zum Umwandeln aller Fehlermeldungen, die durch die Ausfüh rung des Kompilierbefehls auf dem Zielcomputersystem erzeugt werden, in ein Format, das auf dem Entwick lungscomputersystem (102) verwendbar ist; und
einem Anzeigesystem zum Anzeigen der Ergebnisse des Kompilierens auf dem Entwicklungscomputersystem (102).

6. Vorrichtung gemäß Anspruch 5, bei dem die Umwandlungs einrichtung in dem Übersetzungssystem ferner folgende Merkmale aufweist:
eine Einrichtung (306) zum Umwandeln der Kompilierpara meter in ein Computersystem-neutrales Format; und
eine Einrichtung (308) zum Umwandeln der Kompilierpara meter aus dem Computersystem-neutralen Format in das Format, das auf dem Zielcomputersystem verwendbar ist.

7. Vorrichtung gemäß Anspruch 5 oder 6, bei dem das Über setzungssystem ferner folgende Merkmale aufweist:
eine Einrichtung (412) zum Umwandeln der Fehlermeldun gen in ein Computersystem-neutrales Format; und
eine Einrichtung (414) zum Umwandeln der Fehlermeldun gen aus dem Computersystem-neutralen Format in das For mat, das auf dem Entwicklungscomputersystem (102) ver wendbar ist.