INE1 Präprozessor, Module

Transkript

1 INE1 Präprozessor, Module Prä(ääh)prozessor, Compiler und Linker, Lader Der Präprozessor Bedingte Übersetzung Modulare Programmierung Anhang: make-utility 1

2 Präprozessor, Compiler, Linker, Lader 2 von 75

3 Direkt ausführbarer Code vs Virtuelle Maschinen C/C++ Programmquelle wird in EXE/DLL übersetzt (Maschine Code) um dann direkt ausgeführt zu werden Ausführbare Einheiten Bestehen aus (Maschinen-)Code Werden durch Funktionen des jeweiligen Betriebssystems unterstützt Unterschied Java/C# (später) Programmquelle wird in.class File (sog. VM Code) übersetzt und dann anschliessend durch VM ausgeführt Ausführbare Einheiten Bestehen aus Code der von VM ausgeführt wird; VM läuft auf verschiedenen Plattform Werden durch ein umfangreiches Laufzeitsystem (Virtual Runtime Environment: VRE) unterstützt 3 von 75

4 Übersetzungs-/Ausführungsvorgang Übersetzung/Ausführung in vier Phasen 1. Präprozessor: textuelle Vorverarbeitung 2. Erzeugung von Maschinen-Code (Linkbare-Einheiten): Compilation 3. Erzeugung von ausführbaren Einheiten (.exe): Linking 4. Ausführung C-Quellen Dateien.c,.h Linkbare Einheiten.obj Ausführbare Einheiten.exe Compilation Linking normalerweise normalerweise nicht nicht an an Zwischenprodukt Zwischenprodukt interessiert interessiert 4 von 75

5 Präprozessor, Compiler, Linker, Lader 1. Der Präprozessor sucht in den Quelltexten nach speziellen Befehlen, um dann im wesentlichen textuelle Ersetzungen durchzuführen 2. Der Compiler wandelt den so geänderten Code in Objektcode um, der aber noch offene Aufrufe enthält 3. Der Linker verbindet die noch offenen Funktionsaufrufe mit den zugehörigen Funktionen 4. Der Lader lädt das Programm mit den Abhängigkeiten (Windows.DLL) in den Speicher und startet die "main" Funktion 5 von 75

6 Die 3 Phasen der Übersetzung Übersetzung von C/C++ in 3 Phasen 1. Phase: Präprozessor (rein textuelle Substitutionen) Präprozessor Direktiven alle mit # Beispiele: #define PI #include <stdio.h> 2. Phase: Übersetzung in Maschinencode obj-dateien: (linkbare Einheit) 3. Phase: Linken der Teile zu ausführbarem Programm 6 von 75

7 Phase 1: Erzeuge Quelle für Compilation Vorverarbeitung (1. Schritt) stdio.h hello.c #include<stdio.h> #include "hello.c" int main () { } Präprozessor Compilation 7 von 75

8 Phase 1: Präprozessor-"Direktiven" Anwendung Definition von Konstanten Einbeziehen von anderen Quellen (Header Files) Ein-/Ausblenden von Blöcken (z.b. Debug Code) #define PI #include "filename" /* from the current directory */ #include <filename> /* from the system directories */ #define DEBUG /* defines the symbol DEBUG */ #ifdef DEBUG /* code here is compiled if DEBUG is defined */ #elif defined UNIX /* code here is compiled if DEBUG is not defined, and UNIX is defined */ #else /* code here is compiled if neither DEBUG or UNIX are defined */ #endif #ifndef DEBUG /* test if symbol is not defined */ #undef DEBUG /* undefines a symbol */ 8 von 75

9 Phase 1: Logische Aufteilung in C und H Files C Files C-Programmquellen ->.c H(eader)-Files ~ "Dateien mit Funktionsdeklarationen" ->.h Sammlungen von vordeklarierten (Prototyp-) Funktionen (keine Implementationen!) Definition von allgemein verwendeten Typen und Konstanten System Header Files Beschreibung der Schnittstelle zu Betriebssystem und Bibliotheken (Funktionsprototypen) Beispiele stdio.h : Standard Ein/Ausgabe string.h : String Funktionen Eigene Header-Files zur besseren Strukturierung des Programms 9 von 75

