[Abgetrennt] C++ und Build-Zeiten

[Jonathan]

Seien wir doch mal ehrlich, realistisch betrachtet, wird sich am verkrüppelten Build-System von C++ nix mehr ändern. Ich überlege echt, mich etwas mehr mit Rust zu beschäftigen, einfach weil es so viele Dinge die ich an C++ wirklich mag, aufgreift, und gleichzeitig so viele Dinge die ich an C++ doof finde, besser macht.
Kurze Kompilierzeiten sind jedenfalls definitiv was zum neidisch werden.

[Krishty]

Das Resultat bei 40k Zeilen in knapp 40 .cpps:

1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:01.17
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

1>Time Elapsed 00:00:00.87
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Wenn es alle falsch machen, macht man es eben selber besser. Mittlerweile bin ich bei rund 60k Zeilen und seit alle fremd-Header raus sind, dauert das Neukompilieren weniger als eine Sekunde. Beim ändern einzelner Zeilen ist die Kompilierzeit quasi nicht mehr spürbar. (Immernoch selbe Maschine wie damals.)

[Jonathan]

Hm, aber wie lange hat es gedauert, alle Header zu optimieren? Und wie schwierig ist sowas, wenn man auch noch eine handvoll externer Bibliotheken benutzen will?
Ich meine, es gibt so vieles, was theoretisch geht, aber ich würde gerne meine Programmiersprache als ein Hilfsmittel und nicht als das eigentliche Problem betrachten. Sprich, ich will nicht Wochen darauf verwenden, dass mein Programm später noch genau das selbe tut, jetzt aber schneller kompiliert. Und bei einer einmaligen Änderung wird es ja kaum bleiben...

[Krishty]

Und jeden Tag zehn Minuten auf den Build warten sind doch ein gerechtfertigter Preis für die enorm höhere Produktivität durch STL, boost, & Co., oder? Dann gibt es doch gar keinen Grund mehr, über die Kompilierzeiten zu meckern.

[Spiele Programmierer]

Ich möchte aber hohe Produktivität und einen schnellen Build.
Du kannst das als gierig bezeichnen, aber es gibt genug Sprachen die bewiesen haben, dass es geht.
Praktisch alle Sprachen die ich kenne kompilieren viel schneller. Von VB über C#, Java bis zu D und Rust.
C++ könnte das auch, nur gibt es eben leider das Includesystem, so das große Teile der Anwendung praktisch x mal kompiliert werden...

Ehrlich gesagt finde ich sehr schade, dass hier so wenig Fortschritte gemacht werden. Die meisten Leute stellen sich wohl lieber einen größeren Buildserver hin anstatt das Problem an der Wurzel zu packen.

[Krishty]

C++ könnte das auch, nur gibt es eben leider das Includesystem, so das große Teile der Anwendung praktisch x mal kompiliert werden...

Nein. Der Grund ist, dass alle Leute bei C++ Header-only-Bibliotheken wollen.

[Spiele Programmierer]

Das ist doch gar nicht wahr. Ich will so viele Dinge wie Möglich in den Source schieben.
Praktisch müssen viele Dinge wegen verschiedenen Gründen in den Header. Templates ist ein großer Punkt. Oder Makros. Oder weil man nicht möchte, dass der Optimizer mal wieder versagt.

Außerdem sind Header deshalb fürchterlich, weil man immer abwägen muss zwischen vielen Builddependencies durch zuvielen Includes und der Notwendigkeit so viele Header einzeln zu includieren (Komfort). Ich kann gut verstehen, warum Microsoft sich entschieden hat, alles in einen Header (Windows.h) zu schieben.

[Zudomon]

Sollte das dann nicht auch raus aus dem Vorstellungsbereich?
Dieser Post kann dann auch gelöscht werden, wenn von den Mods gelesen ;)

[Alexander Kornrumpf]

C++ könnte das auch, nur gibt es eben leider das Includesystem, so das große Teile der Anwendung praktisch x mal kompiliert werden...

Nein. Der Grund ist, dass alle Leute bei C++ Header-only-Bibliotheken wollen.

Ich dachte, die will man deshalb, weil es im C++ Ökosystem ansonsten keinen "runterladen-einbinden-läuft" Mechanismus für Bibliotheken gibt?!

[Schrompf]

