GNU make, 3rd Edition

This is the Title of the Book, eMatter Edition

Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.

|

143

First

Max.

Linie

Max.

Linie

Kapitel 7

KAPITEL 7

Portable Makefiles

Was verstehen wir unter einem portablen Makefile? Im Extremfall meinen wir damit ein

Makefile, das ohne Änderungen auf jedem System läuft, für das es GNU

make gibt. In der

Praxis ist das natürlich angesichts der Vielzahl unterschiedlicher Betriebssysteme nahezu

unmöglich. Eine sinnvollere Definition lautet daher: Ein portables Makefile ist mit gerin-

gen Änderungen an jede neue Plattform adaptierbar. Auf den folgenden Zusatz legen wir

dabei Wert: Wenn das Makefile an ein neues Betriebssystem angepasst wird, dann soll

das so geschehen, dass die neue Version nach wie vor auf den Betriebssystemen verwend-

bar ist, auf denen das auch für die alte Version galt.

Dieser Grad an Portabilität eines Makefiles kann nur mit den Techniken erreicht werden,

die wir schon aus der traditionellen Programmierung kennen: Kapselung und Abstrak-

tion. Durch den Einsatz von Variablen und benutzerdefinierten Funktionen können wir

Anwendungen und Algorithmen kapseln. Die Einführung von Variablen für Kommando-

zeilenargumente und Parameter ermöglicht eine Abstraktion von Elementen, die sich von

Plattform zu Plattform unterscheiden, hin zu Elementen, die konstant sind.

Zunächst sollte man aber darüber nachdenken, welche Tools man einsetzt. Nicht alle

Tools sind auf jeder Plattform vorhanden. Im Extremfall schafft man es, sich nur auf

Werkzeuge und Fähigkeiten zu stützen, die auf allen Zielplattformen vorhanden sind.

Man bezeichnet dies als Ansatz des »kleinsten gemeinsamen Nenners«. Aus nahe liegen-

den Gründen stehen einem in diesem Fall nur relativ primitive Funktionalitäten zur Ver-

fügung.

Eine andere Version des kleinsten gemeinsamen Nenners ist es, sich auf Tools zu stützen,

die man unter Umständen auf die jeweilige Zielplattform mitbringen kann. Der offen-

sichtliche Vorteil besteht darin, dass sich diese Tools auf allen Plattformen gleich verhal-

ten. Das kann natürlich zu Problemen administrativer Art führen. Insbesondere gibt es

Firmen, die ein gewisses Setup vorgeben und bei denen die Installation weiterer Software

nicht erwünscht ist. Wenn man diese Probleme gelöst hat, ist dies aber ein durchaus

sinnvoller Ansatz, wie ich später noch mit dem Cygwin-Paket unter Windows vorführen

werde. Wir werden dabei auch sehen, dass die Standardisierung von Werkzeugen das

Problem nur zum Teil löst: Letzten Endes gibt es immer irgendwelche Eigenheiten des

Betriebssystems, die man berücksichtigen muss.

This is the Title of the Book, eMatter Edition

Copyright © 2005 O’Reilly & Associates, Inc. All rights reserved.

144

|

Kapitel7: Portable Makefiles

Links

Max.

Linie

Max.

Linie

Die letzte Möglichkeit besteht darin, die Unterschiede zwischen den verschiedenen Syste-

men zu akzeptieren und durch eine sorgfältige Programmierung von Makros und Funkti-

onen zu umgehen. Auch auf diesen Ansatz werden wir in diesem Kapitel noch zu spre-

chen kommen.

Zusammenfassend können wir durch vernünftigen Einsatz von Variablen und benutzer-

definierten Funktionen, durch Vermeidung exotischer Features und standardisierte

Werkzeuge die Portabilität eines Makefile deutlich erhöhen. Wie schon erwähnt, wird es

niemals so etwas wie perfekte Portabilität geben. Wir müssen einen Kompromiss zwi-

schen dem nötigen Aufwand und der erreichten Portabilität eingehen. Bevor wir uns den

einzelnen Techniken widmen, wollen wir aber zunächst die typischen Portabilitätspro-

bleme eines Makefile betrachten.

Portabilitätsprobleme

Es fällt schwer, Portabilitätsprobleme zu charakterisieren, weil es sich dabei um so ver-

schiedene Dinge handeln kann wie einen vollkommen anderen Ansatz des Betriebssys-

tems (etwa klassisches Mac OS verglichen mit Unix System V) oder nahezu triviale Feh-

lerkorrekturen. Mit den folgenden Fragen beschäftigt man sich aber in jedem Makefile

früher oder später:

Programmnamen

Selbst wenn die eingesetzten Programme gleich oder ähnlich sind, ist damit noch

lange nicht gesagt, dass sie auf verschiedenen Plattformen denselben Namen tragen.

Das beste Beispiel dafür ist der C- bzw. C++-Compiler (z.B.

cc, gcc, xlc). Auch die

GNU-Versionen verschiedener Programme heißen oft anders, zum Beispiel findet

man oft das Präfix g (

gmake, gawk).

Pfade

Auch die Pfade (also die Verzeichnisnamen), anhand derer man Programme und/

oder andere Dateien findet, unterscheiden sich. Zum Beispiel findet man unter Sola-

ris das X11-System unter /usr/X, anderswo sind /usr/X11 oder /usr/X11R6 üblich.

Auch die Unterscheidung zwischen /bin, /usr/bin, /sbin und /usr/sbin ist oft recht un-

scharf.

Optionen

Die Kommandozeilenoptionen der eingesetzten Programme unterscheiden sich. Das

gilt besonders dann, wenn es sich um unterschiedliche Implementationen handelt.

Wenn ein Hilfsprogramm auf einer Plattform fehlt oder mit Fehlern behaftet ist,

muss man sich oft auf eine Alternative mit anderen Optionen stützen.

Fähigkeiten der Shell

Standardmäßig verwendet

make zum Aufruf von Kommandos die Shell /bin/sh. Die

Fähigkeiten von

sh unterscheiden sich aber drastisch je nach Implementation. Insbe-

sondere Shells aus den Zeiten vor POSIX sind oft recht eingeschränkt und akzeptie-

ren gelegentlich eine ganz andere Syntax als eine moderne Shell.