This is the Title of the Book, eMatter Edition
Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
|
11
First
Max.
Linie
Max.
Linie
Kapitel 2
KAPITEL 2
Regeln
Im letzten Kapitel haben wir bereits einige Regeln erstellt, um unser Wortzähl-Programm
zu linken und zu kompilieren. Jede dieser Regeln definiert ein Ziel, also eine zu aktuali-
sierende Datei. Jedes Ziel hängt von einer Reihe von Voraussetzungen ab, die ebenfalls
Dateien sind. Wurden eine oder mehrere der abhängigen Dateien nach dem Ziel verän-
dert, führt
make für diese Regeln das betreffende Kommandoskript aus. Das Ziel einer
Regel kann seinerseits als Voraussetzung für eine andere Regel verwendet werden. Die
Regeln und ihre Voraussetzungen bilden also eine Kette oder einen Graphen aus Abhän-
gigkeiten (»dependency graph«). Letztendlich geht es bei
make um das Erstellen und Ver-
arbeiten dieses Abhängigkeitsgraphen.
Da die Regeln in
make so wichtig sind, gibt es mehrere verschiedene Arten von Regeln.
Explizite Regeln, die wir bereits aus dem vorigen Kapitel kennen, verweisen auf ein
bestimmtes Ziel, das aktualisiert werden muss, wenn es älter ist als seine Voraussetzun-
gen. Musterregeln (»pattern rules«) verwenden an Stelle der expliziten Dateinamen Wild-
card-Zeichen. Auf diese Weise kann
make die Regel anwenden, sobald eine auf das
Muster passende Datei aktualisiert werden soll. Implizite Regeln sind entweder Musterre-
geln oder Suffixregeln, die sich in
makes integrierter Regel-Datenbank befinden. Diese
Datenbank bereits »eingebauter« Regeln erleichtert das Schreiben von Makefiles, da
make
die Dateitypen, Suffixe und Programme für häufig auftretende Aufgaben bereits kennt.
Statische Musterregeln verhalten sich wie reguläre Musterregeln, werden aber nur auf eine
bestimmte Liste von Zieldateien angewendet.
GNU
make kann oftmals als gleichwertiger Ersatz vieler anderer make-Versionen benutzt
werden. Es enthält bereits eine Reihe von Eigenschaften, mit denen die Kompatibilität
mit anderen Versionen gewährleistet wird. Suffixregeln waren ursprünglich dazu
gedacht, um in
make allgemeine Regeln zu verfassen. Zwar unterstützt GNU make diesen
Regeltyp auch weiterhin, allerdings wird er mittlerweile als veraltet angesehen und meist
durch Musterregeln ersetzt, die klarer und allgemeiner verwendbar sind.
This is the Title of the Book, eMatter Edition
Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
12
|
Kapitel 2: Regeln
Links
Max.
Linie
Max.
Linie
Explizite Regeln
Meistens werden Sie explizite Regeln schreiben, in denen bestimmte Dateien als Ziele
und Voraussetzungen verwendet werden. Eine Regel kann mehr als ein Ziel haben, was
bedeutet, dass in diesem Fall jedes Ziel die gleichen Voraussetzungen besitzt. Sind die
Ziele veraltet, werden für ihre Aktualisierung jeweils die gleichen Aktionen durchgeführt.
Zum Beispiel:
vpath.o variable.o: make.h config.h getopt.h gettext.h dep.h
Diese Regel besagt, dass vpath.o und variable.o beide von den gleichen C-Header-Dateien
abhängen. Wir hätten auch schreiben können:
vpath.o: make.h config.h getopt.h gettext.h dep.h
variable.o: make.h config.h getopt.h gettext.h dep.h
Beide Ziele werden unabhängig voneinander behandelt. Ist eine der Objektdateien im
Verhältnis zu einer ihrer Voraussetzungen veraltet (hat also mindestens eine der Header-
Dateien ein aktuelleres Änderungsdatum), wird
make diese Objektdatei aktualisieren,
indem es die zu dieser Regel gehörenden Kommandos ausführt.
Eine Regel muss nicht »in einem Stück« definiert werden. Sieht
make eine Zieldatei, wer-
den das Ziel und seine Voraussetzungen zum Abhängigkeitsgraphen hinzugefügt. Enthält
der Abhängigkeitsgraph das Ziel bereits, werden zusätzliche Voraussetzungen an den
Eintrag für die betreffende Datei angehängt. In einfachen Fällen hilft diese Möglichkeit,
lange Zeilen auf natürliche Weise zu umbrechen, um die Lesbarkeit des Makefiles zu
erhöhen:
vpath.o: vpath.c make.h config.h getopt.h gettext.h dep.h
vpath.o: filedef.h hash.h job.h commands.h variable.h vpath.h
In komplexeren Fällen kann die Liste der Voraussetzungen aus Dateien bestehen, die
sehr unterschiedlich gehandhabt werden:
# Sicherstellen, dass lexer.c erzeugt wird, bevor vpath.c kompiliert wird.
vpath.o: lexer.c
...
# vpath.c mit speziellen Flags kompilieren.
vpath.o: vpath.c
$(COMPILE.c) $(RULE_FLAGS) $(OUTPUT_OPTION) $<
...
# Von einem Programm erzeugte Abhängigkeiten einbeziehen.
include auto-generated-dependencies.d
Die erste Regel besagt, dass das Ziel vpath.o immer aktualisiert werden muss, wenn lexer.c
aktualisiert wurde (vielleicht weil das Erzeugen von lexer.c andere Nebeneffekte hat).
Diese Regel stellt außerdem sicher, dass eine Voraussetzung immer vor ihrem Ziel aktua-
lisiert wird. (Beachten Sie die bidirektionale Natur der Regeln. »Vorwärts« gelesen besagt
die Regel, dass nach der Aktualisierung von lexer.c die nötigen Schritte unternommen
werden müssen, um auch vpath.o auf den neuesten Stand zu bringen. »Rückwärts« gele-
sen steht hier, dass für das Bauen oder Benutzen von vpath.o zuerst die Datei lexer.c auf

Get GNU make, 3rd Edition now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.