Denke ich auch. C++ ist halt ein ziemlicher Murks, wenn man externe Libs einbinden will. Man kann durch das nicht standardisierte Name Mangeling und die ganzen lustigen Runtime-Konflikte bei Allokationen, Ausnahmen usw. ja praktisch eh keine vorgebauten Libs nehmen, sondern muss immer für seine Zwecke neubauen. Und da kommen einem dann diverse Schlaumeier-Libs in die Quere, die ihre eigenen Includes im Nachbarverzeichnis auf drei verschiedenen globalen Include-Pfaden ansprechen müssen, anstatt einfach relativ zu inkludieren.

Ich jedenfalls atme immer erleichtert auf, wenn ich herausfinde, dass eine Lib nur aus ein paar self contained headers besteht, oder meinetwegen auch noch eins zwei autarke CPP-Dateien im selben Verzeichnis. CMake ist für mich schon ein Grund, nach einer anderen Lib zu schauen, weil ich weiß, dass ich die resultierenden Projektstrukturen nie sinnvoll in mein Relative-Pfade-Dependency-System eingecheckt bekomme.

Selbst Assimp ist inzwischen zu einem solchen Monster verkommen, wo durch CMake auch noch irgendein File erzeugt wird, nur um irgendwelchen Package Maintainern irgendner Linux-Distribution entgegen zu kommen. Bäh.

[Jonathan]

All die Probleme würden sich halt schlagartig erledigen, wenn man kein hundsmiserables Build-System (das Wort klingt doof, kennt jemand ein besseres?) hätte. Ich meine, man will doch nur Header-Only, weil die die einzigen sind, die man wirklich leicht einbinden kann. Und man will nur deshalb Dinge in Source-Files schieben, weil Header die Kompilierzeit explodieren lassen.
Ich habe schon Tage damit verbracht, CMake-Skripte Debuggen zu müssen, die es nie hätte geben dürfen. Wieso kann ich nicht einfach Header- und Sourcefiles einer Bibliothek runterladen, in irgendeinen Standardordner verschieden und die Bibliothek mit etwas wie #use "AwesomeGraphics" einbinden? Die wird dann einmal in Byte-Code übersetzt und verursacht ab dann keine Mehrkosten mehr.
Ich meine, C++ schafft es ja noch nicht einmal, Code in Interface- und Implementationsdateien aufzuteilen. Man muss ja unbedingt in Headern auch private Member auflisten. Oder exotische Tricks anwenden, und jede Klasse zweimal schreiben.

Aber das alles sind halt wirklich gravierende Änderungen. Ohne jegliche Abwärtskompatibilität zu zerstören, wird man das wohl kaum irgendwie umsetzen können.

Hat jemand eigentlich Erfahrung mit Rust? Von dem was ich bisher gehört habe, ist das ein wenig wie "C++ aber diesmal richtig". Stimmt das?

[Alexander Kornrumpf]

Wieso kann ich nicht einfach Header- und Sourcefiles einer Bibliothek runterladen, in irgendeinen Standardordner verschieden und die Bibliothek mit etwas wie #use "AwesomeGraphics" einbinden?

GPL?

[Jonathan]

Naja, mein Reden ist schon idealisiertes Wunschdenken und hat mit der Realität nicht soo viel zu tun. Was aber nicht heißt, dass es nicht - theoretisch - möglich sein sollte.

Die GPL/LGPL ist dann auch nur noch ein Artefakt aus vergangenen Tagen. Die nimmt halt explizit Bezug auf den Build-Prozess, indem unterschieden wird, wie eine Bibliothek eingebunden werden darf, das ist ja nichts was man nicht auch ändern könnte. Man könnte natürlich auch irgendeine Form von Byte-Code ausliefern, den man dann später mit passenden Compiler Einstellungen zu Maschinencode umwandeln kann.
Oder was genau meintest du mit GPL?

[Alexander Kornrumpf]

Die Abhängigkeit scheint mir schon wechselseitig zu sein:

=> Ich will den Source meistens nicht deshalb, weil Richard Stallmann das sagt, sondern weil es keinen verlässlichen Weg gibt, Binärpakete auszuliefern, oder anders gesagt verfügbare Binärpakete dazu tendieren, mit meinem System inkompatibel zu sein.

<= In dem Moment wo man den Sorce braucht, kommt das Bedürfnis auf, diesen durch Lizenzen besonders zu schützen und das kann im Einzelfall die Distribution von Binärpaketen _noch_ komplizierter machen.