Was bedeutet $$@ und das pipe-symbol im Makefile stehen?

(Sie haben einen beklagenswerten Wahl von Variablen-Namen; wir ändern DESTDIR zu SOURCE_DIR und lassen DEST_DIR allein.)

Angenommen, Sie schreiben eine einfache Regel:

$(DEST_DIR)/foo : $(SOURCE_DIR)/foo
    cp $(SOURCE_DIR)/foo $(DEST_DIR)/foo

Funktioniert, aber die Redundanz ist lästig. Früher oder später werden Sie das ändern $(DEST_DIR)/foo im preq, aber vergessen, es zu ändern in der Regel. Und die Regel ist schwer zu Lesen. So haben wir eine automatische Variablen:

$(DEST_DIR)/foo : $(SOURCE_DIR)/foo
    cp $(SOURCE_DIR)/foo $@

Wenn diese Regel ausgeführt wird, $@ wird erweitert, um den Namen des Ziel -, $(DEST_DIR)/foo. (Wir können es noch besser als das, aber lasst uns dort.)

Nun wollen wir sicherstellen, dass $(DEST_DIR) vorhanden ist, bevor diese Regel ausgeführt wird, aber wir wissen nicht wollen es eine Voraussetzung, genau, weil das fehlen dieses Verzeichnis sollte nicht genug, um die Ursache dieser Regel ausgeführt werden. Also machen wir es ein bestellen-einzige Voraussetzung:

$(DEST_DIR)/foo : $(SOURCE_DIR)/foo | $(DEST_DIR)
    cp $(SOURCE_DIR)/foo $@

Nun wollen wir viele Regeln wie diese, für verschiedene Ziele, und anstatt das zu tun, es der intelligente Weg,, verwenden wir eine "Dosen-Rezept", eine Art Vorlage für die Erstellung von Regeln für das Fliegen.

# This won't work
define KERNEL_RULE
$(SOURCE_DIR)/$(1) : kernel_modules
$(DEST_DIR)/$(1) : $(SOURCE_DIR)/$(1) | $(DEST_DIR)
    cp $(SOURCE_DIR)/$(1) $@
endef

Das problem ist, dass, wenn wir beurteilen diese definition $@ erweitert werden, und da es nicht in der Regel noch nicht, es wird erweitert, um nichts. Also ändern wir es $$@:

# This will work
define KERNEL_RULE
$(SOURCE_DIR)/$(1) : kernel_modules
$(DEST_DIR)/$(1) : $(SOURCE_DIR)/$(1) | $(DEST_DIR)
    cp $(SOURCE_DIR)/$(1) $$@
endef

Beim telefonieren diese definition $$@ erweitert, um $@ dann, wenn es ausgeführt wird die Regel, $@ wird erweitert, um den Namen des Ziels.