Forum: Compiler & IDEs Makefiles im C-Projekt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Karlheinz (yuyu)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

Wenn es schnell bauen soll und ein großes Projekt wird, dann cmake, 
ninja und ccache.

von Jack V. (jackv)


Lesenswert?

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
von 900ss (900ss)


Lesenswert?

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.

von Jürgen (jliegner)


Lesenswert?

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.

von Bruno V. (bruno_v)


Lesenswert?

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.

von Monk (roehrmond)


Lesenswert?

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?

von 900ss (900ss)


Lesenswert?

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
von Jack V. (jackv)


Lesenswert?

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.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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.

von Clemens L. (c_l)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.
von Bruno V. (bruno_v)


Lesenswert?

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.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

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.

von Klaus (feelfree)


Lesenswert?

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.

von Norbert (der_norbert)


Lesenswert?

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.

von Klaus (feelfree)


Lesenswert?

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...

von Monk (roehrmond)


Lesenswert?

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.

von Norbert (der_norbert)


Lesenswert?

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…)

von Monk (roehrmond)


Lesenswert?

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.

von G. K. (zumsel)


Lesenswert?

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?

von 900ss (900ss)


Lesenswert?

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
von Monk (roehrmond)


Lesenswert?

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
von 900ss (900ss)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Udo K. (udok)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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).

von Vanye R. (vanye_rijan)


Lesenswert?

> - 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

von Norbert (der_norbert)


Lesenswert?

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.

von Klaus (feelfree)


Lesenswert?

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.

von Norbert (der_norbert)


Lesenswert?

Klaus, ich bin mir nicht vollständig sicher das ich so etwas geschrieben 
habe. Aber du bist nicht der Erste der falsch zitiert. ;-)

von 900ss (900ss)


Lesenswert?

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 ;)

von Monk (roehrmond)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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
von Klaus (feelfree)


Lesenswert?

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
von Norbert (der_norbert)


Lesenswert?

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. ;)

von 900ss (900ss)


Lesenswert?

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.

von Norbert (der_norbert)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Monk (roehrmond)


Angehängte Dateien:

Lesenswert?

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
von 900ss (900ss)


Lesenswert?

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
von Norbert (der_norbert)


Lesenswert?

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!

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Monk (roehrmond)


Lesenswert?

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
von Klaus (feelfree)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von Monk (roehrmond)


Lesenswert?

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.

von Klaus (feelfree)


Lesenswert?

Steve van de Grens schrieb:
> Dein Gemeckere ist vollkommen sinnlos.

Dein Gemeckere an mir ebenso.

von Norbert (der_norbert)


Angehängte Dateien:

Lesenswert?

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‹!

von Monk (roehrmond)


Lesenswert?

Klaus schrieb:
> Dein Gemeckere an mir ebenso.

Das stimmt wohl

von Udo K. (udok)


Lesenswert?

Wer über TAB in Makefiles diskutiert, hat noch nie ernsthaft Make 
verwendet.  Das TAB ist noch nicht mal ein Problemchen...

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Bruno V. (bruno_v)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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?

von Ein T. (ein_typ)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Bruno V. (bruno_v)


Lesenswert?

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.

von Norbert (der_norbert)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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

von Monk (roehrmond)


Lesenswert?

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
von Ein T. (ein_typ)


Lesenswert?

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. :-)

von Rolf M. (rmagnus)


Lesenswert?

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.

von Klaus (feelfree)


Lesenswert?

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.

von Monk (roehrmond)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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
von Bruno V. (bruno_v)


Lesenswert?

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
von Rolf M. (rmagnus)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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...

von Norbert (der_norbert)


Lesenswert?

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?

von Bauform B. (bauformb)


Lesenswert?

Norbert schrieb:
>> aber TAB ging mit CTRL-H...
>
> Ähm, CTRL-I vielleicht?

danke, nicht nur vielleicht :(

von Oliver S. (oliverso)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Norbert (der_norbert)


Lesenswert?

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

von Norbert (der_norbert)


Lesenswert?

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!

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Norbert (der_norbert)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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?

von J. S. (jojos)


Lesenswert?

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
von Monk (roehrmond)


Lesenswert?

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

von Bruno V. (bruno_v)


Lesenswert?

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?

von Oliver S. (oliverso)


Lesenswert?

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
von Norbert (der_norbert)


Lesenswert?

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.

von Bruno V. (bruno_v)


Lesenswert?

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?

von Oliver S. (oliverso)


Lesenswert?

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
von Norbert (der_norbert)


Lesenswert?

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…

von Joerg W. (joergwolfram)


Angehängte Dateien:

Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Udo K. (udok)


Lesenswert?

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
von Udo K. (udok)


Lesenswert?

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 😉

von Peter D. (peda)


Lesenswert?

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.

von Joe J. (j_955)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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.

von Udo K. (udok)


Lesenswert?

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.

von Norbert (der_norbert)


Lesenswert?

… 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. ;-)

von Bauform B. (bauformb)


Lesenswert?

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/

von Markus F. (mfro)


Lesenswert?

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

von J. S. (jojos)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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
von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Oliver S. (oliverso)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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?

von Markus F. (mfro)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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.

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Peter D. (peda)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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 ;)

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.