Hallo an alle, ich suche Feedback zur Erfahrung mit Makefiles (GNU-Make) im Zusammenhang mit C-Projekten. Macht es Sinn, wenn man ein einziges globales Makefile mit allen Modulen/Pfaden hat oder wenn man mehrere einzelne Make-Files pro Modul verwendet die ineinander aufrufen? Ziel sollte eine schnelle Build-Time als auch Runtime/Memory Performance vom generierten Machine-Code sein. Danke.
Wenn es schnell bauen soll und ein großes Projekt wird, dann cmake, ninja und ccache.
Karlheinz schrieb: > Macht es Sinn, wenn man ein einziges > globales Makefile mit allen Modulen/Pfaden hat oder wenn man mehrere > einzelne Make-Files pro Modul verwendet die ineinander aufrufen? Ziel > sollte eine schnelle Build-Time als auch Runtime/Memory Performance vom > generierten Machine-Code sein. Danke. Mit diesen Sachen hat die Frage eher wenig zu tun. Beim Bau geht die meiste Zeit meist für’n Compiler oder die Tests drauf, und auf die generierten Binaries hat’s gleich gar keinen Einfluss: gleiche Optionen beim Bauen vorausgesetzt, sind die Binaries bei den unterschiedlichen Schemata auch gleich. Ich glaube, der Hauptunterschied liegt in der Übersichtlichkeit und Wartbarkeit.
:
Bearbeitet durch User
Jack V. schrieb: > Beim Bau geht die meiste Zeit meist für’n Compiler So ganz stimmt das nicht. Wenn immer wieder ein make-prozess gelauncht werden muss, dauert es signifikant länger bei wirklich großen Projekten. Legst du die makefiles so an dass es nur wenige gibt, dort dann aber alles erledigt wird, dann geht es eindeutig schneller. Und unter Windows dauert das nochmal reichlich länger als unter Linux. Das Thema OS ist hier nicht gefragt aber wenn es um Geschwindigkeit geht, merkt man das auch deutlich, unabhängig vom verwendeten Buildsystem. Zumindest ist das meine Erfahrung.
J. S. schrieb: > Wenn es schnell bauen soll und ein großes Projekt wird, dann cmake, > ninja und ccache. Diese ganzen tollen Tools sind u.U. sinnvoll wenn das ganze Projekt im Sourcecode unter die Leute gebracht werden soll und auf vielen Plattformen und Konstellationen compilieren soll. Das erkauft man sich dann aber mit einer riesigen Komplexität bei dem was die Tools so erzeugen. cmake macht als Output ja auch nur ein makefile, wenn Probleme auftreten muss man sich mit dieser Syntax ja auch vertraut machen. Projekte die man nur auf definierten eigenen Systemen compiliert und als binaries vertrieben werden, ist dieser Overhead nicht nötig und ehr kontraproduktiv. Ich mache seit ueber 30 Jahren Software und das ausschließlich über makefiles. Vor 2 Jahren hat die neue Generation Entwickler alles auf cmake umstellen wollen und sind komplett gescheitert. Zumindestens war das aber Anstoß die makefiles am Ende neu zu schreiben und aus gefüht 60 ein einziges zu machen das auch nicht viel komplexer ist als jedes der einzelenen. Unter windows wird jetzt auch make anstelle von nmake verwendet. Damit kann man dann auch Windows mehrere Kerne zum Übersetzen nutzen und vor allem ich brauche nur noch ein makefile und nicht für jedes Zielsystem eins.
Alle Kerne parallel zu nutzen, ist wohl das wichtigste. Solange das nicht ausgebremst wird, hängt es wohl von Deinem Projekt ab (generierter Code, wechselnde Abhängigkeiten oder Quellen je Target) das Optimum zwischen Laufzeit und maintenance zu finden.
Manche Optimierungsstufen verlagern einen großen Teil der Arbeit vom Compiler auf den Linker. Ich nehme an, dass dort dann ein single-threaded Nadelöhr entsteht, richtig?
Jürgen L. schrieb: > alles auf cmake umstellen wollen und sind komplett gescheitert. Kann ich so nicht erkennen. Zumindest viele Hersteller gehen bei ihren Buildsystemen viel auf cmake. Und wenn man sich damit beschäftigt und dann versteht, ist es um ein Vielfaches einfacher als die elenden Makefiles mit ihrer schon sehr schrägen Syntax und anderen auch sehr speziellen Eigenarten. Der/die Entwickler müssen unter Drogeneinfluss gestanden haben, als die sich das überlegt haben. Ich finde es furchtbar. Nutze die aber auch, ist oft das kleinere Übel :) Nachtrag: allein schon die Unterscheidung ob man Space oder Tab im Makefile verwendet spricht Bände.
:
Bearbeitet durch User
900ss schrieb: > Der/die > Entwickler müssen unter Drogeneinfluss gestanden haben, als die sich das > überlegt haben. Die Überlegung kam mir eher bei cmake … ;) Man darf die Zeit nicht vergessen, in der make entstanden ist. Damals waren die technischen Voraussetzungen und die Anforderungen leicht anders, als heute.
Karlheinz schrieb: > Macht es Sinn, Für kleine Projekte ist es egal. Für große: > wenn man ein einziges > globales Makefile mit allen Modulen/Pfaden hat Das ist eine Mode die ab 1997 auf kam. Sie geht auf einen einzigen Entwickler zurück, der mit make nicht zurecht kam. Der hat alles in ein einziges Makefile gepackt und geglaubt er hätte eine wahnsinnige Erleuchtung gehabt. Er hat darüber einen pseudo-wisenschenschaftlichen Aufsatz ins Internet gestellt. Mit einem reißerischen Titel und den Anschein eines echten wissenschaftlichen Papers. Inhaltlich ist das Ding dünn, es werden anekdotische "Beweise" gebracht, aber es macht halt Eindruck: Miller, P.: Recursive Make Considered Harmful. 1997. Dieses hat die Runde unter anderen Entwicklern gemacht die mit make nicht zurecht kamen. Der Aufsatz ging in den Kreisen viral. Wie das mit dem Internet so ist. Heute wird einem der Aufsatz immer wieder um die Ohren gehauen wenn man ein rekursives Buildsystem aufsetzt. Meist von Leuten die ihn nicht gelesen haben und sowieso keine Ahnung von Buildsystemen, besonders in großen Projekten, haben. > einzelne Make-Files pro Modul verwendet die ineinander aufrufen? Hat vor Millers "bahnbrechender" Erkenntnis funktioniert, funktioniert auch heute noch. Besonders wenn du nicht-triviale Projekte hast. Der einzige Punkt, und da fallen die Leute immer wieder auf die Schnauze, ist das sie ihre physikalische Codestruktur nicht im Griff haben. Da werden zyklische Abhängigkeiten eingebaut und sich dann gewundert dass man alles auf einen Rutsch kompilieren muss. Wer mehr darüber wissen möchte, etwa um die gleiche Zeit wurde das Buch Lakos, John: Large-Scale C++ Software Design. Juni 1996 veröffentlicht. Nicht nur in Bezug auf C++ interessant. Es müsste mittlerweile eine zweibändige Neuauflage geben. Nur ist das eine ernsthafte Auseinandersetzung mit großen Projekten, nicht "Considered Harmful" Aufmerksamkeitsheischen.
Hannes J. schrieb: > Er hat darüber einen pseudo-wisenschenschaftlichen Aufsatz ins Internet > gestellt. Mit einem reißerischen Titel und den Anschein eines echten > wissenschaftlichen Papers. Inhaltlich ist das Ding dünn, es werden > anekdotische "Beweise" gebracht, aber es macht halt Eindruck: Ich habe das Paper gelesen und konnte nicht erkennen dass es reißerisch ist. Es betrachtet die Sache eher auch aus einer anderen Seite die nicht schlechter sein muss. Das hat meines Erachtens nichts damit zu tun ob man make versteht oder nicht. Das muss man in jedem Fall. Der Ansatz in den Paper hat Berechtigung finde ich.
Karlheinz schrieb: > Macht es Sinn, wenn man ein einziges > globales Makefile mit allen Modulen/Pfaden hat oder wenn man mehrere > einzelne Make-Files pro Modul verwendet die ineinander aufrufen? Beides kann sinnvoll sein, wie auch ein globales Makefile mit Include- Dateien pro Modul. Ich empfehle "Managing Projects with GNU Make" (frei verfügbar), insbesondere die Diskussion in Kapitel 6: https://www.oreilly.com/openbook/make3/book/index.csp > ... the nonrecursive make solution is a viable approach to building > large projects. It also solves many traditional problems found in the > recursive make approach. The only drawback I'm aware of is the > paradigm shift required for developers used to recursive make.
900ss schrieb: > So ganz stimmt das nicht. Wenn immer wieder ein make-prozess gelauncht > werden muss, dauert es signifikant länger bei wirklich großen Projekten. Bei der Art der Frage des TO wird die angepeilte Projektgröße wohl 2-3 Module und ein paar dutzend sourcefiles umfassen. Da spielt das alles überhaupt keine Rolle. Oliver
Steve van de Grens schrieb: > Manche Optimierungsstufen verlagern einen großen Teil der Arbeit vom > Compiler auf den Linker. Ich nehme an, dass dort dann ein > single-threaded Nadelöhr entsteht, richtig? Nein, nicht wenn man es richtig macht. Du beziehst dich wohl auf LTO, was keine Optimierung des Linkers ist sondern des Compilers. GCC zum Beispiel zerlegt den globalen Call-Tree in Teilbäume, die parallel compiliert werden können. Einfach mal die LTO-Optioen anschauen.
Beitrag #7634583 wurde vom Autor gelöscht.
Jürgen L. schrieb: > Zumindestens war > das aber Anstoß die makefiles am Ende neu zu schreiben und aus gefüht 60 > ein einziges zu machen das auch nicht viel komplexer ist als jedes der > einzelenen. Die von cmake erzeugten Makefiles sind ähnlich krypisch wie von Matlab erzeugter C-Code. Ja, kann man verstehen und auch verändern, aber das sollte nie notwendig werden. Das "eigentliche" Makefile ist hingegen sehr kompakt.
900ss schrieb: > ob man Space oder Tab im > Makefile verwendet spricht Bände. Richtig, spricht Bände wenn du nicht verstehst, das Space und Tab nunmal unterschiedliche Zeichen sind. Ansonsten könnte man ja auch einfach irgendein white-space zeichen nehmen, hauptsache da ist ne Lücke zu sehen.
Kaj G. schrieb: > Richtig, spricht Bände wenn du nicht verstehst, das Space und Tab nunmal > unterschiedliche Zeichen sind. - die aber für den Menschen in fast allen Editoren gleich aussehen, nur für den Rechner nicht. So etwas als Mensch-Maschine-Schnittstelle herzunehmen ist einfach nur kaputt. Zum Glück musste ich seit mindestens 15 Jahren kein Makefile mehr ansehen und bearbeiten, cmake sei Dank.
Klaus schrieb: > - die aber für den Menschen in fast allen Editoren gleich aussehen, nur > für den Rechner nicht. Ist das so? Im Texteditor vim:
1 | ┆·······Text |
2 | ┆·······┆·······Text |
3 | ┆·······┆·······┆·······Text |
4 | ┆·······┆·······┆·······┆·······Text |
In graphischen Editoren (Geany, Pluma,…) bekomme ich Linien und Pfeile pro Tabstop.
Norbert schrieb: > Ist das so Im Editor nicht, da hast du Recht. Aber spätestens wenn ich mit cat/less mal kurz was auf die Konsole ausgeben lasse...
Klaus schrieb: > Aber spätestens wenn ich mit cat/less mal kurz was auf die Konsole > ausgeben lasse... Dann ist es aber auch egal, weil du cat/less nicht zum Editieren benutzt. Derjenige der das eingetippt hat, wird es schon richtig gemacht und getestet haben.
Klaus schrieb: > Im Editor nicht, da hast du Recht. > Aber spätestens wenn ich mit cat/less mal kurz was auf die Konsole > ausgeben lasse... Ja, zum Schauen da nehme ich gewöhnlich view oder vi -R (ich mag den Farbrausch…)
Ich finde es auch suboptimal, dass bei Makefiles der Unterschied zwischen Tabs und Spaces wichtig ist. Aber so ist es halt. Wer will, kann sich gerne den Quelltext von Make schnappen und das ändern. Der Rest der Welt nimmt solche Details als gegeben hin und kümmert sich um echte Probleme.
Steve van de Grens schrieb: > Wer will, kann sich gerne den Quelltext von Make schnappen und das > ändern. Der Rest der Welt nimmt solche Details als gegeben hin und > kümmert sich um echte Probleme. Welches make besteht den noch auf Tabs?
Kaj G. schrieb: > Richtig, spricht Bände wenn du nicht verstehst, das Space und Tab nunmal > unterschiedliche Zeichen sind. Was du alles so weißt und irgendwas dann irgendwo hineininterpretierst. Da bin ich jetzt beeindruckt. :) Klaus schrieb: > die aber für den Menschen in fast allen Editoren gleich aussehen, nur > für den Rechner nicht Danke für die Erklärung. Zu den nachfolgenden Postings, ja ich weiß auch dass man das in den Editoren sichtbar machen kann. Aber die Ansicht nervt und es bleibt eine "Krankheit" in Makefiles das zwischen Space und Tab unterschieden wird. Es ist Unsinn aus vergangener Zeit.
:
Bearbeitet durch User
G. K. schrieb: > Welches make besteht den noch auf Tabs? Keine Ahnung. Bei gnu Make scheint es noch so zu sein: " Please note: you need to put a tab character at the beginning of every recipe line! " https://www.gnu.org/software/make/manual/make.html
:
Bearbeitet durch User
Steve van de Grens schrieb: > G. K. schrieb: >> Welches make besteht den noch auf Tabs? > > Keine Ahnung. Für gnu Make scheint rs nich so zu sein: > " Please note: you need to put a tab character at the beginning of every > recipe line! " > > https://www.gnu.org/software/make/manual/make.html Vom Arbeitgeber/Hersteller zur Verfügung gestellte IDEs, die auf Make basieren und nicht von morgen sind. Es soll Projekte geben, dessen Entwicklung schon eine Weile zurück liegt und trotzdem wird daran gearbeitet. Warum auch immer. Ob ein aktuelles Make darauf verzichtet, hab ich nicht probiert.
Jürgen L. schrieb: > Diese ganzen tollen Tools sind u.U. sinnvoll wenn das ganze Projekt im > Sourcecode unter die Leute gebracht werden soll und auf vielen > Plattformen und Konstellationen compilieren soll. Das erkauft man sich > dann aber mit einer riesigen Komplexität bei dem was die Tools so > erzeugen. cmake macht als Output ja auch nur ein makefile, wenn Probleme > auftreten muss man sich mit dieser Syntax ja auch vertraut machen. > Projekte die man nur auf definierten eigenen Systemen compiliert und als > binaries vertrieben werden, ist dieser Overhead nicht nötig und ehr > kontraproduktiv. Das sehe ich anders. Die Komplexität ist eher geringer, als wenn man selbst ein Makefile basteln muss. Ich nutze CMake gerne und inzwischen eigentlich für so ziemlich alles zum bauen. Und wenn was nicht richtig geht, musste ich eigentlich noch nie in die Makefiles schauen. > Ich mache seit ueber 30 Jahren Software und das ausschließlich über > makefiles. Ich mache das ähnlich lange. Bevor ich mir CMake angeschaut habe, hab ich auch fast alles direkt per handgeklöppeltem Makefile gemacht (oder bei Software für Linux auch mal mit automake/autoconf), aber seither mache ich das praktisch nur noch über CMake. > Vor 2 Jahren hat die neue Generation Entwickler alles auf cmake umstellen > wollen und sind komplett gescheitert. Ich habe vor ein paar Jahren das Build-System einer alte Software, das auf eine Mischung aus recht komplexen Makefiles und awk-Skripten aufgebaut hat, durch CMake und (für ein paar Codegeneratoren) Python ersetzt. Das war einfacher als ich anfangs befürchtet hatte. Jetzt sind ein paar unerklärliche Probleme, die das alte System hatte, verschwunden. Es baut auch deutlich schneller, weil nicht mehr Tausende von Prozessen als Teil der Dependancy-Erkennung laufen müssen, die am Ende trotzdem fehlerhaft war. Bei CMake passt das einfach automatisch.
Karlheinz schrieb: > ich suche Feedback zur Erfahrung mit Makefiles (GNU-Make) im > Zusammenhang mit C-Projekten. Macht es Sinn, wenn man ein einziges > globales Makefile mit allen Modulen/Pfaden hat oder wenn man mehrere > einzelne Make-Files pro Modul verwendet die ineinander aufrufen? Ziel > sollte eine schnelle Build-Time als auch Runtime/Memory Performance vom > generierten Machine-Code sein. Danke. Mit einem einzigen Makefile hast du einen Haufen Abhängigkeiten zwischen den einzelnen Modulen. Es ist nicht mehr einfach möglich ein Modul aus seinem Verzeichnis heraus zu übersetzen, oder die Arbeit an einen Externen auszulagern. Das globale Makefile muss die Sonderlocken aller Module beinhalten, das ist ein Wartungsmonster. Und was passiert, wenn ein Modul gerade nicht kompiliert? Würde ich nicht empfehlen. Die Geschwindigkeit spielt da normalerweise keine Rolle. Wenn du schnell übersetzen willst, dann verwende precompiled Header und reduziere die Anzahl der Sourcefiles.
So sehe ich das auch. Ein modularer Aufbau ist eigentlich so gut wie immer gegenüber einem großen Monolith zu bevorzugen. Nicht umsonst macht man das beim Code selbst ja auch so (oder sollte es zumindest).
> - die aber für den Menschen in fast allen Editoren gleich aussehen, nur > für den Rechner nicht. Korrekt. Das waere ja fast so als wenn man in einer Programmiersprache die geschweiften Klammern durch Einrueckungen ersetzen. :-D Vanye
Vanye R. schrieb: > Korrekt. Das waere ja fast so als wenn man in einer Programmiersprache > die geschweiften Klammern durch Einrueckungen ersetzen. :-D Ich denke das ist ein sehr schönes Selektionskriterium. Wenn ein "Programmierer" nicht in der Lage ist zwischen Leerzeichen und Tabulatoren zu unterscheiden, wenn er/sie/es nicht in der Lage ist Einrückungen zu bewerten, dann wäre das doch ein wunderbares Signal sich einem neuen Aufgabengebiet zuzuwenden.
Norbert schrieb: > Korrekt. Das waere ja fast so als wenn man in einer Programmiersprache > die geschweiften Klammern durch Einrueckungen ersetzen. :-D Genau das ist auch der Punkt, warum ich python nicht sehr mag.
Klaus, ich bin mir nicht vollständig sicher das ich so etwas geschrieben habe. Aber du bist nicht der Erste der falsch zitiert. ;-)
Norbert schrieb: > Wenn ein "Programmierer" nicht in der Lage ist zwischen Leerzeichen und > Tabulatoren zu unterscheiden, wenn er/sie/es nicht in der Lage ist > Einrückungen zu bewerten, dann wäre das doch ein wunderbares Signal sich > einem neuen Aufgabengebiet zuzuwenden. Klar... Erzähl mal wie du an einem Zeilenanfang 8 Leerzeichen, in der nächsten Zeile ein Tab (Tabweite auf 8 gestellt), unterscheiden willst wenn der Editor nicht so eingestellt ist, dass er Whitespaces durch Punkt oder sonst etwas kenntlich macht. Du hast Augen, da beneide ich ich dich drum ;)
Da ich weiß, das das bei Makefiles eine Rolle spielt, benutze ich für Makefiles sinnvollerweise einen Editor, der den Unterschied anzeigt. Danach muss man nicht lange suchen. Am naheliegendsten ist Word oder Writer, wenn nan nicht eh schon eine geeignete IDE verwendet.
Steve van de Grens schrieb: > Da ich weiß, das das bei Makefiles eine Rolle spielt, benutze ich für > Makefiles sinnvollerweise einen Editor, der den Unterschied anzeigt. Klar, mache ich auch so. Alles andere wäre recht dumm. Trotzdem ändert es nichts daran dass man eine Extrawurst braten muss nur dieses Unsinns wegen. Auch klar, ist kein Weltuntergang. Trotzdem ist dieses Feature völlig dämlich. Nachtrag: es gibt noch jede Menge andere dämliche Regeln in Makefiles, offensichtlich oder gut versteckt. Aber Makefiles sind halt das kleinste Übel :) Cmake gefällt mir eigentlich besser. Das ist aber ja nur ein Hut der über das Übel gestülpt wird.
:
Bearbeitet durch User
900ss schrieb: > Das ist aber ja nur ein Hut der über das Übel gestülpt wird. Ungefähr so, wie C einen Hut über Assembler stülpt. Der Komfortgewinn ist mMn in einer ähnlichen Größenordnung.
:
Bearbeitet durch User
900ss schrieb: > Erzähl mal wie du an einem Zeilenanfang 8 Leerzeichen, in der nächsten > Zeile ein Tab (Tabweite auf 8 gestellt), unterscheiden willst wenn der > Editor nicht so eingestellt ist, dass er Whitespaces durch Punkt oder > sonst etwas kenntlich macht. Wieso sollte man sich mit einem derart fehlerhaft/mangelhaft konfigurierten System herum ärgern? Mein vi kann's natürlich und die Graphischen sowieso. 900ss schrieb: > Du hast Augen, da beneide ich ich dich drum Ach wenn's doch nur so wäre. Jedes Jahr den Font um einen Punkt größer stellen, darauf hat mich niemand vorbereitet. ;)
Norbert schrieb: > Wieso sollte man sich mit einem derart fehlerhaft/mangelhaft > konfigurierten System herum ärgern? Mein vi kann's natürlich und die > Graphischen sowieso. Ständig die white spaces als Punkte oder was auch immer anzeigen zu lassen, nervt mich und ist für mich ohnehin völlig unnötig. Zuviel Zeugs im Editor. Farbige Syntax ist ausreichend (für mich). Aber jeder wie er mag. Ich schalte es nur ein, wenn ich Wert auf die Anzeige der whitespaces als "nicht whitespaces" sehen möchte, Makefiles z.B.. Und das hat nun garnichts mit einem fehlerhaft konfiguriertem System zu tun.
900ss schrieb: > Norbert schrieb: >> Wieso sollte man sich mit einem derart fehlerhaft/mangelhaft >> konfigurierten System herum ärgern? Mein vi kann's natürlich und die >> Graphischen sowieso. > > Ständig die white spaces als Punkte oder was auch immer anzeigen zu > lassen, nervt mich und ist für mich ohnehin völlig unnötig. Zuviel Zeugs > im Editor. Farbige Syntax ist ausreichend (für mich). Aber jeder wie er > mag. Ich schalte es nur ein, wenn ich Wert auf die Anzeige der > whitespaces als "nicht whitespaces" sehen möchte, Makefiles z.B.. Und > das hat nun garnichts mit einem fehlerhaft konfiguriertem System zu tun. Ja klar, Blanks bleiben selbstverständlich weiterhin Blanks. Und Tabs werden sanft hervorgehoben. Die habe ich im Prinzip aber nur noch in Makefiles. Und im vi werden sie auch noch als dünne Linien in einem dunkleren Blau angezeigt. Recht angenehm und (mich) überhaupt nicht störend.
Vanye R. schrieb: >> - die aber für den Menschen in fast allen Editoren gleich aussehen, nur >> für den Rechner nicht. > > Korrekt. Das waere ja fast so als wenn man in einer Programmiersprache > die geschweiften Klammern durch Einrueckungen ersetzen. :-D Schlechtes Beispiel, denn man kann in der Regel in einem Editor sehr leicht Einrückungen von Klammern unterscheiden. Klaus schrieb: > Norbert schrieb: > >> Korrekt. Das waere ja fast so als wenn man in einer Programmiersprache >> die geschweiften Klammern durch Einrueckungen ersetzen. :-D > > Genau das ist auch der Punkt, warum ich python nicht sehr mag. Es wird etwas, das man sowieso machen sollte, um die Struktur des Code dem Leser zu zeigen, auch gleich verwendet, um sie dem Interpreter zu zeigen, anders als in Sprachen wie C, wo man dafür unterschiedliche Elemente verwendet. Wer sowieso vernünftig einrückt, denn sollte das nicht weiter stören. 900ss schrieb: > Norbert schrieb: >> Wieso sollte man sich mit einem derart fehlerhaft/mangelhaft >> konfigurierten System herum ärgern? Mein vi kann's natürlich und die >> Graphischen sowieso. > > Ständig die white spaces als Punkte oder was auch immer anzeigen zu > lassen, nervt mich und ist für mich ohnehin völlig unnötig. Reicht ja, wenn nur die Tabs so angezeigt werden. Dann kann man es bei Makefiles gleich erkennen, und bei allem anderen benutzt man sowieso keine Tabs.
> Nachtrag: es gibt noch jede Menge andere dämliche Regeln > in Makefiles, offensichtlich oder gut versteckt. Aber > Makefiles sind halt das kleinste Übel :) Der Meinung bin ich auch. Make is kacke, aber riecht am wenigsten und ist durchgesetzt und mittlerweile halbwegs kompatibel. Alles andere ist schlimmer und in jeder neuen Version anders. > Schlechtes Beispiel, denn man kann in der Regel in einem Editor sehr > leicht Einrückungen von Klammern unterscheiden. Nein, gutes Beispiel. Es geht naemlich nicht darum Space/Tab oder Begin/{/Space zu unterscheiden, es geht darum auf einem Blick die Struktur in einem Programm zu erkennen. Also das worauf es ankommt und zwar mit jedem beliebigen Texteditor und auch gedruckt. Und es ist weder sinnvoll bewusst in "obfuscated C" zu schreiben, noch sich eine bestimmte "schoene" schreibform vorschreiben zu lassen. Der pragmatische Mittelweg ist gut. Vanye
Angehängte Dateien:
-
2024-03-31_09-56.png
170 KB
900ss schrieb: > Ständig die white spaces als Punkte oder was auch immer anzeigen zu > lassen, nervt mich und ist für mich ohnehin völlig unnötig Es hat ja niemand empfohlen, das ständig zu tun. 900ss schrieb: > Ich schalte es nur ein, wenn ich Wert auf die Anzeige der > whitespaces als "nicht whitespaces" sehen möchte, Makefiles z.B Na also, geht doch! Ich weiß nicht ob es heute noch so ist. Aber Word hatte dazu früher immer einen prominent platzierten Button unter der Menüleiste, den wir "ekel-P" nannten. Damit konnte man die Anzeige dieser Zeichen ein/aus schalten. Offenbar war das früher nicht nur für Programmierer eine häufig genutzte Funktion. Sonst wäre sie in den Tiefen der Einstellungs-Dialoge versteckt gewesen. Ich erinnere mich auch an eine andere Textverarbeitung unter DOS (ohne GUI), wo Tabulatoren hervorgehoben wurden. Dass Tabulatoren standardmäßig nicht mehr hervorgehoben werden, kam offenbar erst lange nachdem Make erfunden wurde.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Na also, geht doch! Ja Herr Lehrer ;) Ich nutze in meiner IDE sogar solch einen Button. :) Und trotzdem finde ich es Unsinn. Ja weiß ich auch, mir ist nicht zu helfen :)
:
Bearbeitet durch User
Rolf M. schrieb: > Klaus schrieb: >> Norbert schrieb: Lieber Rolf, Wenn du jemanden zitierst welcher einen anderen falsch zitiert, dann wird die Aussage damit nicht besser. In diesem speziellen Falle wird sie sogar komplett auf den Kopf gestellt. Ich mag Python, ich nutze Python oft, ich kann es sogar richtig schreiben. Auch bin ich in der glücklichen Lage meine Editoren zu konfigurieren, so das sie mir ein Modicum an Hilfestellung bei der Erkennung von Tabulatorzeichen geben. Also genau die Zeichen, welche sich als extrem nützlich in Makefiles erwiesen haben und in Python Dateien niemals als Einrückung auftauchen sollten. PS. Hängt man sich hier in diesem "Fachforum" immer noch an einem 0x09 auf? Ein Zeichen welches seit vielen Jahrzehnten für Makefiles genutzt wird und welches jeder – aber auch wirklich jeder – Nutzer eines ›make‹ vollumfänglich verinnerlicht haben sollte? Wir leben wahrlich in seltsamen Zeiten!
> aber auch wirklich jeder – Nutzer eines ›make‹ > vollumfänglich verinnerlicht haben sollte? Falsch, irgendwann sterben die alten Knacker ja immer weg und Frischlinge ruecken nach und die stellen dann immer so doofe Fragen: Wieso geht das nicht, sieht doch gleich aus? Und sobald sie es begriffen haben denken sie: Palmface. Und im schlimmsten Falle denken sie dann, oh man, ich muss das Problem loesen indem ich etwas neues mache. Aber hey, ganz neu bekomme ich intellektuell nicht auf die Reihe, am besten ich stuelpe da noch einen Layer drueber! -->cmake Hm..wo cmake nun aber auch schon alt ist wird es eigentlich mal wieder Zeit fuer einen weiteren Standard. Hm...nennen wir es cargo. Wobei cargo ist auch schon alt und hat nix mit KI, also der naechste Verschlimmbesserer kommt bald... Vanye
Vanye R. schrieb: > Falsch, irgendwann sterben die alten Knacker ja immer weg und > Frischlinge ruecken nach und die stellen dann immer so doofe > Fragen: Wieso geht das nicht, sieht doch gleich aus? Ganz Recht Wer zum Lesen der Anleitungen zu unfähig ist, der soll nicht programmieren. Die Sache mit den Tabs steht in jeder Anleitung zu Makefiles deutlich drin. Niemand zwingt Frischlinge dazu, die Arbeitsmittel von Opa zu benutzen. Wer Make doof findet, der kann gerne andere Tools nutzen oder entwickeln. > ich stuelpe da noch einen Layer drueber! --> cmake Genau. Leider stellst das auch nicht alle zufrieden - wer hätte das gedacht? Die alten überrascht es jedenfalls nicht. Die Geschichte wiederholt sich. Jedenfalls ist das Benutzen von 50 Jahren Werkzeugen einfach nur peinlich, wenn man sich zugleich darüber beklagt, dass sie nicht dem aktuellen Standard entsprechen. Die gleichen Leute werfen den alten womöglich auch noch vor, unflexibel zu sein.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Sorry, aber wer nicht lesen kann oder will, ist selbst Schuld. Das steht > in jeder Anleitung zu Makefiles deutlich drin. Und weil es - in der Anleitung steht - im Editor sichtbar zu machen ist - schon immer so war - sich nie ändern wird muss ich es gut finden? Nein, muss ich nicht.
Vanye R. schrieb: > Hm...nennen > wir es cargo. nein, wenn schon dann Meson z.B. Was es nicht einfacher macht weil so wieder verschiedene Buildsysteme parallel existieren und C/C++ mit Komponenten erschwert. In den meisten modernen Sprachen hat man sich dieses Problems angenommen und die Komponentenverwaltung eingebaut, wie Cargo bei Rust. Das ist aber auch nur ein Argument für CMake, es gibt viele weitere. Kein Argument für mich ist 'mache ich schon seit 30 Jahren so'. Ich programmiere seit über 40 Jahren und es ist für mich kein Hinderungsgrund Neues zu lernen oder verstehen zu wollen warum man etabliertes wie make verbessern möchte. Wobei cmake nicht make ersetzt, sondern eine Metasprache ist und make oder ninja benutzt. Durch die Ausführung in zwei Schritten (makefile generieren, danach make/ninja aufrufen) kann das eigentliche make schneller laufen. Das makefile wird nicht möglichst toll leserlich und kompakt generiert, sondern so das es ohne aufwändiges parsen schnell abgearbeitet werden kann. In das makefile guckt man nur maximal bei anfänglicher Fehlersuche rein, ob z.B. Compileroptionen richtig gesetzt wurden.
Klaus schrieb: > muss ich es gut finden? > Nein, muss ich nicht. Dein Gemeckere ist vollkommen sinnlos. Akzeptiere, was du nicht ändern kannst oder ändere, was du nicht akzeptieren kannst.
Angehängte Dateien:
-
make_error.png
19 KB
Vanye R. schrieb: > Falsch, irgendwann sterben die alten Knacker ja immer weg und > Frischlinge ruecken nach und die stellen dann immer so doofe > Fragen: Wieso geht das nicht, sieht doch gleich aus? > > Und sobald sie es begriffen haben denken sie: Palmface. Tja, so macht jeder unterschiedliche Erfahrungen. Die einen lesen, die anderen meckern.
1 | make |
2 | makefile:4: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. |
Und der Editor hilft auch noch mit ›syntax highlighting‹!
Wer über TAB in Makefiles diskutiert, hat noch nie ernsthaft Make verwendet. Das TAB ist noch nicht mal ein Problemchen...
> Wer über TAB in Makefiles diskutiert, hat noch nie ernsthaft Make > verwendet. Das TAB ist noch nicht mal ein Problemchen... Naja, es muss ja Gruende geben wieso die Anleitung zu make ueber 200Seiten hat. :-D Vanye
Steve van de Grens schrieb: > Dein Gemeckere ist vollkommen sinnlos. Wenn etwas nicht optimal ist, muss man das wertfrei sagen können. Wenn Tab hier eine gute Idee ist, dann begründe das gerne. Vielleicht hat es in einer bestimmten Umgebung zu einer bestimmten Zeit Vorteile gehabt, dann erkläre das gerne. Es ist auch nett, dass Du Workarounds postest (selbst wenn die jedem make-User bekannt sein sollten). Aber verfügbare Workarounds sind kein Argument dafür, dass etwas sinnvoll ist und (in künftigen Produkten) so bleiben sollte.
Vanye R. schrieb: > Rolf M. schrieb: >> Schlechtes Beispiel, denn man kann in der Regel in einem Editor sehr >> leicht Einrückungen von Klammern unterscheiden. > > Nein, gutes Beispiel. Es geht naemlich nicht darum Space/Tab oder > Begin/{/Space zu unterscheiden, es geht darum auf einem Blick die > Struktur in einem Programm zu erkennen. Also das worauf es ankommt und > zwar mit jedem beliebigen Texteditor und auch gedruckt. Genau das gewährleistet der Whitespace in Python. Und dabei achtet der Interpreter sogar auf die Konsistenz innerhalb der Dateien: Leerzeichen und Tabs mischen ist nicht. > Und es ist weder > sinnvoll bewusst in "obfuscated C" zu schreiben, noch sich eine > bestimmte "schoene" schreibform vorschreiben zu lassen. Der pragmatische > Mittelweg ist gut. Der pragmatische Weg ist, Redundanzen einzusparen, und wenn der Code korrekt und sauber eingerückt ist, dann sind Klammern redundant und überflüssig. Darüber hinaus kennen erfahrene Entwickler, die in Teams gearbeitet haben, die ewig langen und mitunter außerordentlich nervigen Diskussionen über einen gemeinsamen, konsistenten Coding Style. Darum sind die Entwickler von Golang sogar einen Schritt weiter gegangen und haben nicht nur einen fixen Coding Style vorgeschrieben, sondern setzen ihn mit "go fmt" sogar durch. Aber ging es hier nicht um Makefiles?
Bruno V. schrieb: > Wenn Tab hier eine gute Idee ist, dann begründe das gerne. Vielleicht > hat es in einer bestimmten Umgebung zu einer bestimmten Zeit Vorteile > gehabt, dann erkläre das gerne. Es Letztlich beinhalten Makefiles zwei "Sprachen": einmal die von Make selbst und dann, innerhalb der Rezepte, Shellskripte. Das macht Make so außerordentlich mächtig und flexibel, so daß es nicht nur die Übersetzung von Programmen und Bibliotkeken, sondern alles Mögliche steuern kann. Die Einrückung mit Tabs ist es nun, die Make mitteilt, daß dort jetzt nicht die Make-, sondern "die andere Sprache", nämlich ein Shellskript steht. Das kann man jetzt schlimm finden, muß man aber nicht, etliche Generationen von Entwicklern haben es geschafft, sich daran zu gewöhnen. Ich selbst verwende GNU Make zum Beispiel nicht nur für C, C++ und Golang, sondern auch zum Erzeugen meiner Präsentationen, Artikel, Dokumentationen und Briefe aus LaTeX, zur Transpilation von Sass- in CSS-Dateien, zur Erzeugung und Pushen von Docker-Images, und für eine... kreative Nutzung von Ansible. Nebenbei bemerkt habe ich mir im Laufe der Jahre auch immer wieder andere Build-Werkzeuge angeschaut, weil das Bessere ja bekanntlich der größte Feind des Guten ist und ich das ungern verpassen möchte. Am Ende bin ich dann aber dennoch immer wieder zu Make zurückgekehrt, eben weil es so flexibel ist.
Ein T. schrieb: > Und dabei achtet der Interpreter sogar auf die Konsistenz innerhalb der > Dateien: Leerzeichen und Tabs mischen ist nicht. Stimmt nicht ganz. Man kann sie schon beliebig mischen, es muss nur in aufeinanderfolgenden Zeilen auf konsistente Weise getan werden. Man kann also nicht in einer Zeile die Einrückung mit einem Tab machen, in der nächsten dieselbe Einrückung dann mit 8 Spaces. Man kann aber z.B. die erste Einrückungsebene mit 4 Spaces machen, die zweite dann mit 4 Spaces + ein Tab und die dritte dann mit 4 Spaces, einem Tab und nochmal 3 Spaces. Es muss eben nur bei aufeinanderfolgenden gleich oder tiefer eingerückten Zeilen immer gleich sein.
Ein T. schrieb: > Das kann man jetzt schlimm finden, muß man aber nicht, etliche > Generationen von Entwicklern haben es geschafft, sich daran zu gewöhnen. Mein Frage (also C-Programmierer und daher an Sonderzeichen im ASCII-Raum gewöhnt) wäre: hätte es auch ein anderes Zeichen zwischen 32 und 127 getan, dass in jedem Editor in jeder Einstellung von 32 unterscheidbar ist (und den "Flow" nicht stört)? Wenn ja, dann sollte man das anmerken dürfen. Wenn nein (Zeichenvorrat erschöpft, Inkompatibilität mit anderen Editoren, Verwechslungsgefahr mit einer anderen Syntax, nicht auf damaligen Tastaturen, ...), dann gerne Infos.
Das ganze ist zu einer Zeit entstanden, als nicht nur Terminals sondern auch Drucker auf Tabs (nicht nur horizontal sondern auch vertical Tabs) in sinnvoller Weise reagierten. Zudem war Speicherplatz (im wahrsten Sinne des Wortes) kostbar. Das kann man sich heutzutage - in Zeiten wo selbst einfachste Dinge gleich Exabytes brauchen – kaum noch vorstellen. Die Steuerzeichen im unteren ASCII Bereich <= 0x1f hatten tatsächlich noch eine Bedeutung. Und ein Tabulatorzeichen wurde gerne als Tabulatorzeichen für eine Einrückung genommen. Es mag seltsam erscheinen, doch so steht es in den alten Schriften.
Norbert schrieb: > Das ganze ist zu einer Zeit entstanden... ...als ein Programmierer noch alle seine User persönlich kannte ;) "I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history." https://retrocomputing.stackexchange.com/questions/20292/why-does-make-only-accept-tab-indentation
Das muss man sich mal heute vorstellen: Du schreibst dir ein kleines Hilfsprogramm, weil es dir eine Menge wiederholter Arbeit abnimmt. Und 50 Jahre später nutzt es (immer noch) die ganze Welt. Und zwar auf Computern, von die damals nicht mal in deinen wildesten Träumen vorkamen. Ist das nicht krass?
:
Bearbeitet durch User
Bruno V. schrieb: > Ein T. schrieb: >> Das kann man jetzt schlimm finden, muß man aber nicht, etliche >> Generationen von Entwicklern haben es geschafft, sich daran zu gewöhnen. > > Mein Frage (also C-Programmierer und daher an Sonderzeichen im > ASCII-Raum gewöhnt) wäre: hätte es auch ein anderes Zeichen zwischen 32 > und 127 getan, dass in jedem Editor in jeder Einstellung von 32 > unterscheidbar ist (und den "Flow" nicht stört)? Bitte nenne doch mal eines und zeig uns dann mal ein Makefile damit. :-)
Bruno V. schrieb: > Mein Frage (also C-Programmierer und daher an Sonderzeichen im > ASCII-Raum gewöhnt) wäre: hätte es auch ein anderes Zeichen zwischen 32 > und 127 getan, dass in jedem Editor in jeder Einstellung von 32 > unterscheidbar ist (und den "Flow" nicht stört)? Hätte es wahrscheinlich auch getan. Man kann allerdings die Zeit nicht zurückdrehen und diese Entscheidung nachträglich ändern. Und wenn man es könnte, wäre es dann den Aufwand wert? > Wenn ja, dann sollte man das anmerken dürfen. Klar darf man das, nur hilft das nicht weiter.
Ein T. schrieb: > Bitte nenne doch mal eines und zeig uns dann mal ein Makefile damit. :-) Guckst du einfach in den Link 2 Beiträge über deinem.
Klaus schrieb: > Guckst du einfach in den Link 2 Beiträge über deinem. Konfigurierbar via RECIPEPREFIX. Aber diese Antwort ist nicht willkommen, da sie den Wind aus den Segeln nimmt.
Rolf M. schrieb: > nur hilft das nicht weiter Wieviele der in diesem Forum (und natürlich auch woanders) geführten Diskussionen helfen wirklich(!) weiter? :) Und oft ist es vor Beginn einer Diskussion auch kaum bekannt, ob sie weiter hilft. Hinterher kann man immer klug daher reden. Das ist grundsätzlich ein ziemlich unsinniges Argument dafür, dass man eine Diskussion nicht führen sollte. Und bis auf wenige Ausnahmen von Leuten, die es auch sonst oft nicht besser können, lief diese Diskussion hier wirklich sachlich. Erstaunlich eigentlich ;)
:
Bearbeitet durch User
Rolf M. schrieb: > Klar darf man das, nur hilft das nicht weiter. In diesem Fall ja doch: Dank BBs Link weiß nun jeder, wie es dazu kam und dass es schon nach kurzer Zeit als suboptimal erkannt wurde.
:
Bearbeitet durch User
900ss schrieb: > Rolf M. schrieb: >> nur hilft das nicht weiter > > Wieviele der in diesem Forum (und natürlich auch woanders) geführten > Diskussionen helfen wirklich(!) weiter? :) Nunja, er hat sich über die Tabs in Makefiles beschwert, ihm wurde gesagt, dass das nicht viel bringt, weil es jetzt nun mal so ist und er entweder damit leben oder halt ein anderes Tool verwenden soll, aber er besteht darauf, sich weiter darüber zu beschweren. Das ist eben recht sinnlos. > Und oft ist es vor Beginn einer Diskussion auch kaum bekannt, ob sie > weiter hilft. Hinterher kann man immer klug daher reden. Dass make Tabs als Trenner nutzt, war durchaus schon vorher bekannt. Steve van de Grens schrieb: > Konfigurierbar via RECIPEPREFIX. Aber diese Antwort ist nicht > willkommen, da sie den Wind aus den Segeln nimmt. Können das alle, oder ist das eine Spezialität von GNU make? Und findest du es sinnvoll, das umzukonfigurieren? Bei einem Makefile rechnet mit sowas doch keiner.
Bruno V. schrieb: > hätte es auch ein anderes Zeichen zwischen 32 und 127 getan natürlich, aber > (Zeichenvorrat erschöpft, Inkompatibilität mit anderen Editoren, > Verwechslungsgefahr mit einer anderen Syntax, nicht auf damaligen > Tastaturen, ...) tatsächlich werden alle ASCII-Zeichen irgendwo benutzt, make soll ja für mehr als Compiler-Aufrufe funktionieren. Vielleicht bis auf das Fragezeichen, da fällt mir nur $? aus der Shell ein. Aber: TAB alleine funktioniert ja auch nicht, es heißt newline-tab. Kombiniert mit newline fände ich ! passend oder ^. Auf damaligen Tastaturen fehlte einiges, auf der ASR-33 Tastatur gab es ja nicht einmal { }, aber TAB ging mit CTRL-H...
Bauform B. schrieb: > Auf damaligen Tastaturen fehlte einiges, auf der ASR-33 Tastatur gab es > ja nicht einmal { }, Heißt ja auch ASCII und nicht GSCII. ;-) > aber TAB ging mit CTRL-H... Ähm, CTRL-I vielleicht?
Norbert schrieb: >> aber TAB ging mit CTRL-H... > > Ähm, CTRL-I vielleicht? danke, nicht nur vielleicht :(
Norbert schrieb: > Und ein Tabulatorzeichen wurde gerne als > Tabulatorzeichen für eine Einrückung genommen. Es mag seltsam > erscheinen, doch so steht es in den alten Schriften. Natürlich wurde ein Tabulator für eine Einrückung genommen. Nicht nur "gerne", sondern immer. Schließlich war das dessen Funktion auf den anderen Geräten, die damals zur Zeit der "Erfindung" von Computerausgabegeräten (Druckern) in Gebrauch waren, nämlich mechanische bzw. elektrische Schreibmaschinen. Terminals kamen ja erst viel später. Oliver
Ich mache ja nur sehr kleine µC Projekte mit etwa 30 Objekten. Die Kollegen wollen ein makefile, also habe ich eins geschrieben. Die 30 Aufrufe des AVR-GCC darin dauern schon etwas. Ich selber benutze aber eine Batch, die den AVR-GCC einfach mit *.c aufruft, das compiliert und linkt deutlich schneller.
> Die 30 Aufrufe des AVR-GCC darin dauern schon etwas.
Im ernst? Das kann ich kaum glauben. Hast du schonmal ein make linux
-j16 gemacht und gesehen was da abgeht? Die Vorstellung das soetwas
banales wie eine Mikrocontrolleranwendung wahrnehmbar lange dauert ist
auf aktueller Hardware doch absurd zumal make ja auch dafuer da ist
gerade nur das zu uebersetzen an das du rumgefummelt hast.
Vanye
Peter D. schrieb: > Ich selber benutze aber eine Batch, die den AVR-GCC einfach mit *.c > aufruft, das compiliert und linkt deutlich schneller. Der erste April ist zwar schon vorbei, aber:
1 | .PHONY: all |
2 | all: |
3 | gcc *.c |
Vanye R. schrieb: > Die Vorstellung das soetwas > banales wie eine Mikrocontrolleranwendung wahrnehmbar lange dauert ist > auf aktueller Hardware doch absurd Nicht wenn auf dem Betriebssystem der Wahl die Geschwindigkeit mit der ein Prozess startet mit dem Abreißkalender gemessen wird!
> Nicht wenn auf dem Betriebssystem der Wahl die Geschwindigkeit mit der > ein Prozess startet mit dem Abreißkalender gemessen wird! Soll den das sein? DOS3.3? Hier mal ein Beispiel: ~/sources/RP2040/SMU_Tester: make clean ~/sources/RP2040/SMU_Tester: time make -j 16 CC build/main.o CC build/sysinit.o CC build/ticker.o CC build/uart.o CC build/vt100.o CC build/timer.o CC build/i2c0.o CC build/spi0.o CC build/ads1217.o CC build/core1.o CC build/piotest.o CC build/piors232.o CC build/startup_rp2040.o LD build/MyTest3.elf OBJCOPY build/MyTest3.hex OBJCOPY build/MyTest3.bin size: text data bss dec hex filename 33496 2476 756 36728 8f78 build/MyTest3.elf 33496 2476 756 36728 8f78 (TOTALS) BIN2UF2 build/MyTest3.uf2 real 0m0.137s user 0m0.995s sys 0m0.214s Klar, ist jetzt nur ein kleines Bastelprojekt, aber komplett uebersetzt und unter 1s. Das mag etwas anders sein wenn man einen kompletten Linuxkernel im Projekt hat, aber auch der lag IMHO so bei 5min und nicht mehr 30min wie vor 20Jahren. Und wie ich schon sagte, ueblicherweise wird ja immer nur eine Datei uebersetzt an der man halt gerade arbeitet. Vanye
Vanye R. schrieb: > Soll den das sein? DOS3.3? Na das es auf Linux Systemen rasend schnell ist, das wissen wir! Selbst auf meinem alten, armseligen Vier-Kerner brummt es ganz ordentlich.
J. S. schrieb: > Wenn es schnell bauen soll und ein großes Projekt wird, dann cmake, Wie könnte cmake schneller sein als make, wenn es erst Makefiles baut und die dann mit make abarbeitet?
Die makefiles müssen natürlich nur dann erstellt wenn sich an der Konfiguration etwas ändert, also an den CMakeList.txt files. In IDEs geht automatisiert, beim Speichern der CMakeList.txt wird das Erstellen aufgerufen. Die generierten makefiles sind dann eben so das make/ninja die sehr schnell verarbeiten können.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Konfigurierbar via RECIPEPREFIX Rolf M. schrieb: > Können das alle, oder ist das eine Spezialität von GNU make? Weiss ich nicht, ich kenne nur GNU make. > Und findest du es sinnvoll, das umzukonfigurieren? Nein > Bei einem Makefile rechnet mit sowas doch keiner. Genau
Peter D. schrieb: > Ich selber benutze aber eine Batch, die den AVR-GCC einfach mit *.c > aufruft, das compiliert und linkt deutlich schneller. Ich kenne AVR-GCC nicht. Wer macht dabei den dependency-Kram, also dass nur die nötigen Schritte erfolgen?
Bruno V. schrieb: > Ich kenne AVR-GCC nicht. Kennst du einen gcc, kennst du alle. gcc ist gcc ist gcc ist gcc. > Wer macht dabei den dependency-Kram, also dass > nur die nötigen Schritte erfolgen? Niemand. Wer braucht schon solch neumodischen Kram? Einfach immer alles neu bauen ist das einzig wahre ;) Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Niemand. Wer braucht schon solch neumodischen Kram? Einfach immer alles > neu bauen ist das einzig wahre ;) Hehe, Kompilieren, Linken, HEX-file erzeugen, EEP-file erzeugen, Zeug ins Device flashen. Wer das manuell macht, hat die Kontrolle über sein Leben schon vor geraumer Zeit verloren.
Oliver S. schrieb: > Niemand. Wer braucht schon solch neumodischen Kram? Einfach immer alles > neu bauen ist das einzig wahre ;) Nein, ernsthaft. Peter wird ja nicht jedes Mal alles kompilieren, oder?
Bruno V. schrieb: > Nein, ernsthaft. Peter wird ja nicht jedes Mal alles kompilieren, oder? Nachdem, was er hier schon seit Jahren immer wieder über sein batchfile schreibt, tut er das. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Nachdem, was er hier schon seit Jahren immer wieder über sein batchfile > schreibt, tut er das. Vielleicht hat er ja die komplette ›make‹ Funktionalität eingebaut. Du weißt schon, Tab am Anfang der Zeile, usw…
Angehängte Dateien:
Ich habe mir vor längerer Zeit Gedanken über die generelle Struktur meiner Projekte gemacht und danach ein Makefile-Template "zusammegebaut", welches einfach die Sourcen aus dem "src" Ordner (auch mit Unterordnern) compiliert. Der von mir preferierte MCEDIT stellt die führenden Tabs in den Makefiles eigentlich schön dar (Bild). Da ich aber Leute kenne, die auch 2024 Wordvorlagen mit Leerzeichen "formatieren", kann ich die Problematik schon nachvollziehen ;-) Jörg
Bruno V. schrieb: > Nein, ernsthaft. Peter wird ja nicht jedes Mal alles kompilieren, oder? Doch, so viel Zeit kostet das ja nicht. Der Dependency-Kram hat bei mir nicht funktioniert. Z.B. _DATE_, _TIME_, Defines auf der Kommandozeile wurden nicht mehr aktualisiert.
> Defines auf der Kommandozeile wurden nicht mehr aktualisiert.
Warum Kommandozeile?
Bei mir steht da sowas im Programm:
uart_printf("RP2040 %s %s", _DATE_, _TIME_);
Und du hast recht, das wird nicht aktualisiert weil dependency
funktioniert. Schliesslich aendert sich der Source ja nicht.
Ich hab da einfach ein touch auf den betreffenden source im makefile
stehen und ja, dann wird bei mir main.c immer uebersetzt.
Aber ich gebe zu das hat einen kleinen Nachteil ueber dessen Loesung
ich auch gerade nachsinne. :-) Emacs noegelt dann immer wenn man im
anderen Fenster make ausfuehrt und man noch main.c im Editor hat
weil sich die Datei auf der Platte angeblich geaendert hat.
Da muss ich mich noch drei Tage von nerven lassen bis ich es
richtig loese. :-D
Vanye
Selbstgeschriebene Sourcen mit ein paar tausend Zeilen compilieren so schnell, dass sich der Make Aufwand nicht auszahlt. Zumindest solange die Sourcen nicht Header Files mit Hunderttausenden Zeilen reinziehen.
:
Bearbeitet durch User
Vanye R. schrieb: > anderen Fenster make ausfuehrt und man noch main.c im Editor hat > weil sich die Datei auf der Platte angeblich geaendert hat. > Da muss ich mich noch drei Tage von nerven lassen bis ich es > richtig loese. :-D Verwende vim, der lädt die Datei neu solange es keine Konflikte gibt 😉
Vanye R. schrieb: > Warum Kommandozeile? Z.B. sollte man beim AVR die F_CPU auf der Kommandozeile definieren, damit das delay-Macro immer richtig rechnet, Timerwerte, Baudraten stimmen usw.
Dieser ganze neumodische Kram - wer braucht sowas. Höhere Sprachen, wie etwa C = ist doch alles Hexerei. Ich finde, das es nicht mehr zeitgemäß ist sich an kleineren Projekten für einefache Mikrocontroller an der Compile Zeit aufzuhängen. Große Anwendungen hingegen, die auf richtigen Betriebssystemen laufen, da mag das schon wichtiger sein(Insbesondere C++ und Templates als Beispiel). Die Hürde ins CMAKE reinzufinden ist am Anfang da, klar. Nach 30 Jahren Entwicklung verständlich, dass das Einfinden in neue Themen mit viel Mühe verbunden ist. Mein Tip: Lass die Jugend machen und auch ihre Fehler machen. Statt erhobener Zeigefinger, so gut wie möglich reinfinden. Ist für alle am angenehmsten. Wenn alle an einem Strang ziehen, geht's gern immer nach vorn.
Udo K. schrieb: > Selbstgeschriebene Sourcen mit ein paar tausend Zeilen compilieren so > schnell, dass sich der Make Aufwand nicht auszahlt. hat man make einmal verinnerlicht, schreibt man Makefiles (im Vergleich zu Shell-Skripten) in der halben Zeit oder schneller.
Markus F. schrieb: >> Selbstgeschriebene Sourcen mit ein paar tausend Zeilen compilieren so >> schnell, dass sich der Make Aufwand nicht auszahlt. > > hat man make einmal verinnerlicht, schreibt man Makefiles (im Vergleich > zu Shell-Skripten) in der halben Zeit oder schneller. Ob man jetzt Makefiles oder Shell Skripte schneller schreibt sei dahingestellt. Aber Shell Skripte sind für kleine Testprojekte mit viel experimentellem Kram, vielen Variationen, und Nachbearbeitung der Ergebnisse irgendwie besser geeignet.
… und hier kann man wunderschön erkennen wie objektive Erkenntnisse: Markus F. schrieb: > hat man make einmal verinnerlicht, schreibt man Makefiles (im Vergleich > zu Shell-Skripten) in der halben Zeit oder schneller. und subjektive Erkenntnisse: Udo K. schrieb: > Aber Shell Skripte sind für kleine Testprojekte mit viel > experimentellem Kram, vielen Variationen, und Nachbearbeitung der > Ergebnisse irgendwie besser geeignet. einander diametral gegenüber stehen. ;-)
Vanye R. schrieb: > Bei mir steht da sowas im Programm: > > uart_printf("RP2040 %s %s", DATE, TIME); > > Und du hast recht, das wird nicht aktualisiert weil dependency > funktioniert. Schliesslich aendert sich der Source ja nicht. Die Source mit dieser Zeile ändert sich nicht, aber eine andere. Nach außen, für den Benutzer, ist es dann immer noch das alte Programm. > Ich hab da einfach ein touch auf den betreffenden source im makefile > stehen und ja, dann wird bei mir main.c immer uebersetzt. > Aber ich gebe zu das hat einen kleinen Nachteil ueber dessen Loesung > ich auch gerade nachsinne. :-) Emacs noegelt dann immer... Dagegen hilft eine winzige version.c (oder so, statt main.c), die man nie mehr anfasst, weil praktisch nichts drin steht. Dafür, dass das uart_printf immer die richtige Zeit liefert, sorgt bei mir ein Script, das eben diese version.c touchiert:
1 | #!/bin/sh
|
2 | # source_date_epoch.sh
|
3 | # Liefert die mtime der neuesten Quelldatei.
|
4 | #
|
5 | # Dank "touch" wird version.c immer genau dann neu compiliert,
|
6 | # wenn es irgendetwas neues gibt. Das Makefile erzeugt aus dem
|
7 | # Zeitstempel mit -D ein Macro und versorgt per export den gcc.
|
8 | #
|
9 | # Das Macro darf nur in version.c benutzt werden und __DATE__
|
10 | # und __TIME__ eigentlich garnicht. Die funktionieren nur dann
|
11 | # reproduzierbar, wenn alles komplett neu gebaut wird.
|
12 | |
13 | SOURCE_DATE_EPOCH=$(stat -L -c %Y \ |
14 | $HOME/src/make-flags.mk \ |
15 | $HOME/src/*/Makefile \ |
16 | $HOME/src/*/*.c \ |
17 | $HOME/src/*/*.h \ |
18 | | sort | tail -1) |
19 | |
20 | touch -d@$SOURCE_DATE_EPOCH version.c |
das wird im Makefile benutzt
1 | export SOURCE_DATE_EPOCH:=$(shell ./source_date_epoch.sh) |
2 | CFLAGS += -DSOURCE_DATE_EPOCH=$(SOURCE_DATE_EPOCH) |
und in version.c wird daraus time_t gemacht
1 | time_t
|
2 | source_date_epoch (void) |
3 | {
|
4 | time_t sde = SOURCE_DATE_EPOCH; |
5 | return sde; |
6 | }
|
https://reproducible-builds.org/docs/source-date-epoch/
Bauform B. schrieb: > Vanye R. schrieb: >> Bei mir steht da sowas im Programm: >> >> uart_printf("RP2040 %s %s", DATE, TIME); >> >> Und du hast recht, das wird nicht aktualisiert weil dependency >> funktioniert. Schliesslich aendert sich der Source ja nicht. > > Die Source mit dieser Zeile ändert sich nicht, aber eine andere. Nach > außen, für den Benutzer, ist es dann immer noch das alte Programm. > >> Ich hab da einfach ein touch auf den betreffenden source im makefile >> stehen und ja, dann wird bei mir main.c immer uebersetzt. >> Aber ich gebe zu das hat einen kleinen Nachteil ueber dessen Loesung >> ich auch gerade nachsinne. :-) Emacs noegelt dann immer... > > Dagegen hilft eine winzige version.c (oder so, statt main.c), die man > nie mehr anfasst, weil praktisch nichts drin steht. Dafür, dass das > uart_printf immer die richtige Zeit liefert, sorgt bei mir ein Script, > das eben diese version.c touchiert: Man kann Räder (auch in eckig und oval, wenn man will) neu erfinden oder einfach die von make dafür vorgesehene Syntax verwenden:
1 | version.o: .FORCE |
2 | |
3 | .FORCE: |
Auf die Weise wird version.o immer (unabhängig von version.c) neu erzeugt
schön, aber OS abhängig und funktioniert nicht unter Windows. CMake generiert makefiles passend zum OS. Oder direkt Projektfiles für einige IDEs. Und auch für Cortex-M bekomme ich Projekte mit über 1000 Sourcefiles hin, da möchte ich den Luxus von CMake nicht mehr missen. Neben der OS Unabhängigkeit werden die Abhängigkeiten richtig behandelt, auch wichtig für die Zusammenarbeit mit dem Intellisense. Und jedesmal 1000+ Quellen zu übersetzen macht erst recht keinen Spaß. Aber hier ist das ja nur ein Problem der jüngeren, was für ein Schwachsinn wieder.
Markus F. schrieb: > version.o: .FORCE > .FORCE: > > Auf die Weise wird version.o immer (unabhängig von version.c) neu > erzeugt Das liefert mir nur den make-Zeitpunkt, nicht die letzte Quelltextänderung. Das ist ein großer Unterschied, wenn man alles auf einem anderen Rechner neu baut. Von Distributions-Paketen garnicht zu reden. Außerdem müsste ich die DATE und TIME strings auch noch zerfieseln, nein danke.
Bauform B. schrieb: > Das liefert mir nur den make-Zeitpunkt, das liefert dir - ausser einem neuen version.o - erstmal überhaupt nix. Es stellt nur sicher, daß version.o neu erzeugt wird, obwohl der Zeitstempel aktuell ist. Für deine Anforderung kannst Du statt des Shellscripts auch einen
1 | $(shell ...) |
-Aufruf in dein Makefile packen.
:
Bearbeitet durch User
> Selbstgeschriebene Sourcen mit ein paar tausend Zeilen compilieren so > schnell, dass sich der Make Aufwand nicht auszahlt. Das stimmt nicht. Zum einen schreibt man sich ein Makefile nur selten mal neu. Ich kopiere es bei einem neuen Projekt immer nur von einem alten Projekt und aender ein paar Zeilen drin. Andererseits, wenn man ein neues Projekt fuer eine andere Hardware aufsetzt, zum Beispiel arm nach riscv dann wird man merken das es doch einiges an Aufwand ist die Umgebung anzupassen, dann lohnt es sich also auch. Vanye
Peter D. schrieb: > Z.B. sollte man beim AVR die F_CPU auf der Kommandozeile definieren, > damit das delay-Macro immer richtig rechnet, Timerwerte, Baudraten > stimmen usw. Ja, daher definiert man das im makefile dann auch so. Oliver
Peter D. schrieb: > Bruno V. schrieb: >> Nein, ernsthaft. Peter wird ja nicht jedes Mal alles kompilieren, oder? > > Doch, so viel Zeit kostet das ja nicht. Oben schreibst du noch das Gegenteil: Peter D. schrieb: > Die 30 Aufrufe des AVR-GCC darin dauern schon etwas. Vanye R. schrieb: > Und du hast recht, das wird nicht aktualisiert weil dependency > funktioniert. Schliesslich aendert sich der Source ja nicht. > Ich hab da einfach ein touch auf den betreffenden source im makefile > stehen und ja, dann wird bei mir main.c immer uebersetzt. Es reicht, das Target unter .PHONY zu listen, dann weiß make, dass es die Datei immer neu erzeugen muss. An-touchen muss man das File dann nicht. Das löst auch dieses Problem: > Emacs noegelt dann immer wenn man im anderen Fenster make ausfuehrt und > man noch main.c im Editor hat weil sich die Datei auf der Platte > angeblich geaendert hat. Markus F. schrieb: > Man kann Räder (auch in eckig und oval, wenn man will) neu erfinden oder > einfach die von make dafür vorgesehene Syntax verwenden: > version.o: .FORCE > .FORCE: Dazu konnte ich in der Doku von GNU make nur das finden: https://www.gnu.org/software/make/manual/html_node/Force-Targets.html Da steht auch, wie die tatsächlich dafür vorgesehene Syntax ist:
1 | .PHONY: version.o |
Bauform B. schrieb: > Das liefert mir nur den make-Zeitpunkt, nicht die letzte > Quelltextänderung. Das ist ein großer Unterschied, wenn man alles auf > einem anderen Rechner neu baut. Wie willst du letzteres überhaupt hinbekommen, wenn du auf einem anderen Rechner neu baust? Woher soll der andere Rechner wissen, wann auf dem einen Rechner zuletzt irgendeine der Dateien geändert wurde?
Rolf M. schrieb: > Da steht auch, wie die tatsächlich dafür vorgesehene Syntax ist: Geht beides, aber .PHONY gibt's nur bei GNU make.
Rolf M. schrieb: > Bauform B. schrieb: >> Das liefert mir nur den make-Zeitpunkt, nicht die letzte >> Quelltextänderung. Das ist ein großer Unterschied, wenn man alles auf >> einem anderen Rechner neu baut. > > Wie willst du letzteres überhaupt hinbekommen, wenn du auf einem anderen > Rechner neu baust? Woher soll der andere Rechner wissen, wann auf dem > einen Rechner zuletzt irgendeine der Dateien geändert wurde? Damit der neu bauen kann, braucht er doch die Dateien ;) Wenn die mit tar verpackt und ausgepackt wurden, bleiben die Zeitstempel doch erhalten.
> Damit der neu bauen kann, braucht er doch die Dateien ;)
Das ist natuerlich richtig. Allerdings wenn ich etwas komplett
umziehe dann mache ich immer auch mal ein make clean und baue
alles neu, einfach mal um zu sehen das auch alles noch geht.
Man erlebt ja auch schon gelegentlich eine interessante
Ueberraschung.
Vanye
Rolf M. schrieb: > Peter D. schrieb: >> Die 30 Aufrufe des AVR-GCC darin dauern schon etwas. Der Unterschied 30s vs. 10s ist merkbar, aber kein Grund zur Panik.
Vanye R. schrieb: >> Damit der neu bauen kann, braucht er doch die Dateien ;) > > Das ist natuerlich richtig. Allerdings wenn ich etwas komplett > umziehe dann mache ich immer auch mal ein make clean und baue > alles neu, einfach mal um zu sehen das auch alles noch geht. Mit etwas Glück geht alles noch, also muss keine Datei angepasst werden, also ist es immer noch die alte Version. > Man erlebt ja auch schon gelegentlich eine interessante Überraschung. Zweifellos, aber sonst wird's ja langweilig ;)
Peter D. schrieb: > Vanye R. schrieb: >> Warum Kommandozeile? > > Z.B. sollte man beim AVR die F_CPU auf der Kommandozeile definieren, > damit das delay-Macro immer richtig rechnet, Timerwerte, Baudraten > stimmen usw. Nunja, das kann man wohl mit jeder IDE und jedem Buildsystem (mehr oder weniger) problemlos realisieren. Dafür muss man sich wirklich nicht mit Batch-Dateien und der Kommandozeile rumschlagen. Allerdings: In jede IDE und jedes Buildsystem muß man sich erst einarbeiten, um die Stelle zu finden, wo man das eintragen muss. Das ist manchmal auch garnicht so einfach. Das wirklich Schlimme an diesen aufgeblasenen Buildsystemen ist, dass sie sich unwahrscheinlich schlecht debuggen lassen. Dagegen sind die Debugmöglichkeiten der eigentlichen Software auf den Targets richtig geil. Ich z.B. hadere enorm mit cmake. Es kommt immer wieder vor, dass ein Build fehlschlägt, ohne dass es einen einsichtigen Grund dafür gäbe. Ich kann nie rausfinden, warum er fehlschlägt (auch weil mir die Zeit dafür zu schade ist). Weil: es ist viel einfacher, den Build-Cache komplett zu löschen. Danach klappt der Build auf einmal wieder. Ohne jede Änderung an den Quellen oder den cmake-Konfig-Dateien... Sprich: der Scheiß ist einfach nur dramatisch buggy und auch die Entwickler dieses völlig overengineered Mists sind selber daran gescheitert, ihren eigenen Scheiß hinreichend für eine Produktivumgebung zu debuggen.
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.