Hallo Leute,
also ich bin kein totaler Anfänger, ich bastl und programmier schon seit
paar Jahren. Aber eine Sache hat sich mir immer verschlossen, da ich nur
mit schönen bunten IDEs gearbeitet habe: Makefiles
Ich weis wofür sie gut sind, hab schon paar mal (versucht) welche
nachzuvollziehen aber hab noch NIE eines geschrieben.
Dabei frag ich mich dauernd - Wozu die Dinger? (wahrscheinlich weil ich
doch was nicht ganz verstanden habe)
Ich bekomm den Brückenschlag zwischen einer IDE und Makefiles nicht hin.
In der IDE sehe ich im jeweiligen Projekt alle Dateien, die zum Programm
gehören und kompiliert werden. Ein paar werden noch von externen
Verzeichnissen eingebunden zB. io.h
Wenn ich im AtmelStudio auf "Build" klicke, erstellt dann die IDE ein
makefile entsprechend den Dateien die zum Projekt gehören, und ruft dann
"make all" auf???
THEMA DEBUGGEN:
ich weis, dass man den Buildvorgang auch aus der Komandozeile starten
kann und hab ich auch schon paarmal gemacht. Aber debuggen geht ja dann
nicht mehr oder? *.hex ist fertig, wird drauf geflasht und dann tut der
Controller oder tut eben nicht.
Das heist für mich: Wenn ich mit Makefiles arbeite kann ich nicht
debuggen -> Makefiles sind böse. ABER warum arbeiten dann nahezu alle,
die bisl besser programmieren können mit Makefiles?? Programmieren die
keine Fehler und müssen deshalb nicht debuggen? ;-)
Kann bitte jemand bisl Licht ins Dunkle bringen
Gruß Stefan
Anfänger schrieb:> Kann bitte jemand bisl Licht ins Dunkle bringen
Erst mal nur ein wenig:
Makefiles sind eigentlich ScriptDateien mit Anweisungen wie DOS/Windows
.BAT. Als Besonderheit enthalten sie Abhängigkeiten der Art "wenn das
Sourcefile jünger ist als das Objectfile, wirf den Compiler an, um das
Objectfile neu zu erzeugen". Das spart Arbeit, weil immer nur das
ausgeführt wird, was nach Änderungen nötig ist (vorausgesetzt, das
Makefile ist korrekt - das ist eine Aufgabe für sich). Bemerkbar macht
sich die Ersparnis aber nur bei grossen Projekten, bei einem Embedded
System kann man auch einfach alles neu machen (= Build All), und dafür
könnte man sich auch ein normales BAT-File schreiben. So ein Build hat
früher mal Stunden gebraucht (mit Lochstreifen), dann Minuten, und heute
noch so 1..2 Sekunden.
Ein Vorteil bei direkter Bearbeitung des Makefiles ist, dass man
Zwischenschritte einplanen kann, die die IDE garnicht vorsieht - ich
habe zum Beispiel eine Software geschrieben, die Standard-Texte durch
eine andere Sprache ersetzt, die macht dann aus einer internationalen
Datei eine russische oder spanische, und wird im Makefile als allerstes
aufgerufen, wenn diese Datei verändert wurde.
Mit dem Debugger hat das so gut wie nichts zu tun, beim Debuggen ist das
Programm immer fertig und geladen. Nur ist meistens zum Debuggen eine
besondere Ausführung der Übersetzung nötig, so dass z.B. die
Zeilennummern des Programms in irgendeiner Form enthalten sind - die
kann der Debugger dann lesen und damit den Cursor in der entsprechenden
Source-Datei setzen. In einer IDE muss man zwischen Debug-Version und
Release-Version wählen.
Das ist bequem aber nicht inbedingt nötigt, Hardcore-Progarmmierer
können auch debuggen mit nichts als dem Programm im Speicher und dem
Listing auf dem Tisch.
Gruss Reinhard
Die Antwort aus meiner Sicht auf die Frage ist ganz einfach. Die
Industrie glaubt nicht, dass es einen nennenswerten Markt für einen
guten Debugger ohne den restlichen Kram der IDEs gibt. Eigentlich ja nur
ein vernünftiges Frontend für den gdb der in der Regel überall verwendet
wird. Die Opensource Lösungen decken den Controllerbereich nicht richtig
ab und die Klötze wie Eclipse oder Netbeans sind nur zum Debuggen
einfach zu fett. Auch in einem Debugfrontend steckt eine Menge Arbeit
wenn man viele verschiedene Controller und deren Perepherie unterstützen
will. Wenn man sich einmal mit den makefiles richtig beschäftigt hat und
unter vielen verschiedenen Systemen oder Controllerfamilien arbeitet,
lernt man die vielen IDEs hassen. Man hat sich dann für einen guten
Editor entschieden und schreibt Programme für Windows,Linux, Controller
u.s.w. immer in der selben Art und Weise. Nur beim Debuggen gibt es
nichts universelles. Leider.
Anfänger schrieb:> also ich bin kein totaler Anfänger, ich bastl und programmier schon seit> paar Jahren. Aber eine Sache hat sich mir immer verschlossen, da ich nur> mit schönen bunten IDEs gearbeitet habe: Makefiles>> Ich weis wofür sie gut sind
Das bezweifle ich ehrlich gesagt ein bisschen.
> hab schon paar mal (versucht) welche> nachzuvollziehen aber hab noch NIE eines geschrieben.>> Dabei frag ich mich dauernd - Wozu die Dinger?> Ich bekomm den Brückenschlag zwischen einer IDE und Makefiles nicht hin.
Kein Wunder. IDE und Makefile sind ziemlich gegesätzliche Ansätze.
Vielleicht erstmal, was Makefiles nicht sind:
- sie haben nichts mit dem Debuggen zu tun
- es sind keine Skripts
Die Aufgabe, die das Programm make in Verbindung mit einem Makefile
löst, ist das Compilieren und Linken eines Projekts aus den
Quelldateien.
Make ist dabei ein sehr generischer Ansatz und kann für so ziemlich
alles verwendet werden, wo aus einer Menge Eingabefiles eine Menge
Ausgabefiles erzeugt werden (ggf. auch in mehreren Schritten).
Beispiel: meine Diplomarbeit habe ich in Latex geschrieben und einige
Diagramme wurden mit Maple erzeugt. Ein Makefile hat damals die
Maple-Skripte durch Maple gejagt um die Diagramme zu erzeugen, dann die
Latex-Files durch tex gedreht, und anschließend mit dvips alles in ein
hypsches Postskript-File verpackt.
Ein wichtiges Feature von make ist, daß es versucht Arbeit zu sparen.
Wenn z.B. dein Programm aus 3 .c Files besteht und du nach dem letzten
make-Lauf nur eins davon geändert hast, dann compiliert make nur dieses
eine und verwendet für die anderen die .o Files aus dem letzten Lauf.
Bei großem Projekten (z.B. Linux-Kernel) ist das sehr wichtig.
make ist auch nicht allein auf weiter Flur. Es gibt Alternativprogramme,
z.B. ant in der Java-Welt. Oder cook als generischer make-Ersatz.
Zurück zum Thema µC:
die Schritte zum Bauen eines Projektes sind im wesentlichen:
- compilieren aller Quellfiles zu Objektcode. Hier werden evtl.
verschiedene Compiler (C, C++, Assembler, ...) benötigt
- linken der Objektfiles und der verwendeten Libraries zum Target
- evtl. Postprocessing wie das Erzeugen von .hex und .eep Ladefiles
Eine IDE "weiß", wie das alles zusammenhängt und sobald du deine Quellen
zum Projekt getan hast und gesagt hast welche externen Libs du brauchst,
kann die IDE selber Compiler und Linker entsprechend aufrufen. Manche
IDEs schalten hier make ein, indem sie ein Makefile generieren und das
dann durch make jagen. Aber das ist eher die Ausnahme als die Regel.
Die IDE-Verweigerer unter uns verwenden hingegen direkt ein Makefile.
Die Details werde ich hier weglassen (kannst du in der Doku von z.B. GNU
make nachlesen). Oder hier: AVR-GCC-Tutorial/Exkurs Makefiles
Im Prinzip besteht ein Makefile aus zwei Arten von von Deklarationen:
1. Definition von make-Variablen. Viele davon habe magische Namen, z.B.
CC für den C-Compiler und CFLAGS für die Kommandozeilenoptionen für den
C-Compiler.
2. Regeln. Eine Regel beschreibt dabei einerseits Abhängigkeiten der
Files voneinander, als auch wie man aus dem Quellfile das Zielfile
erzeugt. Beispiel:
1
foo.o: foo.c
2
$(CC) $(CFLAGS) -c foo.c -o foo.o
das ist die Regel für die Erzeugung von foo.o. Es ist abhängig von foo.c
- wenn make also ein neueres foo.c als foo.o findet, weiß es daß es
foo.o neu erzeugen muß. Die nächste Zeile verwendet dann die magischen
Variablen für den C-Compiler, um foo.c zu foo.o zu compilieren.
Was die Sache für Anfänger etwas sperrig macht, sind zum einen die
vielen magischen Variablen und zum anderen die Tatsache, daß make
unheimlich viele Regeln bereits eingebaut hat. Obige Regel für .c -> .o
ist z.B. eingebaut.
In der Praxis sieht ein Makefile meist so aus, daß man ganz oben seine
Quelldateien auflistet. Darunter gibt man noch an, für welchen
Controller man das ganze bauen will und evtl. noch die
Optimierungsstufe.
Der ganze Rest darunter sind dann Regeln, die normalerweise immer gleich
sind. Deswegen schreibt man Makefiles seltenst komplett neu, sondern
verwendet ein altes und paßt nur die wenigen Stellen an, die sich
gändert haben. Auch gibt es Makefile-Generatoren wie mfile für
AVR-Projekte.
Soweit im Telegrammstil ertmal das wichtigste. Es gäbe noch viel mehr,
wie Default-Targets, wie man make depend automatisiert usw. usf.
HTH, XL
Danke für die Antworten, einiges kannte ich schon, einiges war neu
Wenn ich doch nur das heute gelernte behalten könnte^^
Axel Schwenke schrieb:> Manche IDEs schalten hier make ein, indem sie ein Makefile generieren und> das dann durch make jagen. Aber das ist eher die Ausnahme als die Regel.
Du meinst sowas wie Eclipse?
Gruß Stefan
Lass dich nicht verwirren.
Das hat schlicht und einfach historische Gründe. Früher, als es noch
keine IDEs gab, hatten die Programmierer das Makefile selbst
geschrieben.
Bei der Entwicklung der IDEs war es dann einfacher, das alte Makefile zu
behalten.
Debugging? Irgendwas hast du da falsch aufgerufen. Früher war ein "make
debug" üblich. Danach konnte man den Debugger benutzen.
Axel Schwenke schrieb:> - es sind keine Skripts
Ach Axel, da liegst du ganz falsch.
Makefiles SIND Skripte.
Dummerweise sind es solche, die nur von ihrem jeweiligen Make-Programm
(fast hätte ich 'make.exe' geschrieben :-) verstanden werden. Es gibt
leider eine eher unübersichtliche Anzahl verschiedener Makes, die alle
ihr eigenes Süppchen kochen und demzufolge ist Babylon angesagt. Ich
z.B. hab das Babylon notgedrungen (und nicht aus freien Stücken!) auf
meinem Rechner in der Firma. Wenn ich mich recht entsinne, sind das bei
mir so um die 7 oder 8 Makes, und wenn man selbige nicht aus einer
Batchdatei heraus aufruft, wo man zuvor fein säuberlich den Suchpfad
passend eingerichtet hat, geht garnix.
Das Blöde an Make und Makefiles ist, daß es eben jeweils eine eigene
Skriptsprache ist, die man erst mal erlernen und dann im Kopf behalten
muß, um sowas richtig zu schreiben.
Für Leute, die beruflich eher ne Art Monokultur betreiben, ist das
sicherlich kein Problem.
Aber für alle anderen ist es eben noch eine zusätzliche Sache, die man
lernen und handhaben muß - oder gar mehrere zusätzliche Sachen. Da ist
es einem sehr viel lieber, entweder eine passende IDE zu benutzen oder
sich einmal ne simple Batchdatei zusammenzuschreiben - das ist
dramatisch einfacher als ein Makefiles.
Und wozu das Ganze?
Ich sag's mal ganz provokativ: Für Mikrocontroller-Angelegenheiten, die
hier in diesem Forum diskutiert werden, ist Make völlig obsolet, ein
Fall für die Tonne. Die paar Quelldateien, die üblicherweise zu einer
typischen Geräte-Firmware dazugehören, kann man mit jedem
Übersetzungslauf ALLE übersetzen und die vor 30 Jahren mal angedachte
Zeitersparnis durch selektives Übersetzen per Make macht bei den
heutigen PC-Geschwindigkeiten keinen Sinn mehr. Ich schätze sogar, daß
deine Diplomarbeit auch nicht schlechter ausgefallen wäre, wenn du kein
Make verwendet hättest. Als ich diplomierte, gab's noch kein Make, da
wurden Diplome per Schreibmaschine getippt und Dissertationen in ne
Druckerei gegeben und Programme noch auf Lochband gestanzt. Was hab ich
damals an Lochband aufgerollt! Wahrscheinlich mehr als einmal um den
Äquator. TAR stammt aus dieser Zeit. TapeArchiver. Der TAR-Header
(256xnul und dann alles oktal) spiegelt noch jetzt die Verhältnisse am
Lochbandstanzer wider.
Abschließend ein Wort an unseren Anfänger: Es ist 1000 mal besser, seine
grauen Zellen mit wichtigeren Dingen zu füllen als sich mit Make und
Konsorten zu befassen. Make macht kein einziges Software-Projekt besser.
W.S.
W.S. schrieb:> Axel Schwenke schrieb:>> - es sind keine Skripts>> Ach Axel, da liegst du ganz falsch.> Makefiles SIND Skripte.
Nur wenn man den Begriff Skript sehr weit faßt. Im Gegensatz zu
klassischen Skriptsprachen (insbesondere den angesprochenen .BAT
Dateien) benutzt make einen deklarativen Ansatz.
> Es gibt> leider eine eher unübersichtliche Anzahl verschiedener Makes, die alle> ihr eigenes Süppchen kochen und demzufolge ist Babylon angesagt.
Stimmt, ist aber eine vollkommen andere Baustelle.
Eine Ursache für den Wildwuchs ist, daß make genauso wie ein C-Compiler
klassisch ein proprietäres Stück Software war, das oft genug nicht
unerheblich Geld kostete. Erst die GNU Leute haben das aufgebrochen und
es ist mir eine große Freude sagen zu können, das GNU make heute der
de-facto Standard ist (auch wenn das einige Leute schlecht finden;
bescheuerterweise besteht deren "Lösung" dann immer darin, entweder ein
weiteres make Derivat [ z.B. Jörg Schillings smake ] oder einen
Ersatz a'la ant oder cook zu propagieren - sie bekämpfen also den
Wildwuchs mit noch mehr Wildwuchs - sehr clever)
> es einem sehr viel lieber, entweder eine passende IDE zu benutzen oder> sich einmal ne simple Batchdatei zusammenzuschreiben - das ist> dramatisch einfacher als ein Makefiles.
Mal abgesehen davon, daß IDEs noch viel proprietärer sind als Makefiles
- sie sind auch nicht ansatzweise so mächtig. Ein Bekannter hat mal die
These von der Erhaltung der Gemeinheit aufgestellt: sprich daß Dinge
die kompliziert sind, kompliziert bleiben, egal auf welche Weise man sie
angeht. Für das Problem, das make löst, scheint mir das zuzutreffen.
Jede korrekte Lösung wird zwangsläufig einen nicht vermeidbaren Grad an
Komplexität haben.
> Ich sag's mal ganz provokativ: Für Mikrocontroller-Angelegenheiten, die> hier in diesem Forum diskutiert werden, ist Make völlig obsolet, ein> Fall für die Tonne.
Deine Meinung muß ich dir wohl lassen. Auch wenn ich sie nicht teile.
XL