10 Phase 2: Compiler Der Compiler bekommt den vom Präprozessor überarbeiteten Quelltext und setzt ihn in einen Objektcode um Objektcode Maschinen-Code Nicht ausführbar, da noch unaufgelöste Referenzen (z.b. Bibliotheks-Funktionsaufrufe) enthalten sind Meistens mit der Endung.o oder.obj 10 von 75

11 Phase 2: Weitere Aufgaben des Compilers Prüfung auf syntaktische und grammatische Fehler Statische Typprüfung Teilweise Warnung für logische Fehler Anlegen von Tabellen, in denen Buch über die verwendeten Variablen geführt wird 11 von 75

12 Phase 3: Linker Linkbare Einheiten (.obj) werden zu ausführbaren Einheit (exe,dll) zusammengebunden ("linken") C-Compilation hello.obj 33 Assembler baba.obj 3 3 Linking hello.exe main() Pascal- Compilation tatu.obj 3 3 Linking tatu.dll foo() 12 von 75

13 Phase 3: Linker Setzt die vom Compiler generierten Objektmodule zu einem ausführbaren Programm zusammen (EXE) Sucht nach Funktionsaufrufen und den dazugehörigen Funktionen Überprüft, ob alle Variablen, die nur deklariert wurden (extern, s.u.), auch irgendwo definiert sind Es gibt zwei Varianten von Linking statisch: der Bibliotheks Code wird in das EXE hinein gepackt dynamisch: der Bibliotheks Code wird nur als externe Referenz vermerkt und der Lader löst dann diese auf Nach dem Linken: ausführbares Programm 13 von 75

14 Phase 3: Einbinden der Standard-Bibliotheken Der Linker sucht auch in speziellen Dateien, den Bibliotheken, um alle Referenzen aufzulösen in Windows: Bibliotheken in sog. DLL Dateien in Linus: in sog..so Dateien In C: eine Bibliothek ist eine Sammlung von Funktionen Der Linker sucht in der Standard-Bibliothek nach allen verwendeten Funktionen Für C sind eine Reihe Standard-Bibliotheken vorgegeben Zusätzliche Bibliotheken müssen beim Linken angegeben werden 14 von 75

15 Phase 4: Ausführung/Lader Bringe ausführbare Einheiten zur Ausführung. Lädt EXE und davon abhängige DLLs in den Speicher springt zu Einsprungstelle (main) Teil Teil des des Betriebssystems Betriebssystems hello.exe 4 4 Lader c:> tatu.dll von 75

16 Überblick Übersetzungs-/Ausführungsvorgang Präprozessor C-Compilation Linker Lader hello.c 1 1 hello.pre 2 2 hello.obj 3 3 hello.exe hello.h Assembler baba.obj 3 tatu.dll baba.asm 2 16 von 75

17 Der Präprozessors 17 von 75

18 Präprozessor Wichtig bei allen Präprozessorbefehlen ist: Sie führen textuelle Änderungen am Quellcode aus Präprozessorbefehle werden auch Direktiven genannt Wird i.d.r. nicht separat ausgeführt Ist Teil des C Compilers Kann via Kommandozeile aber aufgerufen werden gcc -E... -E -E Stop Stop after after the the Präprocessing Präprocessing stage; stage; do do not not run run the the compiler compiler proper. proper. The The output output is is in in the the form form of of Präprocessed Präprocessed source source code, code, which which is is sent sent to to the the standard standard output. output. 18 von 75

19 Warum ein Präprozessor? Ursprünglich: Code kompakter und lesbarer machen Aber: Man kann damit auch schwer zu findende Fehler in den Code einbauen... In späteren C Versionen wurden Sprachmittel eingeführt, mit denen sich viele Präprozessor-Befehle vermeiden lassen z.b. Konstanten nicht mehr mit #define 19 von 75

20 Präprozessor Der Präprozessor hat folgende Aufgaben: Dateien in andere einfügen Konstanten definieren Makros zur Verfügung stellen Teile des Quelltextes selektieren #include #define #define #ifdef, #ifndef 20 von 75

