Mit Programmen, Diplomarbeiten und anderen Projekten, bei denen aus mehreren Dateien letzten Endes eine entstehen soll, ist es wie mit Handarbeiten: Für den Topflappen nimmt man noch das Nadelspiel zur Hand, aber wenn´s an den Pullover geht, gibt es nicht umsonst Strickmaschinen – wie make.

Das Tool make wurde ursprünglich von Stuart I. Feldman entwickelt, um dem programmschaffenden Volke ein effektives Werkzeug zur Generierung von Programmen an die Hand zu geben. Dass dies sehr gut gelungen ist, belegt wohl die Tatsache, dass das ursprünglich unter und für Unix geschriebene make auf die meisten heute existierenden Plattformen portiert wurde. Sein Einsatzgebiet beschränkt sich aber schon lange nicht mehr ausschließlich auf die Programmierung.

Was ist make?

Die Standardsituation: Eine Programmiererin abeitet an einem beträchtlichen Haufen Quelldateien, die übersetzt und schließlich zu einem ausführbaren Programm zusammen gelinkt werden müssen. Jedes Mal, wenn eine Änderung an einer Datei vorgenommen wird, muss diese Datei neu übersetzt und dann das ganze Programm erneut gelinkt werden.

Dabei wird sehr schnell ein bedeutendes Problem sichtbar: Die Programmiererin muss sich jeweils alle Dateien merken, die sie modifiziert hat, und zweitens sollte sie auch alle Dateien im Kopf haben, die von diesen modifizierten Dateien abhängig sind.

Genau hier setzt make an. Das make-Tool kompiliert alle modifizierten Dateien sowie alle, die von diesen abhängig sind, und linkt dann alles fein säuberlich zum ausführbaren “Executable” zusammen. Um dieses Wunder zu vollbringen, folgt make haargenau den Anweisungen, die in einer Datei mit dem Namen Makefile festgehalten sind. Praktisch alle Programme, deren Quellcode veröffentlicht ist, und die z.B. auf dem heimischen Rechner übersetzt werden können, werden mittels Makefiles organisiert. Oft hat man dann nicht mehr zu tun, als den Befehl make einzutippen, einen Kaffee trinken zu gehen und dann das frisch übersetzte Programm zu starten.

Wie funktioniert make?

Das Prinzip, nach dem make arbeitet, ist recht einfach. Um die Dateien zu bestimmen, welche neu zu übersetzen sind, schaut make nach, ob schon eine Version des zu erzeugenden Programms existiert. Wenn nicht, werden alle Dateien nach den Anweisungen im Makefile kompiliert. Existiert schon eine alte Programmversion, dann nimmt sich make den “Timestamp” (“Zeitstempel”) dieser Version her und vergleicht ihn mit den Timestamps aller Dateien, die in der Abhängigkeitszeile angegeben sind. Ist der Timestamp einer solchen Datei aktueller als jener der alten Programmversion, dann werden diese Datei und alle von ihr abhängigen Dateien neu kompiliert.

Ein Makefile

Zur besseren Anschauung soll ein kleines, aus den Dateien foo.c und bar.c bestehendes Programm namens foo übersetzt werden.

gcc -c bar.c

übersetzt den C-Code in der Datei bar.c in eine Objektdatei namens bar.o. Dasselbe gilt für foo.c:

gcc -c foo.c

Schließlich werden die beiden erzeugten Objektdateien zu einem ausführbaren Programm namens foo zusammengelinkt:

gcc -o foo foo.o bar.o

1:  # Makefile
2:
3:  foo:   foo.o bar.o
4:     gcc -o foo foo.o bar.o
5:
6:  foo.o: foo.c
7:     gcc -c foo.c
8:
9:  bar.o: bar.c
10:    gcc -c bar.c

In einem Makefile würde man das ungefähr wie in Listing 1 formulieren. Es beginnt mit einem Kommentar in der ersten Zeile: Ein # bedeutet make – wie unter Linux u.a. Unixbetriebssysteme üblich –, sich um den in der Zeile folgenden Text nicht zu kümmern. In Zeile 3 folgt eine Target/Dependency Line oder auf deutsch eine Abhängigkeitsdarstellung. Der dazu gehörige Anweisungsblock, hier nur eine Zeile, folgt in Zeile 4. Eine solche Kombination von Abhängigkeitsdarstellung und Anweisungsblock folgt dann nochmal in den Zeilen 6, 7 sowie 9 und 10.

