\chapter{Werkzeuge zu M2Amiga}

\thispagestyle{empty}
\section{Das Projekt-Konzept}

\label{project}
Im Allgemeinen wird ein gr"osseres \mtwo-Programm aus mehreren
Moduln bestehen. Jedes Modul umfasst seinerseits mehrere Dateien,
wie Text\-dateien\footnote{Definitions-, Implementations- oder Programm-Modul},
die Symboldateien, die Referenzdateien und schliesslich die 
gelinkten Amiga-Programme.

Entwickelt man nun diverse \mtwo-Programme, ergeben sich schnell
eine grosse Anzahl Dateien, die --- ohne besondere Vorkehrungen ---
un"ubersichtlich auf der Diskette oder der Festplatte verteilt sind.
Man verliert somit schnell die "Ubersicht, welche Dateien zu welchem
Modul geh"oren und welche Moduln zu welchen \mtwo-Programm geh"oren.

Das Betriebssystem bietet uns schon eine M"oglichkeit an,
um auf der Diskette oder der Festplatte eine "ubersichtliche
Anordnung mehrerer Dateien vornehmen zu k"onnen: die
{\bf Verzeichnisse} und die dortigen Unterverzeichnisse
("'directories"' oder "'drawers"'). Wir nutzen diese
M"oglichkeit und bauen sie zu einem eigentlichen Konzept aus:
dem {\bf Projekt-Konzept}. Es gen"ugt n"amlich nicht, wenn Sie
als Benutzer einfach Ihre Ordnung auf dem externen Speicher
vornehmen, die Programme von \mtwoamiga --- Compiler, Linker,
Make, Debugger usw.\ --- Ihre Anordnung der Dateien aber
unber"ucksichtigt lassen.

Wenn Sie ein \mtwo-Programm entwickeln --- nehmen wir als Beispiel
gerade den Compiler selbst --- kann man dieses Vorhaben als Projekt
bezeichnen. Zu diesem Projekt geh"oren diverse Moduln. Um bei
unserem Beispiel des Compilers zu bleiben, gibt es sicher
ein Modul, das den Text einliest und die Syntax pr"uft (Scanner),
ein Modul, das die Semantik "uberpr"uft (Parser), und ein drittes
Modul schliesslich erzeugt den Code (Generator). All diese Dateien
geh"oren logisch zusammen und werden demzufolge in einem Verzeichnis
zusammengefasst. Somit kann man folgendes festhalten:
\begin{quote}
"`Ein Projekt entspricht einem Verzeichnis"'
\end{quote}

\subsection{Details zum Projekt}

Bis jetzt ist noch nichts Spektakul"ares an diesem Konzept
zu erkennen. Es liegt auf der Hand, alle zusammengeh"orenden
Moduln in einem eigenen Verzeichnis abzulegen. Wir haben
aber vorher gesehen, dass es viele verschiedene Typen
von Dateien gibt. Sie unterscheiden sich durch spezifische
Endungen:

\begin{ttscript}{.sym}
\item[.def]
  Textdatei eines Definitions-Moduls
\item[.mod]
  Textdatei eines Implementations- oder Programm-Moduls
\item[.sym]
  "ubersetztes Definitions-Modul
\item[.obj]
  "ubersetztes Implementations- oder Programm-Modul, compiliert
  f"ur MC68000
\item[.ob{\cmsltt n}]
  "ubersetztes Implementations- oder Programm-Modul, je
  nach Endung f"ur einen h"oheren Prozessor der MC68000-Familie
  compiliert. M"ogliche Endungen sind {\tt ob1}, {\tt ob2},
  {\tt ob3}, {\tt ob4} und schliesslich {\tt ob8}.
\item[.ref]
  Datei, welche die Debuggerinformation enth"alt
\item[~]
  die Datei des gelinkten Programms hat keine Endung.
\end{ttscript}

Schaut man sich ein Projektverzeichnis mit dem Befehl
{\tt dir} des Betriebssystems an, stehen aber nicht alle Dateien
gleichen Typs beieinander, sondern man findet alle Dateien, die zu
einem Modul geh"oren, alphabetisch aufgelistet. In unserem 
Beispiel des Compilers sieht das Projektverzeichnis folgendendermassen
aus:

\pagebreak[3]
\begin{verbatim}
1> dir
  Compiler            Compiler.mod
  Compiler.obj        Compiler.ref
  Generator.def       Generator.mod
  Generator.obj       Generator.ref
  Generator.sym       Parser.def
  Parser.mod          Parser.obj
  Parser.ref          Parser.sym
  Scanner.def         Scanner.mod
  Scanner.obj         Scanner.ref
  Scanner.sym
\end{verbatim}

Die Liste ist zwar alphabetisch, aber bereits diese vier Moduln
ergeben eine recht lange Liste; dabei sind gar keine Versionen f"ur h"ohere
Prozessoren vorhanden. Oftmals w"are es besser, wenn
man alle Dateien des gleichen Typs beieinander h"atte. Um dies zu
erreichen, kann man das Projektverzeichnis mit Unterverzeichnissen weiter
unterteilen. Unser Projektkonzept erkennt Unterverzeichnisse
mit folgenden Namen:

\begin{ttscript}{xxx}
\item[bin]
  Dieses Verzeichnis enth"alt alle fertig gelinkten Amiga-Programme.
\item[obj]
  Wie der Name schon sagt, befinden sich hier alle
  Objektdateien. Alle Objektdateien werden {\em unabh"angig\/}
  von der Prozessorversion hierin abgelegt.
\item[ref]
  Hier befinden sich alle Referenzdateien.
\item[sym]
  Hier sind alle Symboldateien zu finden.
\item[txt]
  Schliesslich sind hier alle Programmtexte abgelegt,
  d.h.\ die "`{\tt .def}"'- und "`{\tt .mod}"'-Dateien.
\end{ttscript}

Wichtig ist, dass es {\em nicht\/} zwingend ist, mit diesen
Unterverzeichnissen zu arbeiten. Man kann sie einrichten, wenn
man sie m"ochte; man kann aber auch alle oder einen Teil davon
weglassen. Wenn man aber ein Unterverzeichnis eingerichtet hat,
muss man es benutzen. Das heisst, dass bei einem vorhandenen
Unterverzeichnis "`{\tt txt}"' {\em alle\/} Programmquellen in diesem
abgelegt werden {\em m"ussen}. Existiert also ein Unterverzeichnis
"`{\tt txt}"', werden alle Texte, die direkt im Projektverzeichnis
abgelegt sind, von allen \mtwoamiga-Programmen ignoriert.

\begin{figure}
\begin{center}
\unitlength0.5cm
\begin{picture}(16,10)
\put(5,5){\framebox(5,4){Compiler}}
\put(5,8){\framebox(3,1){\bf Projekt}}
\multiput(0,0)(4,0){4}{\framebox(3,2){}}
\put(0,1){\framebox(2,1){\bf txt}}
  \put(4,1){\framebox(2,1){\bf sym}}
  \put(8,1){\framebox(2,1){\bf obj}}
  \put(12,1){\framebox(2,1){\bf ref}}
\put(1.5,2){\line(3,2){4.45}}
\put(5.5,2){\line(1,2){1.45}}
\put(9.5,2){\line(-1,2){1.45}}
\put(13.5,2){\line(-3,2){4.45}}
\end{picture}
\caption{\label{ExProject} Beispiel eines Projekts}
\end{center}
\end{figure}

Das Beispielprojekt k"onnte also aussehen wie in Abbildung
\ref{ExProject}.

Hierbei wurde das "`{\tt bin}"'-Unterverzeichnis weggelassen,
so dass sich das voll"-st"an\-dig gelinkte Programm "`Compiler"'
direkt im Projektverzeichnis befindet.

\subsection[Die Suchstrategie]%
{Zusammenspiel der Projekte: die Suchstrategie}

Es k"onnen aber auch Dateien aus anderen Projekten
importiert werden. Daf"ur gibt es {\bf Pfaddateien}. Pfaddateien
sind normale Textdateien, die auf jeder Zeile einen Projektnamen
angeben. Es gibt eine {\bf lokale Pfaddatei}, sowie
eine {\bf globale Pfaddatei}.
Der Name einer Pfaddatei ist "`{\bf path}"'. Die lokale
Pfaddatei ist im Projektverzeichnis, die globale befindet
sich im "`{\tt M2:}"'-Verzeichnis. Die Suche geht folgendermassen vor:
zuerst werden das aktuelle Projekt, danach die Projekte der
lokalen Pfaddatei und schliesslich die Projekte der globalen
Pfaddatei durchsucht.

Zu beachten ist, dass in den Pfaddateien nicht etwa
Unterverzeichnisse aufgez"ahlt werden, sondern Projekte.
In diesen Projekten gelten die selben Suchregeln bez"uglich
der Unterverzeichnisse ({\tt txt}, {\tt sym}, {\tt obj},
{\tt ref}, {\tt bin}) wie im aktuellen Projekt.

Meistens gen"ugt die globale Pfaddatei, und man muss keine lokalen
Pfaddateien definieren. Ein Beispiel einer globalen Pfaddatei:

\begin{verbatim}
M2:Modules
Arbeits-Disk:Bibliothek
Arbeits-Disk:AnderesProjekt
\end{verbatim}

Wird eine ben"otigte Symboldatei im aktuellen Projekt
nicht gefunden, wird zuerst im Verzeichnis "`{\tt M2:Modules}"'
nachgeschaut. Ist dort ein Unterverzeichnis "`{\tt sym}"'
vorhanden, wird in diesem gesucht, sonst im Verzeichnis
selbst. Wurde die Datei nicht gefunden, geht die Suche
bei den beiden folgenden Verzeichnissen analog weiter.
Erst wenn sie auch dort nicht vorhanden ist, wird eine
Fehlermeldung ausgegeben.

Es empfiehlt sich, eigene Moduln, die kaum oder gar nicht mehr
ge"andert werden, in einem Projekt der {\em globalen\/}
Pfaddatei abzulegen. Dies hat sicher den Vorteil des immerw"ahrenden
Zugriffs --- auch bei neu kreierten Projekten, die noch
ohne lokale Pfaddatei sind.

\section{Programmaufruf und -bedienung}

\label{refBedien}
Alle Programme des M2Amiga-Systems sind mit einer einheitlichen
Benutzerschnittstelle versehen. Wenn Sie den Bedienungsmechanismus
eines Programmes kennen, wissen Sie auch, wie die anderen
Programme zu bedienen sind. Falls Sie diese Schnittstelle sch"atzen,
empfehlen wir Ihnen, alle eigenen Programme mit der gleichen
Schnittstelle zu versehen. Verwenden Sie dazu das im Kapitel
"`Moduln zu M2Amiga"'
beschriebene Modul "`Arguments"' (Seite \pageref{Arguments}).

Alle Programme k"onnen mit Hilfe des CLI-Kommandos "'{\bf Resident}"'
in den Speicher geladen werden.
Ausserdem sind sie sowohl von der SHELL, dem CLI, als auch von der
Workbench aufrufbar. Programme k"onnen --- wenn sie nicht gerade
auf Benutzer-Eingaben warten --- durch \keyctrl[C] abgebrochen werden.

Jedes M2Amiga-Programm akzeptiert als Parameter eine beliebige
Mischung
von Optionen und Dateinamen. Die Dateinamen k"onnen entweder vollst"andig
mit Pfad und Endung, oder auch nur als blosse Modulnamen
angegeben werden. Ist das Modul im aktuellen Projekt oder entlang
des \mtwo-Pfads vorhanden,
wird die zugeh"orige Datei automatisch gefunden.

Die Programme kennen die Endungen der Dateien, die sie verarbeiten. Sie
muss daher normalerweise nicht mit angegeben werden. Lediglich der Compiler
liest zwei verschiedene Datei-Typen: solche mit der Endung
"`{\tt .def}"' und solche mit der Endung "`{\tt .mod}"'.
Der Compiler nimmt eine Endung "`{\tt mod}"' an, d.h.\ nur f"ur
die "Ubersetzung eines
Definitionsmoduls m"ussen Sie die Endung mit angeben,
sonst nicht.

\begin{example}
Beispiele f"ur gleichwertige Aufrufe an Compiler und Linker,
wobei die Unterverzeichnisse "`{\tt txt}"' und "`{\tt obj}"'
vorhanden sind:

\begin{alltt}
  m2c modul
  m2c txt/modul
  m2c txt/modul.mod
  m2l datei
  m2l obj/datei
  m2l obj/datei.obj
\end{alltt}
\end{example}

Der Editor kann sich nicht im gleichen Masse auf das Projektkonzept
abst"utzen, da er beliebige Textdateien aller Art verarbeiten
muss.

\subsection{Optionen}

Die Arbeitsweise eines Programmes kann mit Hilfe von {\bf Optionen} (Schaltern)
beeinflusst werden. Optionen bestehen aus einzelnen f"ur das Programm
spezifischen 
Buchstaben oder  Ziffern. Sie werden immer mit den Zeichen "`{\tt +}"'
oder "`{\tt -}"' eingeleitet.

Optionen, die echte "`{\bf Schalter}"' sind, werden mit
"`{\tt +}"' gesetzt und mit
"`{\tt -}"' gel"oscht. F"ur diese ist der Name Schalter in direkter
Analogie zu \mbox{Ein-/}""Aus-Schaltern zu verstehen.

Zus"atzlich gibt es Optionen, die ihrerseits ein Argument erfordern,
z.B.\ einen Datei- oder Verzeichnisnamen oder eine Zahl. Dieses
Argument muss direkt
an den Buchstaben der Option anschliessen, also ohne
Trennung durch Leerzeichen. Option und Argument m"ussen mit einem Leerzeichen
oder dem Zeilenende abgeschlossen sein. Bei diesen Optionen dienen
"`{\tt +}"' und "`{\tt -}"'
lediglich als Kennzeichnung einer Option und sind gleichwertig.
Die Ausnahme, welche  die Regel best"atigt, ist
beim Compiler zu finden.
 
Parameterlose Optionen --- echte Schalter --- k"onnen zusammengefasst
werden, nach einer
Option mit Parametern muss jedoch ein Leerzeichen folgen.

Einige Optionen gelten f"ur alle folgenden Operationen oder bis
zur n"ach"-sten "Anderung. Andere gelten nur f"ur die
n"achstfolgende Datei. Das genaue Verhalten
ist bei den einzelnen Programmen beschrieben.

Jedes Programm definiert seine eigenen Options-Buchstaben. Der
Buchstabe "`{\tt q}"' steht jedoch einheitlich f"ur "'quiet"' (korrekt
ausgedr"uckt f"ur "'ver\-bose"', weil "`{\tt -q}"' zus"atzliche Meldungen
{\em unterdr"uckt\/}), der Buchstabe "`{\tt i}"' f"ur die
{\bf Ikonen-Erzeugung}.
Die Standardeinstellung f"ur die Ikonen-Er\-zeu\-gung wird so gew"ahlt,
dass beim Start von der Workbench Ikonen erzeugt werden und
beim Start vom CLI keine.

\subsubsection{Wechsel des Verzeichnisses}

Compiler und Linker bieten als Option den Wechsel des aktuellen
Verzeichnisses, der sowohl in der Kommandozeile als auch interaktiv
angegeben werden kann. Eingeleitet wird der Wechsel durch "`{\tt +g}"'
oder "`{\tt -g}"', direkt gefolgt
vom Namen des Verzeichnisses. Nach dem Befehl "`{\tt -g/tools}"' "andert
sich beispielsweise der Prompt von "`\verb|() m2c >|"' zu
 "`\verb|(/tools) m2c >|"'.
Wird die Option ohne Namen angegeben, so wechselt das Programm
wieder in das urspr"ungliche Verzeichnis, das beim Aufruf des Werkzeuges
das aktuelle war.

Falls man sich in einem Unterverzeichnis eine Projektes befindet
(z.B.\ in "`{\tt tools/obj}"'),
gehen die Programme vor dem Start einer Bearbeitung automatisch
in das Projektverzeichnis (in diesem Beispiel nach "`{\tt tools}"') und
nach Beendigung der Operation wieder zur"uck in das alte Verzeichnis.

Seien Sie deshalb nicht irritiert, wenn der Linker
bei einer Bearbeitung
beispielsweise "`{\tt -obj/Demo.obj}"'
ausgibt, obwohl es korrekt "`{\tt -Demo.obj}"' hiesse.

\begin{example}
Einige Beispiele:
\begin{quote} \tt befehl -i +x +l\cmsltt Name\/ \tt +b \end{quote} 
ist gleichwertig mit
\begin{quote} \tt befehl -i+xl\cmsltt Name\/ \tt +b \end{quote} 
Der Aufruf
\begin{quote} \tt befehl \cmsltt datei1\/ \tt -x -l\cmsltt name datei2\/
  \tt -r \cmsltt datei3 \end{quote} 
bearbeitet {\cmsltt datei1\/} mit den Standard-Optionen,
l"oscht daraufhin die Option {\tt x},
besetzt die Option {\tt l} mit dem Wert "`{\cmsltt name}"',
bearbeitet {\cmsltt datei2}, l"oscht die Option
{\tt r} und bearbeitet {\cmsltt datei3}.

\end{example}

Die Angabe von Optionen beim Start von der Workbench ist 
schwierig und nur durch Tricks\footnote{Ikonen, deren Namen mit
"`{\tt +}"' oder "`{\tt -}"' beginnen} zu erreichen.
Der einfachste Weg ist das interaktive
Aufstarten ohne Argumente oder die Nutzung der Umgebungsvariablen.

\subsection{Umgebungsvariablen (ENV:)}

Jedes Programm besitzt eine {\bf Standardeinstellung} oder {\bf Vorgabe}
seiner Optionen. Da
diese nicht allen W"unschen gerecht werden kann, bieten die Programme
die M"oglichkeit, mit Hilfe einer {\bf Umgebungsvariablen} eine neue
Standardeinstellung vorzugeben.

Hierzu muss das logische Ger"at "`{\tt ENV:}"' vorhanden sein.
Dieses muss durch einen
{\bf Assign}-Befehl
erzeugt werden, beispielsweise durch
"`{\tt Assign ENV: RAM:env}"'. 
In der Datei "`{\tt s:Startup-Sequence}"'
bzw.\ "`{\tt s:StartupII}"'\footnote{Je nach
Version AmigaDOS 2.0 oder AmigaDOS 1.3} sollte dieser
Befehl schon enthalten sein.

Jedes Programm sucht beim Start in "`{\tt ENV:\cmsltt programmname\/}"'
nach seinen Einstellungen. Dabei ist "`{\cmsltt programmname}"'
jeweils durch den Namen des Programmes zu ersetzen.

Diese Einstellungen m"ussen in Form einer einzigen Textzeile vorliegen und
die Optionen in der Art enthalten, wie sie von der Kommandozeile angegeben
werden. Sollte die Datei, bzw.\ Umgebungsvariable, nicht vorhanden
sein, geschieht gar nichts. Andernfalls werden die darin enthaltenen
Optionen ausgewertet und auf dem Bildschirm angezeigt.

Zum Festlegen dieser Optionen benutzt man
am besten den {\bf SetEnv}-Befehl.

\subsection{Projektspezifische Einstellungen ({\cmsltt tool\tt.opt})}

Die Umgebungsvariablen erm"oglichen eine pers"onliche Vorgabe
der Optionen. Diese Vorgabe gilt f"ur alle Werkzeuge von
\mtwoamiga.

Nun sind allerdings auch projektspezifische Einstellungen der
Optionen denkbar. Gewisse Programme sollen vielleicht immer
alle Laufzeitpr"ufungen durchf"uhren, andere k"onnen gut
auf solche verzichten. Dieses spezifische Verhalten ist mit
den Umgebungsvariablen nicht m"oglich.

Alle Werkzeuge von \mtwoamiga\ lesen beim Start {\em nach\/} der
entsprechenden Umgebungsvariable die Datei
"`{\cmsltt programmname\tt.opt}"'.
Diese Datei wird im aktuellen Projekt gesucht, von dem das
Werkzeug gestartet wurde. Und "`{\cmsltt programmname\/}"' ergibt
sich wiederum aus dem gestarteten Programm.

\begin{example}
So belegt "`{\tt SetEnv m2c -1nzh+y}"' die Standardeinstellung
des Compilers. Ben"otigen die Programme eines Projektes
in jedem Fall die Option "`{\tt +n}"', muss die Datei
"`{\tt m2c.opt}"' im Projektverzeichnis die Zeichenkette
"`{\tt +n}"' enthalten.%
\footnote{Selbstverst"andlich auf der ersten Zeile, die als
einzige ber"ucksichtigt wird.}
Sollte man nun ausnahmsweise f"ur dieses Projekt
doch einmal die Option "`{\tt -n}"'
w"unschen, gibt man diese einfach auf der Kommandozeile an.
F"ur die sich ergebende Kombination, die "`{\tt -n}"', 
"`{\tt +n}"' und "`{\tt -n}"' 
enth"alt, ist die {\em letzte\/} Einstellung "`{\tt -n}"' g"ultig.
\end{example}

\subsection{Der interaktive Modus}

Wird beim Starten des Programmes kein Dateiname angegeben,
geht das Programm automatisch in den sogenannten {\bf interaktiven Modus}.
Dies geschieht auch,  falls bei der Bearbeitung einer Datei ein Fehler
auftritt. Die Angabe von Optionen "andert dieses Verhalten nicht.
Ausnahme bildet hier einzig die Option "`-q"', die den Wechsel
in den interaktiven Modus ausdr"ucklich unterbindet. Das
erm"oglicht ein problemloses Einbinden von Compiler-
und Linker-Aufrufen auch in Batch-Dateien.

Im interaktiven Modus erscheint auf dem Bildschirm ein Prompt,
der das aktuelle Verzeichnis und den Programmnamen angibt
(\hbox{"`{\tt () m2c> }"'}). Hier k"onnen Sie Optionen oder Dateinamen
gleich wie in der Kommandozeile eingeben, auch mehrere in einer Zeile.
Der interaktive Modus wie auch das Programm werden durch die Eingabe einer
Leerzeile beendet.

\subsection{Hilfe}

Durch die Eingabe eines "`{\tt ?}"' kann jederzeit Hilfe verlangt werden.
Dabei werden der Name und die Version des Programmes sowie die
Aufrufsyntax angezeigt.

Einige Programme bieten auch die M"oglichkeit, durch die Eingabe von
zwei aufeinanderfolgenden Fragezeichen ("`{\tt ??}"') ausf"uhrlichere
Hilfe und Statusinformationen zu erlangen.

\subsection{ARexx-Schnittstelle}

\label{ARexx}
Compiler, Linker und das Programm {\tt m2pool}
besitzen eine einfache Schnittstelle zu {\bf ARexx}.
ARexx ist eine Programmiersprache, die unter dem Namen
{\bf REXX} (\cite{REXX}, deutsch \cite{REXX-d}) auf sehr vielen
Systemen Verbreitung gefunden hat und von William S. Hawes erweitert
und an den Amiga angepasst wurde. Hier soll keine Erkl"arung zu ARexx erfolgen.
N"aheres kann man in \cite{ARexx} nachlesen.

{\tt m2l} und {\tt m2c} stellen je einen gleichnamigen Port in
Grossschreibung zur Verf"ugung, also
\begin{quote} {\tt M2C} und {\tt M2L}. \end{quote}
An diese Ports k"onnen von ARexx-Programmen dann Meldungen geschickt werden,
wenn sich die Programme im interaktiven Modus befinden.

\medskip\noindent
Der Compiler kennt die Kommandos
\begin{ttscript}{COMPILE Arg}
\item[QUIT] beendet den Compiler.
\item[COMPILE \cmsltt Arg] Das Argument "`{\cmsltt Arg}"' enth"alt eine 
Zeichenkette, die einem Aufruf
von der Kommandozeile oder interaktiv entspricht.
Es besteht also aus beliebig vielen Optionen und Dateinamen. Es sollte
jedoch
immer nur eine Datei gleichzeitig kompiliert werden, damit im Fehlerfall
die Quelle lokalisierbar ist.
\end{ttscript}

\medskip\noindent
Der Linker kennt die Kommandos
\begin{ttscript}{COMPILE Arg}
\item[QUIT] beendet den Linker. 
\item[LINK {\cmsltt Arg}] Das Argument "`{\cmsltt Arg}"' enth"alt die
Parameter, wie sie vom Aufruf
von der Kommandozeile oder interaktiv her bekannt sind,
bestehend aus beliebig vielen Optionen und Dateinamen.
\end{ttscript}

\medskip\noindent
Alle Kommandos k"onnen gross oder klein geschrieben sein.
Die
{\bf R"uckgabewerte}
sind im nachfolgenden Unterabschnitt beschrieben.

\begin{example}
\medskip\noindent
Das folgende Beispiel zeigt ein einfaches ARexx-Programm. Es versucht,
das angegebene Modul zu kompilieren und anschliessend zu linken.

\begin{verbatim}
/*
 *  CompLink.rexx
 *  usage: complink name [compopts [linkopts]]
 */
parse arg modname compopts linkopts .
/* z.B.:
 modname='Demo'
 compopts='-yzgm2:demos'
 linkopts='+rcdgm2:Demos'
*/
options failat 11
IF ~show('Ports','M2C') then exit
address 'M2C' 'compile' compopts modname
IF RC ~= 0 then exit
IF ~show('Ports','M2L') then exit
address 'M2L' 'link' linkopts modname
exit
\end{verbatim}
\end{example}

\subsection{R\protect"uckgabewerte}
\label{RetVal}

Alle Programme des \mtwoamiga-Systems haben ein
einheitliches Konzept der R"uck"-gabe\-werte.
Die R"uckgabewerte behalten das Maximum in den 
Variablen {\tt Arts.returnVal} und 
{\tt ArgHandler.rexxReply} auf. Nach der R"uckgabe
einer ARexx-Meldung wird {\tt rexxReply} wieder auf
Null gesetzt, {\tt returnVal} jedoch bleibt
unver"andert und wird dem Aufrufer des Programms
zur"uckgegeben!

\medskip\noindent
Die Werte setzen sich folgendermassen zusammen:

\begin{table}[h]
\begin{center}
\begin{tabular}{|lll|} \hline
Code & Wert & Bedeutung \\ \hline
{\tt rcOk} & 0 & alles paletti \\
{\tt rcWarn} & 5 & Warnung \\
{\tt rcIllOpt} & 8 & ung"ultige Option \\
{\tt rcActionErr} & 10 & z.B. Fehler im Quelltext \\
{\tt rcImportantNotFound} & 12 & wichtige Datei nicht gefunden \\
{\tt rcMainNotFound} & 14 & Hauptdatei nicht gefunden \\
{\tt rcIllegal} & 15 & ung"ultiges ARexx-Kommando \\
{\tt rcAborted} & 20 & Programm-Abbruch \\ \hline
\end{tabular}
\caption{R"uckgabewerte von \mtwoamiga}
\end{center}
\end{table}

Die Werte {\tt rcIllegal} und {\tt rcAborted} kommen dabei
{\em nur\/} in ARexx-Scripten zur Anwendung.