21 Präprozessor-Befehle Beispiel: #include "dateiname" Der Präprozessor arbeitet zeilenorientiert Bei einer Präprozessor-Anweisung das Zeichen "#" vorangestellt sein Kein Semikolon am Ende! 21 von 75

22 Dateien einbinden Befehl: #include Beim Einfügen der Datei wird der Quelltext der Datei eingefügt Meistens verwendet um Konstanten, Deklarationen von Typen und Funktionen (Prototypen) in einen Quelltext einzubinden Zwei Varianten: #include <Dateiname> #include "Dateiname" Erste Variante für das Einbinden von Header-Dateien aus Standard-Bibliotheken (in einem speziellen "Standard-Verzeichnis" abgelegt) Zweite Variante für projektspezifische Header-Dateien 22 von 75

23 Konstanten definieren Befehl #define Beispiel: #define MAXLOOP Über diese Anweisung können auch Ersetzungen durchgeführt werden Wird der Name irgendwo im Programmcode gefunden, wird an dieser Stelle der Ersetzungstext eingefügt, ausgenommen in Zeichenketten und Kommentaren 23 von 75

24 Konstanten definieren Was durch define definiert wird, wird im allgemeinen als Makro bezeichnet Ein Makro ohne Parameter wird auch als symbolische Konstante bezeichnet Wenn der Makroname in einem String-Literal auftaucht, wird er nicht ersetzt Konvention: Namen von symbolischen Konstanten gross schreiben 24 von 75

25 Konstanten definieren Beispiel Verwendung #define ANZAHL 10 /* meistens besser: */ int feld [ANZAHL]; int j = ANZAHL; const int ANZAHL=10; /* oder: */ enum {ANZAHL=10 }; 25 von 75

26 Konstanten definieren Wichtig: Der Präprozessor ersetzt diese Symbole rein textuell Auf diese Weise können durch den Präprozessor auch leicht Fehler in den Code eingebaut werden: #define I 10 int I = 20; /* wird zu: int 10 = 20; */ 26 von 75

27 Beispiel $ cpp prep.c # 1 "prep.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "prep.c" int main() { double p = 3.14; // 3.14 char tx2[] = "drei"; char tx1[] = "abc ZAHL TEXT de"; return 0; } 27 von 75

28 Vordefinierte Konstanten FILE zwei zwei Underscores Underscores Name der Datei, die gerade übersetzt wird DATE Datum des Übersetzungsvorgangs TIME LINE STDC cplusplus cdecl Uhrzeit, zu der der Übersetzungsvorgang gestartet wurde Aktuelle Zeile der Datei, in der der Compiler sich gerade befindet Erfüllt, wenn im Standard-C Modus übersetzt wird Es wurde mit einem C++ Compiler compiliert Verwende die C Aufruf Konvention 28 von 75

29 Vordefinierte Konstanten /* Ausgabe der Dateiversion: */ printf("version vom %s um %s von %s\n", DATE, TIME, FILE ); /* Ausgabe der Zeile bei Fehlern: */ if (nenner == 0) { printf("schwerer Fehler (Division durch Null) in " "%s, Zeile %s\n", FILE, LINE ); exit(1); } 29 von 75

30 Makros In der #define-direktive können nach dem Namen des Symbols auch zusätzliche Parameter in Klammern angegeben werden Diese können im zu ersetzenden Text wieder auftauchen, wo sie dann textuell eingesetzt werden #define MAKRO(Argl, Arg2,...) Ersetzungstext Hinter dem Makronamen darf kein Leerzeichen folgen 30 von 75

31 Makros Es kann vorkommen, dass eine Anweisung nicht in eine Zeile passt Dann wird das Fortsetzungszeichen "\" verwendet Beispiel: #define ALERT(meintext) \ printf("###########################"); \ printf("%s", meintext); \ printf("###########################"); 31 von 75