Eine Target/Dependency Line definiert ein Ziel (“target”) für den darauf folgenden Anweisungsblock und gibt durch einen Doppelpunkt getrennt die Dateien an, aus welchen das Target erzeugt werden soll, also, von welchen Dateien es abhängig (“dependent”) ist. Allgemein formuliert sieht eine Target/Dependency Line so aus:

ziel:  objekt1 objekt2 ...

Ein Programm kann aus einer ganz erheblichen Menge Quelldateien bestehen. Wenn man die alle in eine Zeile schreiben würde, verliert man schnell den Überblick. Deshalb darf eine solche Erklärung über mehrere Zeilen verteilt werden. Dazu setzt man ans Ende jeder Zeile das Fortsetzungszeichen \:

ziel:  objekt 1 \
       objekt 2 \
       ...      \
       objekt n

Im Makefile aus Listing 1 sind, neben foo, zwei weitere Ziele angegeben, nämlich foo.o und bar.o. Per Voreinstellung nimmt sich make immer der ersten Target/Dependency Line an. Wünscht man einmal ein anderes Ziel, dann ist es möglich, make dies als Kommandozeilenoption mit auf den Weg zu geben:

make foo.o

Dieser Befehl weist make an, sich nur um das Ziel foo.o zu kümmern und alle weiteren Ziele außer Acht zu lassen.

Auf die Aufzählung der Abhängigkeiten folgt ein Anweisungsblock, der aus beliebig vielen, untereinander geschriebenen und jeweils mit einem Tabulator eingerückten Anweisungen bestehen kann:

ziel: objekt1 objekt2 ...
        anweisung1
        anweisung2
        ...

Hat man trotzdem das dringende Bedürfnis, alle Anweisungen in eine Zeile zu schreiben, steht dem nichts im Wege – vorausgesetzt, man trennt die einzelnen Befehle durch Semikolons:

ziel: objekt1 objekt2 ...
        anweisung1 ; anweisung2 ; ...

Einen Tabulator zum Einrücken der Anweisung zu verwenden ist hierbei genauso zwingend wie das Einrücken selbst. Sollte make mal streiken, liegt es zu 90 Prozent an einem vergessenen Tabulator.

Pseudotargets

Ein häufiger Sonderfall ist es, wenn eine Abhängigkeitsdarstellung keine Dependencies enthält, d.h., wenn nach dem Doppelpunkt keine Dateien stehen. Dies bezeichnet man als Pseudotargets. So etwas eignet sich z.B. hervorragend, um kleine Aufräumaktionen zu definieren:

cleanup:
        rm datei1
        rm datei2
        ...

Nun kann man mit der Anweisung

make cleanup

nach einem Kompiliervorgang schön sauber machen, indem man die Dateien (im Beispiel datei1 und datei2 genannt), die man nicht mehr braucht, von make löschen lässt. Ein Pseudotarget wird immer ausgeführt, denn es gibt ja keine Dateien mit Timestamps, an denen sich make orientieren könnte. Viele Pseudotargets sind bereits von make vordefiniert und können als Schalter für bestimmte Einstellungen verwendet werden. Dies bezeichnet man als “Predefined Pseudotargets”. So weist z.B.

.SILENT:

make an, die Kommandos, die es gerade ausführt, nicht explizit auf dem Bildschirm auszugeben. Dies ist äquivalent zur Kommandozeilenoption make -s .

Predefined Pseudotargets beginnen mit einem Punkt (.), werden immer groß geschrieben und stehen der Fairness wegen am Anfang eines Makefiles – am Anfang deswegen, damit man mit einem Blick erfassen kann, welche Pseudotargets verwendet werden. Es kann einen noch etwas Unerfahrenen in den Wahnsinn treiben, wenn beim Kompilieren keine Ausschrift auf dem Monitor erscheint, nur weil irgendwo im Makefile die Anweisung .SILENT: “versteckt” ist.

Suffix-Regeln

Bei allen Betriebsystemen, so auch unter Linux, existieren gewisse Konventionen, was Dateiendungen angeht. Das bedeutet z.B., dass der Name von Dateien, die C-Quelltexte enthalten, auf .c enden muss, Assemblerquelltexte auf .s und LaTeX-Dateien auf .tex. Dies ermöglicht es nicht nur dem geübten Auge, von der Dateiendung auf den Inhalt zu schließen, sondern auch KDE und z.B. make.

Intern besitzt make eine Datenbank, in der bestimmten Dateiendungen bestimmte Befehlsfolgen zugeordnet sind. make weiß auch sonst noch Einiges, z.B. dass beim Kompilieren einer C-Quelltextdatei (.c) eine Objektdatei (.o) entsteht, bzw. umgekehrt, dass eine C-Quelldatei existieren muss, wenn eine Objektdatei gebraucht wird.

