SelfLinux Programmierung Make Abschnitt 6 | SelfLinux-0.13.0

| Make | Autor Formatierung GFDL

#### 7 Richtlinien

Viele der Richtlinien in diesem Kapitel sind aus den "Makefile Conventions" für GNU-Programme entnommen (siehe http://www.gnu.org/prep/standards_50.html). Über das automake-Kommando könnnen Makefiles erzeugt werden, die diese Richtlinien unterstützen.

#### 7.1 Allgemeine Konventionen

#### 7.1.1 Standard-Shell

Normalerweise ist die Bourne-Shell (/bin/sh) als Standard- Shell vordefiniert. Es gibt aber auch make-Varianten, die die Standard-Shell über die Umgebungs-Variable SHELL vererbt bekommen. Um Probleme zu vermeiden, sollte daher die Bourne-Shell über folgendes Makro

    SHELL = /bin/sh

als Standard- Shell definiert werden.

#### 7.1.2 Suffix-Liste

Die Suffix-Liste sollte explizit gesetzt werden:

    .SUFFIXES:
    .SUFFIXES: .c .o

Die erste Zeile löscht die Suffix-Liste, die zweite Zeile setzt dann explizit die gewünschten Endungen.

Grund: Verschiedene make-Varianten haben unterschiedliche und inkompatible Suffix-Listen. Dies kann zu Verwirrungen auf unterschiedlichen Systemen führen.

#### 7.1.3 Programmstart

Programme im Arbeitsverzeichnis müssen mit ./programm gestartet werden.

Grund: Das aktuelle Verzeichnis ist nicht immer im Suchpfad enthalten.

#### 7.2 Utilities

#### 7.2.1 Shell-Kommandos

Auch wenn manche make-Varianten sowohl Korn-Shell- als auch Bash-Syntax verstehen, sollte man nur die Bourne-Shell-Syntax verwenden.

#### 7.2.2 Standard-Kommandos

Folgende Unix-Kommandos können direkt verwendet werden:

cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true

Bei den Optionen sollte man sich auf die gängigen Optionen beschränken, die auf allen Systemen vorhanden sind.

Grund: diese Kommandos sind auf allen Linux- und Unix-Varianten vorhanden

#### 7.2.3 Kommandoaufrufe

Alle übrigen Kommandos wie Compiler-Aufruf und andere Programme sollten in Variablen abgespeichert werden.

Grund: Zum einen ist dies änderungsfreundlicher, zum anderen kann bei Bedarf das Kommando über die Kommandozeile mitgegeben werden.

#### 7.3 Variablen

#### 7.3.1 Kommando-Variablen

Nach Möglichkeit sollten Variablen genauso wie das Kommando heissen und mit dem Namen des Kommandos vorbelegt sein.

Beispiel:

    YACC = yacc

#### 7.3.2 Vordefinierte Variablen

Variable | Wert | Beschreibung
--- | --- | ---
AR | ar | Archiver (zum Bibliotheken bauen)
CC | cc | C-Compiler
CXX | g++ | C++-Compiler
CPP | $(CC) -E | C-Präprozessor
FC | f77 | Fortran-Compiler
LD | ld | Linker, Loader
LEX | lex | lexikalische Analyse
MAKE | make | make-Kommando
PC | pc | Pascal-Compiler
YACC | yacc | Parser-Generator

Tipp: Bei der Verwendung von GNU-Make können die vordefinierten Variablen über

user@linux $ make -p -f /dev/null | grep " = "

ausgegeben werden.

#### 7.3.3 Flags

Flags zu Kommandos sollten in einer Variable mit dem Namen des Kommandos und der Endung FLAGS gekennzeichnet werden (s. Tabelle: Flag-Variablen)

Kommando | Flags | Beispiel | Bemerkung
--- | --- | --- | ---
AR | ARFLAGS | rv |
CC | CFLAGS | -g | Debug-Flag
CXX | CXXFLAGS |  |
CPP | CPPFLAGS | -DGERMAN |
FC | FFLAGAS |  |
LD | LDFLAGS | -lm | math. Bibliothek
LEX | LEXFLAGS |  |
MAKE | MAKEFLAGS | -k |
PC | PFLAGS |  |
YACC | YFLAGS | -v | Verbose-Flag

Abweichend von der obigen Namensgebung werden die Flags für den C-Compiler (CC) mit CFLAGS, für den Fortran-Compiler (FC) mit FFLAGS, für den Pascal-Compiler (PC) mit PFLAGS und für yacc (YACC) mit YFLAGS benannt. Dies hat historische Gründe.

#### 7.3.4 Lebenswichtige Flags

Optionen, die für die Kompilation bzw. Erzeugung des Ziels unbedingt notwendig sind, werden nicht in diesen Variablen abgespeichert.

Grund: Es sollte weiterhin möglich sein, Variablen über den make-Aufruf oder über Umgebungs-Variablen zu setzen, ohne dass die Kompilation schief läuft.

Beispiel:

    hugo.o : hugo.c
            $(CC) -c $(CPPFLAGS) $(CFLAGS) hugo.c

#### 7.3.5 Install-Variablen

Die Variable INSTALL muss in jedem Makefile definiert sein und zum Installieren von Dateien dienen.

Daneben sollten die Variablen INSTALL_PROGRAM und INSTALL_DATA definiert werden, die zur Installation von Programmen und Daten dienen. Der Standard-Wert dafür sollte $(INSTALL) sein.

Name | Standard | Anmerkung
--- | --- | ---
INSTALL | install |
INSTALL_PROGRAM | $(INSTALL) | Installation von Programmen
INSTALL_DATA | $(INSTALL) -m 644 | Installation von Daten

Für die Installation von Programmen und Dateien sollte immer der komplette Dateiname und nicht nur der Verzeichnisname verwendet werden.

Beispiel:

    install:
            $(INSTALL_PROGRAM) love $(bindir)/love
            $(INSTALL_DATA) loveletter $(datadir)/loveletter

#### 7.4 Installations-Verzeichnis

Installations-Verzeichnisse sollten immer in Variablen abgelegt werden, so dass sich die Installation auch leicht an andere Zielverzeichnisse anpassen lässt.

Standardnamen für solche Variablen werden in diesem Abschnitt beschrieben. Sie basieren auf Standard-Dateisystemen von SVR4, 4.4BSD, Linux, Ultrix V4 und anderer moderner Betriebssysteme.

#### 7.4.1 Root-Installations-Verzeichnis

Aus folgenden zwei Varablen sollten alle weitere Installations-Variablen abgeleitet werden:

prefix: | Diese Variable enthält das Basis-Verzeichnis.
exec_prefix: | Diese Variable enthält das Basis-Verzeichnis für einige ausführbare Programme. Als Standard-Wert enthält diese Variable den Wert von prefix.

Variable | Standard | Beschreibung
--- | --- | ---
bindir | $(exec_prefix)/bin | hier werden die ausführbaren Programme für den Benutzer abgelegt
sbindir | $(exec_prefix)/sbin | hier werden die Programme für den System Administrator abgelegt
libexecdir | $(exec_prefix)/libexec | hier werden die Programme abgelegt, die von anderen Programmen benötigt werden
datadir | $(prefix)/share | für Architektur-unabhängige Daten-Dateien, die nicht verändert werden (read-only)
sysconfdir | $(prefix)/etc | Konfigurations-Dateien (read-only), die zu einer Single-Maschine gehören
sharedstatedir | $(prefix)/com | Architektur-unabhängige Daten-Dateien, die vom Programm verändert werden können
localstatedir | $(prefix)/var | lokale Architektur-unabhängige Daten-Dateien, die vom Programm verändert werden können
libdir | $(exec_prefix)/lib | Objekt- und Bibliotheks-Dateien (keine ausführbaren Programme)
infodir | $(prefix)/info | Info-Dateien
lispdir | $(datadir)/emacs/site-lisp | Emacs-Lisp-Dateien
includedir | $(prefix)/include | Header-Dateien
mandir | $(prefix)/man | Verzeichnis für die Manpages
man1dir | $(mandir)/man1 | "1"er-Manpage
man2dir | $(mandir)/man2 | "2"er-Manpage
... | ... | ...
manext | .1 | Manpage Erweiterung
man1ext | .1 | "1"er-Manpage Erweiterung
man2ext | .2 | "2"er-Manpage Erweiterung
... | ... | ...
srcdir | - | Verzeichnis, in dem die Sourcen kompiliert werden

#### 7.5 Standard Targets

#### 7.5.1 Notwendige Targets

all | Kompilation des gesamten Programms (möglichst mit der Option "-g") sollte das Standard-Ziel sein
install | Kompilation und Installation des Programms, der Bibliotheken, usw...
uninstall | "install" wieder rückgängig machen
install-strip | Installation mit ge-"strip"-ten Programmen (strip entfernt die Symboltabelle aus einem Programm)
clean | Löschen aller Dateien, die beim Erstellen des Programms erzeugt werden
distclean | lösche alle Dateien, die nicht mehr benötigt werden
dist | Distributions-Tarfile erstellen; die Tar-Datei sollte ein Unterverzeichnis mit dem Werkzeugname und Versionsnummer enthalten, in dem sämtliche Programme und Dateien enthalten sind (zum Beispiel love-1.0.1)
check | Selbsttest (Überprüfung des Programms)

#### 7.5.2 Nützliche Targets

mostlyclean | wie "clean", ausser Bibliotheken und andere Dateien, die zeitintensiv zu erstellen sind
TAGS | Erstellen/Update einer Tags-Tabelle
info | Info-Dateien erstellen
installcheck | Installation von Test-Dateien und -Verzeichnissen, die für "check" benötigt werden
installdirs | Verzeichnisse, die für "install" erzeugt werden müssen