32 Beispiel $ cpp makro.c # 1 "makro.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "makro.c" int main() { int k = 3, m = 34; double f = 3.1, g = 4.4; {int j; j=k; k=m; m=j; }; printf("getauscht!"); {int j; j=f; f=g; g=j; }; } return 0; 32 von 75

33 Makros: Probleme Mit Makros ist Vorsicht angebracht, da leicht Fehler eingebaut werden können Beispiel: #define Quadrat(x) x*x Quadrat(5+3); /* ergibt 5+3*5+3 = 23 statt 64 */ Besser die Argumente von Makros in Klammern schreiben: #define Quadrat(x) ((x)*(x)) 33 von 75

34 Makros: Probleme Noch besser: Man sollte Funktionen vorziehen, da Fehler, die über Makros entstehen, schwerer zu finden sind In C99 und C++ können Präprozessor-Konstanten und -Makros meistens besser durch const und Inline-Funktionen (C++) realisiert werden "Almost every macro demonstrates a flaw in the programming language, in the program, or in the programmer." (Bjarne Stroustrup) 34 von 75

35 Bedingte Übersetzung 36 von 75

36 Konstanten abfragen Es ist nicht nötig, einem solchen Symbol auch einen Wert zuzuweisen Auch eine Definition ohne Wert kann sinnvoll sein, da abgefragt werden kann, ob ein Symbol definiert ist oder nicht Befehle: #ifdef #ifndef #undef Test, ob Symbol definiert Test, ob Symbol nicht definiert Danach ist Symbol nicht (mehr) definiert 37 von 75

37 Bedingte Übersetzung Man kann den Präprozessor auch dazu nutzen, Teile des Quelltextes zu selektieren Verhindern einer mehrfachen Übersetzung Selektieren von Debugging-Code Plattform übergreifende Programmierung Präprozessorbefehle für diese Funktionen: #ifdef und #ifndef Beide werden mit #endif abgeschlossen Nach #else kann ein Alternativzweig angegeben werden 38 von 75

38 Mehrfache Übersetzung/Includes verhindern Beim Einbinden von Quelltexten (meist Header-Files) mit #include muss verhindert werden, dass gleiche Dateien mehrmals eingefügt werden Grund: Mehrfache Definitionen sind nicht zulässig Dazu wird folgende Struktur verwendet (im Header File): #ifndef c_h c.h #ifndef Dateikennung #define Dateikennung // Code #endif #include "c.h" a.h #include "c.h" b.h #include "a.h" #include "b.h" main.c 39 von 75

39 Mehrfache Übersetzung/Includes verhindern Dateikennung ist ein Kürzel, das in der Regel aus dem Dateinamen zusammengesetzt wird Aus Dateinamen wie "meinedatei.h" wird zum Beispiel eine Dateikennung wie "MEINEDATEI_H" #ifndef MEINEDATEI_H #define MEINEDATEI_H // Code #endif 40 von 75

40 Mehrfache Übersetzung/Includes verhindern #include "meinedatei.h" #include "meinedatei.h" int main (void) { //... } #ifndef MEINEDATEI_H #define MEINEDATEI_H // Code #endif #ifndef MEINEDATEI_H #define MEINEDATEI_H // Code #endif int main (void) { //... } 41 von 75

41 Selektieren von Debugging-Code Einfache Möglichkeit, zusätzlichen Code zur Fehlersuche mit in den Quelltext aufzunehmen, um ihn je nach Bedarf mit übersetzen zu lassen oder nicht Anweisungen werden nur in den übersetzten Code übernommen, wenn die Konstante beim Präprozessorlauf definiert ist Die Konstante kann dann am Anfang des Programmcodes oder über eine Option beim Compileraufruf definiert werden Beim gcc: -Dname bzw. -Dname=wert Oder in den Projektoptionen der IDE 42 von 75

42 Selektieren von Debugging-Code Erkennung ob Debug Code aktiviert werden soll mittels DEBUG Lässt man oft in der Quelle für spätere Fehlersuche stehen #ifdef DEBUG printf("initialisierung abgeschlossen.\n"); #endif 43 von 75

