F
@john-0 sagte in GCC 16.1.0 und Modules:
Noch eine Anmerkung dazu. Ich nutze direkt GNU make und schreibe die Regeln selbst, weil das schon deutlich früher ging, und man so die Flexibilität hat, alles unter Kontrolle zu haben. Mit CMake kann ich mich nicht anfreunden, und wahrscheinlich sollte ich mal meson o.ä. anschauen. b2 wird wohl außerhalb von boost kaum genutzt.
CMake macht auch auf mich einen furchtbar klobigen und inkonsistenten Eindruck (besonders die Sprache!), aber es ist am Ende erstaunlich zuverlässig und portabel. Bei Build-Systemen ist mir vor allem wichtig den Build z.B. von Bibliotheken leicht an meinen übergeordnetes Projekt anpassen zu können, z.B. Compiler-Flags in den Build zu injizieren, da ich in vielen meiner Projekte auch die Abhängigkeiten mit den selben Flags aus dem Quellcode baue.
CMake machte da bisher immer die wenigsten Scherereien, aber das kann auch daran liegen, dass ich selbst viel mit CMake arbeite und daher weiss, wo ich ansetzen muss, damit es tut, was ich will. Viele Probleme ergaben sich auch daraus, wie die anderen Projekte definiert waren - wenn die z.B. eigene Flags hinzufügen, die sich mit meinen übergeordneten Flags beißen, wird es immer fummelig und ein Krampf da herum zu arbeiten. Egal was für ein Build-System.
Ein simples Beispiel sind z.B. Flags für Optimierung und Debug-Symbole (-O0/-Og/-O3, -g, -flto, etc.). Ich hätte am liebsten, wenn sich Build-Skripte diese Flags überhaupt nicht modifizieren sondern lediglich übernehmen, was sie in CFLAGS, CXXFLAGS oder LDFLAGS übergeben bekommen. Leider ist das aber nicht immer der Fall und viele Builds fügen da eigeneständig irgendwelche Flags hinzu ohne das konfigurierbar zu machen. Das macht es dann extrem schwer, alle Abhängigkeiten mit konsistenten Flags zu bauen.
Meson war da eigentlich auch immer ganz okay, am schlimmsten ist da m.E. Autotools, besonders wenn die Projekte obendrauf noch viel mit eigenen Skripten arbeiten. Wenn da irgendwas schief läuft, kann man sich auf ein paar Stunden Problemsuche einstellen, bis es dann endlich läuft.
Handgeschriebene Makefiles sind für simple Projekte okay, aber wenn es komplexer wird, dann sind diese meist nicht flexibel genug, meine Anfordungen zu erfüllen. Da sind dann leider zu oft Annahmen über Compiler und Zielsystem in das Makefile eingebettet und ich muss die dann per Hand anpassen.
Und was Module angeht: Das kann man sicher gut manuell in einem Makefile machen, aber man muss dabei schon genau wissen welche internen Abhängigkeiten die einzelnen Quellcode-Dateien haben und den Build der zugehörigen BMIs manuell "mitpflegen". Module haben ja die Eigenart, dass man einer Quellcodedatei von außen nicht ansieht, von welchen BMIs sie abhängt, ohne die Datei selbst zu parsen und zu schauen, welche Module sie importiert (und das ganze natürlich rekursiv um alle transitiven Modul-Abhängigkeiten zu finden!).
Du kannst also keine einfachen Makefile-Regeln definieren, um die BMIs zu bauen. Stattdessen muss man erstmal den Compiler bitten, die Quellcode-Dateien zu parsen und die Modul-Abhängikeiten zusammenzutragen. Oder man trägt es alles manuell ein, läuft dann aber Gefahr, dass man etwas vergisst, wenn man ein paar imports ändert. Das ist halt Fummelei, die ich selbst lieber automatisiert hätte, daher lasse ich das CMake machen. Das sammelt nämlich die Modul-Abhängigkeiten automatisch und baut die BMIs entsprechend, wenn ich importierte Module im Quellcode ändere.