GNU make, 3rd Edition

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