
\section{Abh\protect"angigkeiten verwalten ({\tt m2make})}

\label{m2make}
\subsection{Aufgabe und Arbeitsweise}

\mtwo{} unterst"utzt die getrennte "Ubersetzung von Moduln mit
gleichzeitiger Konsistenzpr"ufung der Schnittstellen. Dazu muss auf die
Reihenfolge der "Ubersetzung der verschiedenen Moduln geachtet
werden. Bei der Compilation eines Moduls m"ussen alle
Definitionen der importierten Moduln in "ubersetzter Form
vorliegen; in \mtwoamiga{} also als Symboldatei.
Diese Abfolge bestimmt sich aus den Abh"angigkeiten zwischen
den verschiedenen Moduln.

Abbildung \ref{modDep} zeigt eine m"ogliche Ausgangssituation:
die Definitionen der Moduln M4, M5 und M2 m"ussen "ubersetzt
werden, bevor die Implementation des Moduls M2 "ubersetzt
werden kann. Ebenso muss die Definition von M6 vor der
Definition von M3 "ubersetzt werden. Ein m"oglicher
Ablauf von Compilationen der Definitionsmoduln w"are also:

\begin{quote}
M6, M3, M5, M4, M2
\end{quote}

Sind all diese Definitionen "ubersetzt, k"onnen die
zugeh"origen Implementationen in beliebiger Reihenfolge
"ubersetzt werden.

\begin{figure}[bt]
\centering
\unitlength5mm
\begin{picture}(18,14)
\newsavebox{\module}
\savebox{\module}(0,0)[bl]{
  \put(0,0){\framebox(3,2)[br]{}}
  \put(0,0.1){\makebox(2.9,1.9)[br]{{\footnotesize def}}}
  \put(1,0){\line(0,-1){1}} \put(1,-1){\line(1,0){3}}
    \put(4,-1){\line(0,1){2}} \put(4,1){\line(-1,0){1}}
}
\put(0,1){\usebox{\module}\makebox(3,2){M4}}
\put(7,1){\usebox{\module}\makebox(3,2){M5}}
\put(14,1){\usebox{\module}\makebox(3,2){M6}}
\put(3,6){\usebox{\module}\makebox(3,2){M2}}
\put(10,6){\usebox{\module}\makebox(3,2){M3}}
\put(6,10){\framebox(4,3){M1}}
\put(1.5,3){\vector(3,2){3}}
\put(8.5,3){\vector(-3,2){3}}
\put(15.5,3){\vector(-4,3){4}}
\put(4.5,8){\vector(3,2){3}}
\put(11.5,8){\vector(-3,2){3}}
\end{picture}
\caption{\label{modDep}Abh"angigkeiten mehrerer Moduln}
\end{figure}

Oftmals ist es schwierig , diese
Abh"angigkeiten genau zu "ubersehen und die
Auswirkungen einer "Anderung eines Moduls richtig zu erkennen.
Um in einem solchen Fall die erneute "Ubersetzung aller Moduln
zu verhindern, kann {\bf m2make}\footnote{Der Name des Werkzeugs
kommt aus der UNIX-Welt} zur Hilfestellung herangezogen
werden. Das Programm {\tt m2make} "ubernimmt die aufwendige
Arbeit, die Aktualit"at aller Moduln zu "uberpr"ufen und die
n"otigen "Ubersetzungen in der richtigen Reihenfolge
zu veranlassen. F"ur Programm-Moduln wird
nach einer erfolgreichen "Ubersetzung ausserdem der Linker gestartet
und eine ausf"uhrbare Datei erzeugt. Der "ubliche Entwicklungslauf
zwischen
\begin{quote}
Editor $\rightarrow$ Compiler $\rightarrow$ Linker $\rightarrow$ Ausf"uhrung
\end{quote}
verk"urzt sich mit {\tt m2make} zu
\begin{quote}
Editor $\rightarrow$ Make $\rightarrow$ Ausf"uhrung
\end{quote}

Dabei d"urfen Sie beliebig Quelltexte "andern und erhalten
schliesslich in jedem Fall eine lauf"|f"ahige Version. Bei der
"Ubernahme von Quelltexten anderer Programmierer --- denkbar
sind etwa Moduln von Public Domain Disketten oder von Freunden ---
erspart {\tt m2make} das zeitraubende Ermitteln der Abh"angigkeiten
zwischen den Moduln. Mit {\tt m2make} sind Sie sicher, dass diese
neuen Moduln richtig in Ihr System "ubernommen werden.

Diese Aufgabe erfordert mehrere Schritte. Als erstes m"ussen
die Ab"-h"an\-gig\-kei\-ten der betroffenen Moduln festgestellt werden.
Dies geschieht durch die Untersuchung der einzelnen Quelltexte.
In diesen wird nach {\tt IMPORT}-Anweisungen gesucht.
Das jeweils aktuelle Modul ist von allen dort referenzierten
Moduln abh"angig. Diese werden in einer Liste eingetragen. Sind
keine weiteren {\tt IMPORT}-Anweisungen mehr zu finden, wird die
Suche im n"achsten Modul der Liste fortgesetzt. Der Suchvorgang
wird beendet, sobald die Liste keine unbearbeiteten Eintr"age mehr
enth"alt.

Bei diesem Vorgang werden die Quelltexte sowohl der Definitionen als auch der
Implementationen durchsucht. Ausserdem sind die
Abh"angigkeiten entsprechend markiert, um der besonderen Behandlung
der Abh"angigkeiten der Definitionsmoduln Rechnung tragen zu k"onnen.

Ausserdem wird implizit angenommen, dass jedes Implementationsmodul
die Moduln  {\tt MathFFP}, {\tt MathReal}, {\tt Mathieeedoubbas},
{\tt Profiler} und  {\tt Arts} importiert. Folglich werden diese
Compilationszeiten und Schl"ussel ebenfalls "uberpr"uft.

Um diesen aufwendigen ersten Schritt m"oglichst selten durchf"uhren
zu m"ussen, legt {\tt m2make} nach diesem eine {\bf Abh"angigkeitendatei} an,
die beim n"achsten Mal den erheblichen Aufwand sparen kann. Sie ist
aber nur dann noch g"ultig, wenn in der Zwischenzeit keine
Abh"angigkeiten ge"andert wurden.

Der zweite Schritt sucht eine g"ultige Reihenfolge f"ur die
"Ubersetzung der Definitionsmoduln. Wie bereits erw"ahnt, bestehen
mehrere m"ogliche Ablauf"|folgen. Ausserdem wird in diesem Schritt
gepr"uft, ob eine "Ubersetzung "uberhaupt erfordert ist. Dies ist der
Fall, wenn mindestens eine der folgenden Bedingungen wahr
ist:
\begin{itemize}
\item
  Eine im  Definitionsmodul 
  importierte Definition wurde neu "ubersetzt.
\item
  Der Quelltext ist neuer als die entsprechende,
  "ubersetzte Version oder es besteht gar keine "ubersetzte Version.
\item
  Das Implementationsmodul importiert eine Definition, die
  neu "ubersetzt wurde.
\item
  Das "ubersetzte Implementationsmodul ist "alter als die
  "ubersetzte Versions des Definitionsmodul, d.h.\ die
  Objektdatei ist "alter als die zugeh"orige Symboldatei.
\end{itemize}

Bei allen Altersvergleichen wird das Datum der letzten "Anderung 
der entsprechenden Datei verwendet. Es ist deshalb "ausserst
wichtig, dass die Systemuhr immer die korrekte Zeit angibt.
Insbesondere ist eine "`Zukunftszeit"' zu vermeiden. Ausserdem
sollten Dateien ausschliesslich mit {\tt COPY CLONE} oder
"ahnlichem kopiert werden.

Falls schliesslich alle zu "ubersetzenden Quelltexte gefunden wurden
und auch alle Bibliotheksmoduln in einem konsistenten
Zustand erscheinen, wird nun der Compiler aufgerufen.
Als Argumente werden die Namen aller neu zu "ubersetzenden
Quelltexte in der ermittelten, korrekten Reihenfolge
"ubergeben. Treten w"ahrend der "Ubersetzung keine Fehler
auf, ruft {\tt m2make} schliesslich nach der Compilation
des Hauptmoduls --- sofern es sich um ein Programm-Modul handelt ---
den Linker auf, um eine ausf"uhrbare Datei zu erzeugen.

\subsection{Aufruf und Bedienung}

Die Optionen f"ur {\tt m2make} sollen dieses Werkzeug m"oglichst
vielseitig einsetzbar machen. Ohne Angabe von Optionen wird
der allgemeine Fall angenommen. Somit ist dem unge"ubten Benutzer
versichert, dass die "Ubersetzungsfolge korrekt abl"auft.
Die Optionen erlauben es dem fortgeschrittenen Benutzer,
{\tt m2make} besser seinen Bed"urfnissen anzupassen.

Ihre gew"unschte Zusammenstellung der Optionen k"onnen Sie in der
Umgebungsvariable "`{\tt ENV:M2MAKE}"'ablegen. Damit lassen
sich eigene Vorgabewerte erstellen.

\begin{quote}\tt
m2make \{+-012348dfilnpqwx -c{\cmsltt CompOptions\/} \\
~~-o{\cmsltt LinkOptions\/}
  -s{\cmsltt Stack\/}
  -t{\cmsltt TargetFile\/} ? ??
  {\cmsltt Modul}\}
\end{quote}

\begin{description}
\item[?]
  zeigt die Version von {\tt m2make} und gibt eine Hilfestellung
  der Bedienung.
\item[??]
  zeigt den Status der Optionen an.
\item[0\ldots8]
  Durch die Angabe der entsprechenden Ziffer kann eine
  Prozessorversion vorgegeben werden. Zusammen mit der
  Option {\tt f} wird dann das genaue Compilations- und Link-
  Verhalten bestimmt.
\item[d]
  (dependencies) Mit der Option "`{\tt +d}"' wird die aufwendige
  Erstellung der Abh"angigkeiten vermieden, sobald einmal eine
  Abh"angigkeitendatei erzeugt wurde. Dies ist nur m"oglich,
  wenn keinerlei "Anderungen der Abh"angigkeiten erfolgt sind.
  Als Grundregel gilt: wurden seit Erzeugung der Abh"angigkeitendatei
  keine {\tt IMPORT}-Listen ver"andert, muss diese nicht neu erstellt
  werden. Ohne Angabe erzeugt {\tt m2make} eine neue Abh"angigkeitendatei.
\item[f]
(force CPU) Mit der Option "`{\tt -f}"' wird nur die h"ochste
  {\em vorhandene\/} Objektdatei auf das Datum "uberpr"uft.
  Ist mit den Optionen "`{\tt -8-f}"' kein {\cmsltt Modul\tt.ob8}
  vorhanden, wird keine Compilation erzwungen, da der Linker
  ja suchen wird.  Mit "`{\tt -8+f}"' wird die Compilation
  erzwungen, wenn keine {\tt ob8}-Datei vorhanden ist.
  Ausnahme bilden die Libraries. Diese k"onnen nicht
  "ubersetzt werden, da dann auch eine neue Symboldatei
  erzeugt w"urde.
\item[i]
  (icons) Mit "`{\tt +i}"' werden Compiler und Linker angewiesen, Ikonen
  zu erzeugen. Ausserdem erh"alt die Abh"angigkeiten-Datei
  eine Ikone. Diese hat als Default-Tool "`{\tt M2:m2make}"',
   so dass ein Doppelklicken darauf gen"ugt.
  Sonst erhalten Sie nur dann Ikonen, wenn Sie {\tt m2make}
  von der Workbench aus aufrufen.
\item[l]
  (link) Ist ein Programm-Modul Ziel eines Make-Laufs, wird 
  abschliessend automatisch
  der Linker aufgerufen. Dieser Aufruf kann mit der Option
  "`{\tt -l}"' unterbunden werden.
\item[n]
  Wird {\tt m2make} die Option "`{\tt -n}"' mitgegeben, wird es
  zwar vollst"andig ablaufen, aber weder Compiler noch Linker
  wirklich aufrufen. Stattdessen werden die Befehlszeilen,
  die den Aufrufen entsprechen, "uber den aktuellen Ausgabestrom
  angezeigt.
\item[q]
  Die Option "`{\tt -q}"' unterdr"uckt alle Meldungen, die nur
  beschreibenden Charakter haben. Fehlermeldungen und Warnungen
  werden weiterhin ausgegeben.
\item[w]
  Mit "`{\tt +w}"' oder "`{\tt -w}"' werden Warnungen
  ausgegeben, beziehungsweise unterdr"uckt. Vorgabe ist "`{\tt +w}"'. 
\item[x]
  Diese Option erlaubt es, den Vorgang erheblich
  zu beschleunigen. Wird diese Option abgeschaltet, sucht und pr"uft
  {\tt m2make} nur im aktuellen Projekt und l"asst alle anderen Projekte,
  insbesondere das grosse und somit 
  zeitaufwendige {\tt M2:modules}, ausser acht. In diesem
  Fall m"ussen selbstverst"andlich die Moduln in den anderen Projekten
  in Ordnung sein. Ohne Angabe wird in {\em allen\/} Verzeichnissen
  gesucht.
\item[c{\cmsltt Optionen}]
  Die der Option unmittelbar anschliessenden Zeichen werden
  dem Compiler als Optionen weitergereicht. 
\item[o{\cmsltt Optionen}]
  Analog zur vorigen Option sind diese Angaben als Option f"ur
  den Linker gedacht.
\item[s{\cmsltt Stack}]
  Das Argument {\cmsltt Stack\/} gibt an, welche Stackgr"osse
  dem Compiler zur Verf"ugung gestellt werden soll. Ist der
  Wert $< 20\,000$, wird die Stackgr"osse auf 2000 gesetzt, da
  der Compiler in diesem Fall den notwendigen Stackbereich selber
  alloziert.
\item[t{\cmsltt Dateiname}]
  Hiermit kann der Name des zu erzeugenden Programms angegeben werden.
  Vorgabe ist durch den Linker gegeben, welcher den Modulnamen ohne
  Suf"|fix als Programmnamen nimmt. Dies sollte {\em nicht\/}
  bei den Linker-Optionen mit angegeben werden, da
  {\tt m2make} das Datum von Quelltext und Zieldatei "uberpr"ufen muss.
\item[p]
  Mit der Option "`{\tt +p}"' wird eine Zusatzfunktion von
  {\tt m2make} aktiviert. Alle anderen Optionen sowie die normale
  Arbeitsweise von {\tt m2make} sind hier {\em nicht\/} aktiv.
  Daf"ur wird eine Abh"angigkeitentabelle der Moduln auf dem
  aktuellen Ausgabestrom ausgegeben. Diese Tabelle enth"alt
  alle Moduln, die vom Hauptmoduln direkt oder indirekt importiert
  werden.
  
  In dieser Tabelle steht f"ur jedes Modul eine Zeile, die alle
  direkten Importe zu anderen Moduln enth"alt. Dabei werden Importe
  in den Definitionsmoduln mit einem "`{\tt D}"', diejenigen
  der Implementationsmoduln mit einem "`{\tt X}"' gekennzeichnet.
  Um die Tabelle m"oglichst kompakt und "ubersichtlich zu
  gestalten, werden die Spalten nur mit Zahlen (in 5er-Schritten)
  gekennzeichnet.
  Der Name des Moduls kann aus der entsprechenden Zeile entnommen
  werden.
  
  Die in Abbildung \ref{modDep} dargestellte Situation erg"abe
  folgende Darstellung:
  \begin{alltt} \baselineskip10pt
         \verb|\|  Modul B |     :     |
  Modul A \verb|\|         |    5:   10|
  ------------------|-----:-----|
  M5               6|     :X    |
  ------------------|-----:-----|
  M4               5|    X:     |
  ------------------|-----:-----|
  M6               4|   X :     |
  ------------------|-----:-----|
  M3               3|  XD :     |
  ------------------|-----:-----|
  M2               2| X  X:X    |
  ------------------|-----:-----|
  M1               1| XX  :     |
  \end{alltt}
  
  Das Modul {\tt M1} importiert in der Implementation die Moduln
  {\tt M2} und {\tt M3}. {\tt M2} importiert ebenfalls in der
  Implementation die Moduln {\tt M4} und {\tt M5},
  w"ahrend {\tt M3} in seiner Definition {\tt M6} importiert.
\end{description}

\begin{example}
Nun folgt ein Beispiel eines Make-Aufrufs, bei dem eine vorhandene
Abh"angigkeitendatei benutzt wird, zwei benutzerdefinierte Optionen
des Compilers gesetzt werden und schliesslich Prozessor und
Stack vorgegeben sind.
\begin{quote}
\begin{verbatim}
m2make +d-c"+oDemo -oDebug" -0-s20000 test
\end{verbatim}
\end{quote}
\end{example}

\subsection{Fehlermeldungen}

Hier kann zwischen ernsten Fehlern und blossen Warnungen unterschieden
werden. Ernste Fehler f"uhren direkt zum Abbruch des
{\tt m2make}-Durchlaufs. Warnungen teilen dem Benutzer mit, dass
{\tt m2make} seine Aufgabe un"-voll\-st"an\-dig oder nicht unbedingt
korrekt ausf"uhren konnte.

M"ogliche Warnungen sind:

\subsubsection{\cmsltt MyDream\/\tt: Keine Dateien f"ur dieses Modul gefunden}

Von einem referenzierten (importierten) Modul werden weder
die Quelltexte noch die "ubersetzten Versionen gefunden. In diesem
Fall kann das Hauptmodul nicht richtig "ubersetzt werden. Anstatt
aber den {\tt m2make}-Durchlauf abzubrechen, wird weitergefahren, um
allenfalls andere fehlende Moduln zu finden.

Ein m"oglicher Grund ist etwa, dass sich das Modul {\cmsltt MyDream\/}
in einem Projekt-Verzeichnis befindet, das im \mtwo{} Pfad fehlt.
Oder in einer {\tt IMPORT}-Liste steht schlicht ein Schreibfehler,
der den Namen eines Moduls zu {\cmsltt MyDream\/} verf"alscht hat.

\subsubsection{\cmsltt FileSystem\/\tt: Die "ubersetzten Versionen scheinen
  ung"ultig,\newline Quell\-text fehlt}
  
Nachdem keine Quelltexte gefunden wurden, hat {\tt m2make}
einen Konsistenztest mit den "ubersetzten Versionen durchgef"uhrt
und festgetellt, dass die Symboldatei neuer als die entsprechende
Objektdatei ist.

\noindent M"ogliche Reaktionen auf diese Meldung sind:
\begin{itemize}
\item
  Bei Systemdateien erfolgt diese Ausgabe, falls beim
  Kopieren von der Originaldiskette das urspr"ungliche Datum
  nicht beibehalten wurde. Dies l"asst sich am besten mit dem Befehl
  {\tt COPY CLONE} beheben. Es ist die einzige M"oglichkeit,
  um auch bei gegenseitigen Importen die Konsistenz zu wahren.
\item
  Falls dies bei einem eigenen Modul auftritt, sollten Sie die
  vorhandenen Versionen kontrollieren. Unter Umst"anden hat sich
  eine alte Version im Pfad unerw"unscht vorgeschoben.
\end{itemize} 

\subsection{R"uckgabewerte}

\begin{ttscript}{rcImportantNotFound}
\item[rcIllOpt]
  Eine ung"ultige Option oder "`{\tt ?}"' wurden angegeben.
\item[rcMainNotFound]
  Das Hauptmodul, das zu bearbeiten und schliesslich zu erstellen
  ist, wurde nicht gefunden.
\item[{\cmsltt rc\/\rm\ldots}]
  Kann eine Compilation oder der Linkvorgang nicht fehlerfrei
  durchgef"uhrt werden, wird dieser letzte R"uck"-gabe\-wert an
  den Aufrufer von {\tt m2make} weitergereicht.
\end{ttscript}

Die Verwendung der R"uckgabewerte ist unter \ref{RetVal}
beschrieben.