make registriert also, wenn Objektdateien in einer Abhängigkeitserklärung stehen und geht nach einem Blick in die eigene Datenbank automatisch davon aus, dass die dazugehörigen C-Quelltext-Dateien vorhanden sind und übersetzt werden können. Unser Makefile aus Listing 1 lässt sich somit auch etwas kürzer formulieren (Listing 2).

# Makefile
foo:  foo.o bar.o
        gcc -o foo foo.o bar.o

Die C-Quelltext-Dateien brauchen nun mit keiner Silbe mehr erwähnt werden. make registriert die Objektdateien in der Target/Dependency Line, und der Rest passiert automatisch.

Welche Suffix-Regeln die auf dem aktuellen System ansässige make-Version kennt, erfährt man nach Eingabe des Befehls

make -p > make_default

Existiert für eine bestimmte Dateiendung noch keine Suffix-Regel oder möchte man eigentlich etwas ganz anderes, als der vorgesehene Befehl tun würde, ist es natürlich auch möglich, seine eigenen Suffix-Regeln zu definieren. Eine Regel ist dabei grundsätzlich folgendermaßen aufgebaut:

.von.nach
        anweisung1
        anweisung2
        ...

Als Beispiel erweitern wir das Makefile aus Listing 2 um eine Definition für .c.o (Listing 3). Wir sagen make also, was es tun soll, wenn es Objektdateien in Abhängigkeitsbeschreibungen findet, aber keine C-Quelltextdateien explizit angegeben wurden.

# Makefile
foo:  foo.o bar.o
        gcc -o foo foo.o bar.o
.c.o
        gcc -c $<

Das “Von” ist in diesem Falle eine C-Datei (.c), das “Nach” eine Objektdatei (.o), und die Anweisung zwar nicht sonderlich originell aber wirkungsvoll gcc -c $<. Bei $< handelt es sich um ein sogenanntes internes Makro. Es enthält jeweils den Namen des dependend file, also der Datei, die in der Target/Dependency Line hinter dem Doppelpunkt steht (hier das jeweilige .c-File). Dabei darf $< nur bei der Definition von Suffix-Regeln verwendet werden – warum und wieso steht im nächsten Abschnitt.

Findet make nun die Objektdatei foo.o in der Abhängigkeitsbeschreibung, schaut es in seine interne Datenbank und findet heraus, dass da, wo eine Objektdatei entstehen soll, irgendwo eine C-Datei rumstehen muss. Wie sich der Übergang von C-Datei zu Objektdatei vollziehen soll, beschreibt die Anweisung in Listing 3.

Makros

make kennt natürlich auch Makros. Dabei sind grundsätzlich drei Arten zu unterscheiden: zum Ersten vom Benutzer definierte Makros, zum Zweiten von make mit Werten vorbelegte Makros, die aber vom Nutzer geändert werden können, und zum Dritten Makros, die von make situationsbedingt mit Werten belegt werden, vom Nutzer aber nicht geändert werden können.

Beginnen wollen wir hier mit den Eigenschaften, die alle drei gemeinsam haben. Da wäre z.B. die Konvention, dass Makros ausschließlich mit Großbuchstaben bezeichnet werden:

NAME = blah blah

Will man auf die Makros zugreifen, stellt man ein $-Zeichen voran und fasst, wenn der Makroname aus mehr als einem Zeichen besteht, den Namen in Klammern:

... $(NAME) ...

Dabei ist es Ihrem guten Geschmack überlassen, ob Sie runde () oder geschweifte Klammern {} verwenden. Es ist also auch möglich,

... ${NAME} ...

zu schreiben. make macht mit solchen Makros nichts weiter, als sie an der Stelle, an der sie stehen, zu expandieren, sprich: durch ihren (aktuellen) Inhalt zu ersetzen. Wie unser Makefile mit ein paar Makros aussieht, zeigt Listing 4.

ZIEL = foo
OBJS = foo.o bar.o
OPT  = -o
CC   = gcc
$(ZIEL): $(OBJS)
        $(CC) $(OPT) $(ZIEL) $(OBJS)

Hier haben wir vier Makros definiert, nämlich ZIEL, OBJS, OPT und CC. make expandiert diese in den beiden Zeilen darunter, so dass dort nichts Anderes steht als die Target/Dependency Line und darunter die Anweisung:

foo: foo.o bar.o
   gcc -o foo foo.o bar.o

