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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.