43 Plattformabhängigkeiten Quelltext für mehrere Prozessoren, Betriebssysteme, graphische Oberflächen o.ä. gleichzeitig zur Verfügung stellen #ifdef GCC /* systemspezifischer Code für GNU-Compiler */ #endif #ifdef sun /* systemspezifischer Code für Sun-Compiler */ #endif #ifdef _MSC_VER /* systemspezifischer Code für Visual-Studio */ #endif 44 von 75

44 Modulare Programmierung 45 von 75

45 Ziele Modulare Programmierung Gleichzeitige Bearbeitung/Entwicklung durch mehrere Entwickler Kürzere Einarbeitungszeit von neuen Entwicklern Nach Änderungen müssen nur Teile eines Projekts neu übersetzt werden Teile eines Projekts können in anderen Programmiersprachen geschrieben werden Klare Strukturierung des gesamten Programms Verbesserung der Wiederverwendbarkeit Gute Modularisierung ist der Schlüssel für erfolgreiche Projekte. Ohne Modularisierung droht jedes Projekt früher oder später an der Komplexität zu scheitern. 46 von 75

46 Prinzipien der Modularisierung Geringe Vernetzung (wenig Schnittstellen) Schwache Kopplung zwischen Modulen (schmale Schnittstellen) Hohe Kohäsion innerhalb Modul (inhaltliche Einheit) Explizite Schnittstellen (Kommunikation mit Parameterübergabe) Information Hiding (Verstecken der Implementationsdetails) 47 von 75

47 Zwei Stufen der Modularisierung in C 1. Stufe: Lediglich die Quellen werden modular strukturiert Die für andere Quellen verwendbare Funktionen werden in Header Files als Prototypen definiert Für die Verwendung dieser Quellen wird in andern Quellen lediglich dieses Header File included Alle benötigten Quellen werden dann vom Compiler/Linker zu einem fertigen Programm (EXE) zusammen gefügt: "statische Bibliotheken". 2. Stufe: Zusätzlich werden die Laufzeiteinheiten modularisiert Aus den Bibliotheken werden DLLs erzeugt Diese DLLs werden dann zur Laufzeit vom Lader automatisch (nach-)geladen als sog. "dynamische Bibliotheken". 48 von 75

48 Statische Bibliotheken 49 von 75

