Linken von Standardbibliotheken



  • @betzi1985 sagte in Linken von Standardbibliotheken:

    Ist mein Makefile denn korrekt für das statische einbinden der Standardbibliotheken?

    Das make läuft durch und Programm läuft auch, aber wird es so geschrieben, wie ich es gemacht habe?

    Nein, du gibst die Libs nicht beim Linkschritt an sondern beim Erzeugen des Objecfiles.



  • @hustbaer sagte in Linken von Standardbibliotheken:

    Ich würde dir eher empfehlen die Systeme wie z.B. CMake anzuschauen. Das ist zwar auch alles andere als schön, aber immer noch besser als handgeschriebene Makefiles. Vor allem unterstützt es auch modernere Build-Systeme wie Ninja.

    Und vor allem unterstützt CMake auch Out-of-Source-Builds. Das bedeutet, du hast deinen Source im Verzeichnis /a/b/c und kannst dann in ein völlig beliebiges Verzeichnis, also z.B. /a/b/d oder auch /e/f kompilieren. Du kannst dann ein Build-Verzeichnis für den Debug-Build machen und eines für den Release-Build. Dann brauchst du die .o-Dateien nicht ins .gitignore zu schreiben und zum Löschen löscht du einfach das komplette Build-Verzeichnis - und braucht nicht wie bei deinem "make clean" aufzupassen, nur die richtigen Dateien zu löschen. Sehr viel besser als die In-Source-Builds!


  • Mod

    @manni66 sagte in Linken von Standardbibliotheken:

    @betzi1985 sagte in Linken von Standardbibliotheken:

    Ist mein Makefile denn korrekt für das statische einbinden der Standardbibliotheken?

    Das make läuft durch und Programm läuft auch, aber wird es so geschrieben, wie ich es gemacht habe?

    Nein, du gibst die Libs nicht beim Linkschritt an sondern beim Erzeugen des Objecfiles.

    Außerdem sollte clean ein phony-Target sein. Aber ist das wirklich die Frage, wie die best-practices beim Schreiben von Makefiles sind?



  • @hustbaer sagte in Linken von Standardbibliotheken:

    Ich würde dir eher empfehlen die Systeme wie z.B. CMake anzuschauen. Das ist zwar auch alles andere als schön, aber immer noch besser als handgeschriebene Makefiles. Vor allem unterstützt es auch modernere Build-Systeme wie Ninja.

    Hey, ich schreibe das erstmal mit der Hand, weil ich verstehen möchte, wie diese Makefiles funktionieren und möchte es erstmal verstehen. Bevor mir ein Tool diese Arbeit abnehmen soll, muss ich erstmal verstehen, was denn genau passiert. CMake, schaue ich mir gerne mal an. Wie gesagt, später werde ich auch natürlich auch eine richtige IDE wie COdeBlock verwenden, aber um erstmal zu verstehen was passiert, möchte ich es gerne per Hand machen. Und erstmal mit 1,2 Dateien ist es einfach, ich will nicht erst in sowas einsteigen, wenn ich viele Dateien habe, dann ist es meistens zu Kompliziert.

    Und was meint ihr mit phony-Target?
    meint Ihr das

    .PHONY: clean
    clean:
    rm *.o



  • @betzi1985 sagte in Linken von Standardbibliotheken:

    Und was meint ihr mit phony-Target?
    meint Ihr das
    .PHONY: clean
    clean:
    rm *.o

    Ja: https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html

    Bevor mir ein Tool diese Arbeit abnehmen soll, muss ich erstmal verstehen, was denn genau passiert.

    Im Prinzip ist es nur "wenn sich Datei x geändert hat, die für y gebraucht wird, dann muss y neu kompiliert werden". Eigentlich guckt make generell auf die Zeitstempel der Dateien und führt Kommandos aus, wenn irgendeine Abhängigkeit neuer ist als das Ziel. Mehr ist das nicht.

    CMake, schaue ich mir gerne mal an.

    Ist relevant, wenn du nicht manuell alle Abhängigkeiten verwalten kannst und dich vor allem nicht damit beschäftigen willst, wann du welche Parameter an den Compiler und Linker übergeben musst (die sich je nach Compilerhersteller auch noch unterscheiden können). Du nennst CMake das Rezept: target xy hängt von diesen und jenen Sourcen und Libraries ab und CMake generiert dann entsprechende Makefiles (oder Dateien für andere Buildsysteme) für dich.

    Und erstmal mit 1,2 Dateien ist es einfach, ich will nicht erst in sowas einsteigen, wenn ich viele Dateien habe, dann ist es meistens zu Kompliziert.

    Für 1-2 Dateien kannst du auch einfach auf Kommandozeile g++ -O2 -Wall -Wextra -o meine-executable source1.cpp source2.cpp eingeben (ggf. noch -l library)



  • @wob

    Ja das mit den geänderten Dateien habe ich gemerkt. Wenn ich mehrmals das Makefile hintereinander ausführe, macht er nicht mehr viel, weil die Dateien sich nicht geändert haben. Ändere ich den Zeitstempel einer Datei mit touch, compiliert er diese wieder neu.

    Also sollte ich mich als Anfänger mit 2,3 Dateien niciht mit sowas beschäftigen?? Ich weiß auch, dass man mit einem Befehl compilieren und linken kann. Habe nur irgendwo mal gelesen, damit man es richtig versteht, soll man alles einzeln per Hand durchführen, aber ok, lasse das dann erstmal



  • @betzi1985 CMake ist auch ein eingenes Monster 🙂

    Bleib erstmal dabei, wenn du am Anfang sowieso keine großen externen Libraries hast und nur eine paar Source-Dateien hast.

    Je größer dein Projekt wird, desto schwieriger wird es, das Makefile aktuell zu halten. Ist zum Beispiel sichergestellt, dass eine Header-Datei von dir für alle .cpp-Dateien, wo dieser verwendet wird, als Abhängigkeit gelistet ist? usw. usf.

    Beschäftige dich später damit, spätestens wenn deine Make-Datei nicht mehr auf eine Bildschirmseite passt.


  • Mod

    Faustregeln:

    1. Es ist ein Übungsprogramm, nur für dich, dass du in deinem Leben vielleicht nur 5-10x übersetzen wirst, und es hat weniger als 5 Dateien -> Tipp die Kommandos selber auf der Konsole. Erstens lohnt es sich nicht, ein Makefile oder anderes Script dafür zu schreiben. Zweitens lernst du so die Compiler- und Linkeraufrufe kennen. Du willst ja schließlich verstehen, was deine Makefiles machen.
    2. Es ist ein ernstes Projekt, an dem du viele Wochen lang arbeiten wirst, und es oft übersetzen wirst, aber es ist nur für dich oder wenige Personen, und es hat weniger als 15 Dateien -> Schreib dir ein Makefile, gerne auch ganz von Grund auf von Hand. So lernst du den Zusammenhang zwischen Makefiles und den Kommandos, die du sonst von Hand tippen würdest. Und du lernst umgekehrt auch wie Makefiles funktionieren, so dass du 3. und 4. besser verstehst.
    3. So wie 2., aber mit mehr als 15 Dateien, oder es kommen auch mal neue Dateien hinzu: Beschäftige dich mit den fortgeschrittenen Features von Makefiles, wie automatische Dependencies, automatische Standardregeln, und so weiter. Damit bleibt das Makefile kurz und überschaubar, so wie im vorherigen Fall.
    4. Es ist ein großes Projekt und soll auch für Leute sein, denen du im Notfall nicht persönlich helfen kannst: Beschäftige dich mit Meta-Buildtools wie den GNU Autotools oder CMake, die das Makefile für den jeweiligen Benutzer automatisch erstellen.

    Bei 3. kannst du auch überlegen, stattdessen gleich zu 4. zu gehen. Make ist ein sehr altes und gewachsenes Programm und man sehr, sehr viel darüber lernen. Aber all das Wissen nützt dir nur etwas, wenn du regelmäßig Makefiles schreibst. Was du nicht tun wirst, denn irgendwann wirst du bei 4. landen. Es besteht auch eine gewisse Gefahr, dass du so gut mit Makefiles umgehen kannst, dass du nie so recht zu 4. kommst, weil dir auch komplizierte Makefiles leicht fallen und du deswegen die Einstiegshürde zu 4. scheust.



  • @SeppJ

    Dankeschön, das ist für mich ein super Anhaltspunkt.



  • @betzi1985 sagte in Linken von Standardbibliotheken:

    Hey, ich schreibe das erstmal mit der Hand, weil ich verstehen möchte, wie diese Makefiles funktionieren und möchte es erstmal verstehen. Bevor mir ein Tool diese Arbeit abnehmen soll, muss ich erstmal verstehen, was denn genau passiert.

    Nein, musst du nicht unbedingt. Du darfst es gerne wollen, aber, bei Seiner Nudeligkeit, verstehen/wissen muss man das nicht. Und normalerweise will man es auch nicht.


Anmelden zum Antworten