\section{Entstehunggeschichte}
Die Entstehungsgeschichte der Tools kann detailierter in
\cite{MacKenzie00} nachgelesen werden.

\subsection{UNIX Systeme}
\textit{Autoconf} wurde als erstes von den beiden hier vorgestellten Tools
entwickelt. Seine Entstehung ist durch die Geschichte des Betriebssystems UNIX
abh\"angig.

Die erste Version von UNIX wurde von Dennis Ritchie und Ken Thompson an den
Bell Labs 1969 geschrieben. In den 70ern wurde es Bell Labs nicht erlaubt UNIX
kommerziell zu vertreiben, aber f\"ur geringe Kosten an Universit\"aten zu
verteilen. Die Berkeley Universit\"at in Kalifornien arbeitete ihre
Verbesserungen zu dem UNIX-Quellcode ein und machte ihr System sp\"ater als
\textit{BSD} (Berkeley Software Distribution) bekannt. In den 80ern hatte
AT\&T ein Abkommen unterzeichnet, welches es der Firma wieder erlaubte, UNIX
kommerziell zu verkaufen. Ihre erste Version von UNIX wurde als ``System III''
bekannt. Die Popularit\"at des UNIX wuchs in den 80ern und etliche Firmen
erstellten ihre eigenen Versionen.  Obwohl alle UNIX-Varianten in ihren
Fundamenten \"ahnlich waren, gab es verschiedene Unterschiede zwischen
ihnen. Sie hatten leicht unterschiedliche Zusammenstellungen von Headerfiles
und die Auflistungen von Funktionen in den Systembibliotheken wiesen auch
leichte Unstimmigkeiten auf.

Variationen in den Systemen stellten Probleme f\"ur
Programme dar.  Sogar eine Funktion wie \texttt{memcpy} war nicht auf
jedem System verf\"ugbar; die BSD-Systembibliothek stellte zwar eine
\"ahnliche Funktion names \texttt{bcopy} zur Verf\"ugung, aber die
Aufrufparameter waren in umgekehrter Reihenfolge
angeordnet. Programmierer, die ihre Programme auf mehreren
unterschiedlichen UNIX-Varianten lauff\"ahig halten wollten, mussten
sich der einzelnen Unterschiede bewu"st sein.  W\"ahrend es im
Allgemeinen m\"oglich war, die einzelnen Systeme und Versionen mittels
\texttt{\#ifdef} Pr\"aprozessoranweisungen zu identifizieren, wurde es
extrem schwierig festzustellen welche Version welche Features anbot
und welche nicht. Es wurde klar, dass eine besser organisierte Methode von
N\"oten war, um die Unterschiede zwischen den UNIX-Varianten
handhabbar zu machen.

\subsection{Autoconf}
Im laufe der Zeit entstanden verschiedene Systeme, die speziel daf\"ur
entworfen wurden, Entwicklern mit der Sourcecode-Portabilit\"at zu
helfen.
\begin{itemize}
        \item \textit{Metaconfig} von Larry Wall, Harlan Stenn und Raphael
        Manfredi.
        \item Das \textit{Cygnus configure}-Skript von K.Richard Pixley und
        das \textit{GCC configure}-Skript von Richard M. Stallman.
        \item Das \textit{GNU Autoconf} Paket von David MacKenzie.
        \item \textit{Imake}, das ein Teil des X Window Systems ist.
\end{itemize}
Jedes dieser Systeme spaltet das Erstellen einer Software in einen
Konfigurations- und einen Erstellungsschritt. Der Erstellungsschritt st\"utzt
sich bei allen Systemen auf das Programm ``Make''. Dieses liest eine Reihe von
Regeln aus einer sog. ``Makefile'', die w\"ahrend des Konfigurationsschrittes
erzeugt wurden, anhand derer es den Quellcode kompiliert.

\textit{Metaconfig} und \textit{Autoconf} sind Programme, die von
Programmierern benutzt werden, um ein Shell-Skript zu erstellen, welches
\"ublicherweise im Softwarepaket enthalten ist. Ein Benutzer, der das
Softwarepaket erstellen m\"ochte, f\"uhrt zuerst dieses Skript aus, um den
Erstellungsschritt f\"ur sein System zu konfigurieren.  Das von
\textit{Metaconfig} generierte Skript ist standarm\"a"sig interaktiv.

Das \textit{Cygnus} und \textit{GCC ``configure''} hatten zwar Unterst\"utzung
f\"ur das sog. ``cross development'' mussten aber f\"ur jedes neue Unix
angepasst werden, damit sie saubere Arbeit leisten konnten. Dies war zwar keine
schwierige Aufgabe, aber neue Benutzer eines Softwarepakets sollten sich damit
nicht herumplagen m\"ussen. Das selbe galt f\"ur \textit{Imake}. Weil
\textit{Metaconfig} und \textit{Automake} Eigenschaftstests selbst
durchf\"uhrten, generierten sie auch auf neuen UNIX Varianten sehr oft korrekt
arbeitende Skripte, die nicht mehr modifiziert werden mussten. Das machte sie
flexibler und einfacher zu benutzen und f\"uhrte zur gro"sen Verbreitung von
\textit{Autoconf}. Sp\"ater erweiterte David MacKenzie \textit{Autoconf} um
Features, die in den \textit{Cygnys} und \textit{GCC Skripten} enthalten
waren, so dass es auch das ``cross development'' unterst\"utzt.

Im Gro"sen und Ganzen werden heute neue Projekte mit der Unterst\"utzung von
\textit{Autoconf} begonnen und nicht mehr mit anderen
Konfigurationswerkzeugen, obwohl diese doch noch bei einigen Paketen
eingesetzt werden.

\subsection{Automake}
Nach dem man mit \textit{Autoconf} ein stabiles Rahmenwerk hatte, um die
Unterschiede zwischen verschiedenen UNIX Varianten handzuhaben, mussten
die Entwickler jedoch gro"se ``Makefile.in''s schreiben, um \textit{Autoconf}
benutzen zu k"onnen. Das ``configure''-Skript, welches durch \textit{Autoconf}
generiert wird, nimmt die ``Makefile.in'' entgegen und erstellt daraus eine
``Makefile'', die von ``Make'' abgearbeitet wird.

Da die meisten Programme auf die gleiche Art und Weise kompiliert werden, ist
es m\"uhsam und langweilig immer wieder das Gleiche schreiben zu m\"ussen.
Ausserdem kann das Schreiben von Makefiles recht komplex werden, wodurch sich
die Fehlerquote um einiges erh\"oht.

Diese Faktoren f\"uhrten zu der Entwicklung von \textit{Automake}. Es ist
ebenso wie \textit{Autoconf} ein Programm, das nur vom Entwickler benutzt
wird, um sich die Arbeit im Wesentlichen zu erleichtern. Der Programmierer
schreibt eine ``Makefile.am'', die um vieles einfacher im Aufbau ist, und
\textit{Automake} erzeugt aus ihr eine ``Makefile.in'', die von
\textit{Autoconf} weiter bearbeitet wird.