49 Source- und Headerfiles Die Deklarationen werden in Header Files durchgeführt Sie enthalten die Prototypen der "von aussen sichtbaren" Funktionen Header Files sind Deklarationsdateien die sowohl ins definierende als auch ins aufrufende Modul eingebunden werden Header Files sind somit die Schnittstellenbeschreibung der Module Diese Header-Datei wird so abgelegt, dass der Präprozessor (mittels #include) sie findet #ifndef a_h a.h #include "a.h" #include "a.h" a.c b.c 50 von 75

50 Source- und Headerfiles Soll in einem anderen Modul die Funktion globalfunct verwendet werden, muss diese dort mit Hilfe eines prototypen deklariert werden Dasselbe gilt für die globale Variable globalvar auch sie muss im anderen Modul vor der ersten Verwendung deklariert werden Bei Funktionen einfach der Prototyp der Funktion im Header File void foo(); /* Deklaration */ Bei Variablen wird zusätzlich das Schlüsselwort extern verwendet extern int globalvar; /* Deklaration */ 51 von 75

51 Source- und Headerfiles /* --- Deklaration A */ /* Datei: modul_a.h */ #ifndef MODUL_A_H #define MODUL_A_H extern int globalvar; /* fuer alle */ int globalfunct(int a); /* fuer alle */ #endif 52 von 75

52 Source- und Headerfiles /* --- Modul A */ #include "modul_a.h" /* Definitionen */ int globalfunct(int a) {... } /* fuer alle */ static int lokalfunct(int a) {... } /* nur hier */ int globalvar = 24; /* fuer alle */ static int localvar; /* nur hier */ 53 von 75

53 Source- und Headerfiles /* --- Modul B */ #include "modul_a.h" /* Aufruf der Funktion aus Modul A */ int result = globalfunct(42); /* Zugriff auf die Variable aus Modul A */ int var = globalvar; 54 von 75

54 Sichtbarkeit von Funktionen Funktionen können nur auf der äussersten Ebene eines Moduls definiert werden Standardmässig gilt eine Funktion als global das bedeutet, dass ihr Name an den Linker weitergegeben wird Eine Einschränkung der Sichtbarkeit auf das aktuelle Modul ist mit Hilfe des Schlüsselworts static möglich int globalfunct(int a) {... } /* fuer alle */ static int lokalfunct(int a) {... } /* nur hier */ 55 von 75

55 Sichtbarkeit von Variablen Standardmässig sind alle Variablen global, die auf der äussersten Ebene definiert werden Eine Einschränkung der Sichtbarkeit ist ebenfalls mit Hilfe des Schlüsselworts static möglich int globalvar; // fuer alle static int localvar; // nur hier Lokal ist hier nicht im Sinne von lokal in einer Funktion sondern im Sinne von lokal in einem Modul (Dateiebene) gemeint 56 von 75

56 Dynamische Bibliotheken 57 von 75

57 Dynamische Bibliotheken Dynamische Bibliotheken müssen speziell erzeugt werden unter Windows mit der Endung DLL Betriebssystem selber besteht aus einer Sammlung von DLLs Sie stellen dem Linker (über Libs) die Funktionen zur Verfügung, Es wird nicht die Funktion sondern lediglich ein Vermerk (Referenz) gespeichert Der Lader löst die Referenz dynamisch auf und lädt die benötigten DLLs nach Suchpfad für die DLLs ist aktuelles Verzeichnis und zusätzlich alle in der "PATH" Umgebungsvariablen vermerkte Dependency Walker zur Anzeige Dependency Walker zur Anzeige der Abhängigkeiten der Abhängigkeiten 58 von 75

58 Export mit declspec(dllexport) Exportierte Funktionen müssen speziell gekennzeichnet werden #define DLL_EXPORT declspec(dllexport) Von andern Modulen importierte ensprechend #define DLL_EXPORT declspec(dllimport) Die Aufrufkonvention muss cdecl sein Am einfachsten mit einem Define (z.b. _DLL), das man über das Projekt setzt #ifdef _DLL // If accessing the data from inside the DLL #define DLL_EXPORT declspec(dllexport) #else // If accessing the data from outside the DLL #define DLL_EXPORT declspec(dllimport) #endif cdecl void DLL_EXPORT foo(void); Die exportierten Funktionen sind im LIB File gespeichert 59 von 75

59 Übersetzung im Überblick Compilierung der Bibliothek und Klient und Ausführen DynLib.h #include #include Compiler Namen Namen der der DLL DLL vermerkt vermerkt DynLib.dll DynLib.c Beim Compilieren Beim Compilieren wird das h File Beim wird das h File Beim Linken Linken wird wird included das included das lib lib File File gebunden gebunden DynLib.lib Beim Beim Laden Laden wird wird die die referenzierte referenzierte DLL DLL (mit-)geladen (mit-)geladen Lader TestClient.c Compiler TestClient.exe 60 von 75

60 DynLib.h #ifndef DYNLIB1_H #define DYNLIB1_H #ifdef _DLL // If accessing the data from inside the DLL #define DLL_EXPORT declspec(dllexport) #else // If accessing the data from outside the DLL #define DLL_EXPORT declspec(dllimport) #endif #ifdef cplusplus extern "C" { #endif void cdecl DLL_EXPORT foo(void); #ifdef } #endif cplusplus #endif /* DYNLIB1_H */ 61 von 75

61 DynLib.c und TestClient.exe Implementation der Library #include "DynLib1.h" #include <stdio.h> void cdecl foo() { printf("hello World\n"); } Und Aufruf von foo() in TestClient (separates EXE) #include <stdio.h> #include <stdlib.h> #include "DynLib1.h" int main(int argc, char** argv) { foo(); return (EXIT_SUCCESS); } 62 von 75

62 Weiterer Vorteil von dynamischen Bibliotheken C-Bibliotheken lassen sich von praktisch jeder Programmiersprache aus aufrufen Z.B. können GUIs mit Java (oder C#) entwickelt werden einfacher plattformunabhängig sehr gute Werkzeuge vorhanden (sog. GUI Builder) Der Aufruf der C Bibliotheksfunktion in Java dann via JNI oder JNA (später) 63 von 75

63 Noch Fragen? 64 von 75

64 make-utility 65 von 75

65 Das make-utility Jedes etwas grössere Programm setzt sich aus einer ganzen Reihe von Dateien zusammen Schon bei Veränderungen einer Datei kann es nötig sein, mehrere Module neu zu übersetzen Wird z.b. ein Header-File verändert, so sollten alle Quelltextfiles, die dieses Header-File einbinden, neu übersetzt werden Bei grossen Projekten kann das schnell sehr unübersichtlich werden 66 von 75

66 Das make-utility Das Utility make hilft dabei, ein Programm aus mehreren Modulen unter Berücksichtigung der Abhängigkeiten zu erstellen Hinweis: Das frei verfügbare und im Funktionsumfang bedeutend erweiterte GNU-Make trägt meist den Namen gmake Beim Aufruf arbeitet make die Regeln einer im aktuellen Verzeichnis liegenden Makefile-Datei ab 67 von 75

67 Makefile Ein Makefile enthält die Regeln, wann, was und wie es auszuführen ist Es besteht aus: Kommentaren, beginnend mit # Direktiven Variablendefinitionen Expliziten Regeln 68 von 75

68 Makefile Eine Regel ist wie folgt aufgebaut: Target: Was zu erstellen ist target: dependencies <TAB> command Dependencies: Legen fest, wann das zu geschehen hat, nämlich wenn eines von ihnen jünger ist als target Command: Das oder die abzuarbeitenden Kommandos; wichtig ist der Tabulator am Zeilenanfang Da als dependencies auch andere targets angegeben werden können ist eine Verschachtelung der Regeln möglich 69 von 75

69 Makefile Beispiel Das Programm rechner wird aus den Modulen main.o, add.o, sub.o, mul.o sowie div.o gebildet Alle Quelltextfiles nutzen das gemeinsame Headerfile def.h Nach Änderungen an def.h sollten also auch alle Quelltextfiles neu übersetzt werden. 70 von 75

70 Makefile Beispiel # Ausschliesslich explizite Regeln # # rechner wird aus den Objektfiles (.o) zusammengebaut: rechner: add.o sub.o mul.o div.o main.o cc -o rechner add.o sub.o mul.o div.o main.o # Objektfiles loeschen clean: rm -f *.o rechner Forts von 75

71 Makefile Beispiel # Und so entstehen die.o-files (def.h sowie Makefile # werden angegeben, um auch bei Veraenderungen daran # die Übersetzung zu starten): add.o: add.c def.h Makefile cc -c add.c sub.o: sub.c def.h Makefile cc -c sub.c mul.o: mul.c def.h Makefile cc -c mul.c div.o: div.c def.h Makefile cc -c div.c 72 von 75

72 Makefile Beispiel Mit Hilfe von Variablen lassen sich Regeln einfacher ändern (vor allem, wenn sie an mehreren Stellen benötigt werden) Beim Aufruf von make lassen sich auch Variablenzuweisungen übergeben diese haben höhere Priorität als die Festlegungen im Makefile Man muss nicht alle Regeln und Variablen angeben make verwendet dann seine Voreinstellungen 73 von 75

73 Makefile Beispiel # Variante mit Variablen, impliziten Regeln und # gmake's Pattern-Regeln OBJS = add.o sub.o mul.o div.o main.o CC = gcc CFLAGS = -g rechner: $(OBJS) $(CC) $(CFLAGS) -o rechner $(OBJS) clean: rm -f *~ *.o rechner $(OBJS): %.o: %.c def.h Makefile $(CC) $(CFLAGS) -c $< -o $@ Inference Rule: xyz.o depends on xyz.c, def.h and Makefile The source file of the current dependency Full name of the current target 74 von 75

74 Anhang: Calling Convention und Name Decoration Der Name wird anhand der Aufrufkonvention "dekoriert" 75 von 75