CC fällt dabei schon in die oben erwähnte zweite Kategorie vorbelegter Makros. Das heißt, sein Wert ist meist auf einen auf dem System installierten Compiler gesetzt und kann vom Nutzer nach dessen Wünschen überschrieben werden. Dies hat einen bedeutenden Vorteil: Die Verwendung solcher Makros erhöht die Portierbarkeit, da alle Festlegungen, Optionen und Schalter, die bei der Kompilierung verwendet werden sollen, am Anfang des Makefiles stehen. Damit legt der Programmierer im Makefile einige Standardpfade und Optionen sowie vielleicht einen Compiler fest. So braucht man sich, wenn man ein Programm übersetzen möchte, z.B. keine Gedanken um den Compiler machen, da bei der Verwendung von CC der Standardcompiler des Systems verwendet wird.

Neben den eben beschriebenen einfachen und vordefinierten Makros kennt make auch sogenannte interne Makros. Interne Makros werden dynamisch beim Lesen einer Abhängigkeitsbeschreibung immer wieder neu definiert. Durch die Verwendung interner Makros werden Makefiles nicht nur vereinfacht, sondern können auch leichter geändert werden. An dieser Stelle sollen nur zwei interne Makros vorgestellt werden.

Da ist zum Einen $@. $@ enthält immer den Namen des aktuellen Ziels. make schaut beim Auftreten von $@ in die Target/Dependency Line und ersetzt $@ durch den Ausdruck vor dem Doppelpunkt.

Zum Zweiten ist $? sehr beliebt. $? enthält die Namen aller neueren Objekte, oder besser ausgedrückt, alles was in der Target/Dependency Line hinter dem Doppelpunkt steht. Ein illustrierendes Beispiel steht in Listing 5.

ZIEL = foo
OBJS = foo.o bar.o
OPT  = -o
$(ZIEL): $(OBJS)
        $(CC) $(OPT) $@ $?

Darin fassen wir nochmal alles über Makros zusammen. Zu Beginn des Makefiles definieren wir drei Makros mit den Namen ZIEL, OBJS sowie OPT. Diese werden in der Target/Dependency Line zu

foo: foo.o bar.o

expandiert. In der darunter stehenden Anweisung verwenden wir das vordefinierte Makro CC, welches den auf dem aktuellen System installierten C-Compiler enthält. Dieses brauchen wir also im Allgemeinen gar nicht erst explizit zu definieren. Abschließend expandiert make noch die beiden internen Makros $@ und $? zum aktuellen Ziel bzw. zu den dazugehörigen Objektdateien. Damit ergibt sich folgende Anweisung:

gcc -o foo foo.o bar.o

… natürlich nur, wenn der gcc der auf dem System ansässige C-Compiler ist.

Das war …

… natürlich bei Weitem noch nicht alles, was es zu make zu sagen gäbe. Wer mit diesem sehr nützlichen Werkzeug intensiveren Kontakt sucht, dem seien z.B. die beiden Bücher in der Info-Box ans Herz gelegt. Dabei ist das Buch von Tondo, Nathanson und Yount eine kurze und schmerzlose englische Einführung in make-Versionen verschiedener Hersteller, wohingegen sich das Werk von Herold etwas ausgiebiger mit Details beschäftigt.

.SUFFIXES:      .tex .dvi .ps

#############################################
FILE    =  book
#############################################
DVIFILE =  $(FILE).dvi
PSFILE  =  $(FILE).ps

TEX     =  latex
DVIPS   =  dvips
DVIOPT  =  -q -D600

.tex.dvi:
        echo "$< wird übersetzt ..."
        $(TEX) $<
        $(TEX) $<

$(PSFILE): $(DVIFILE)
        echo "$@ wird erzeugt ..."
        $(DVIPS) $(DVIOPT) $?
        $(MAKE) -i cleanup

dvips -q -D600 book.dvi

cleanup:
        echo "Verzeichnisse werden aufgeräumt!";
        rm -rf *~ *.*~ *.log *.aux *.dvi *.idx *.toc

.SUFFIXES:      .tex .dvi .ps
#############################################
FILE    =  book
#############################################
DVIFILE =  $(FILE).dvi
PSFILE  =  $(FILE).ps
TEX     =  latex
DVIPS   =  dvips
DVIOPT  =  -q -D600
#############################################
.tex.dvi:
        echo "$< wird übersetzt ..."
        $(TEX) $<
        $(TEX) $<
$(PSFILE): $(DVIFILE)
        echo "$@ wird erzeugt ..."
        $(DVIPS) $(DVIOPT) $?
        $(MAKE) -i cleanup
cleanup:
        echo "Verzeichnisse werden aufgeräumt!";
        rm -rf *~ *.*~ *.log *.aux *.dvi *.idx *.toc