CMake weiß immer noch nicht, was seine Aufgabe ist.
(dorinlazar.ro)CMake fühlt sich zunehmend wie eine schlechte Lösung für C++ an. Es erfüllt nicht nur die Anforderungen von C++-Entwicklern nicht, sondern hält uns auch im dunklen Zeitalter fest, in dem Makefiles auf eine sehr unklare und unstrukturierte Weise mit einer inkonsistenten Sprache erzeugt werden.
Das Problem
In der Welt des C++-Builds gibt es zwei Arten von Problemen.
- Probleme, die bestehende Projekte sich selbst geschaffen haben (Anm. d. Übers.: Probleme beim Bauen bereits existierender großer Projekte)
- Probleme, die auftreten, wenn man in C++ ein neues Projekt auswählt
CMake versucht, das erste Problem zu lösen, und löst das zweite überhaupt nicht. Gerade weil es diese Probleme nicht zu lösen versucht, ist es ein weniger nützliches Werkzeug geworden.
CMake möchte ein Übersetzer sein, der Projektdefinitionen in Build-Systeme überträgt, und ist daran gravierend gescheitert. Es ist eine schlechte Sprache zur Projektdefinition, inkonsistent und nicht intuitiv.
Die gesamte C++-Community spricht inzwischen über die Tools von Rust. Cargo tut tatsächlich das, was die meisten Entwickler für nötig halten. Cargo lädt Abhängigkeiten aus dem Internet herunter, um ein isoliertes Toolkit zu erstellen (eine schlechte Idee), und stellt statisch gelinkte Bibliotheken bereit (ebenfalls eine schlechte Idee). Menschen brauchen kein Werkzeug, das mit enormer Geschwindigkeit Sicherheitslücken hinzufügt (Anm. d. Übers.: Der Autor argumentiert, dass Cargos Vorgehen, automatisch Code aus dem Internet zu holen und zu linken, aus Sicherheitssicht eine Schwachstelle wie etwa für Supply-Chain-Angriffe darstellt. Siehe I Hate Rust.), aber was Cargo tatsächlich bietet, wird gebraucht:
- eine sehr strikte Projektstruktur
- ein sehr einfaches Konfigurationssystem, das sich auf externe Server verlässt, um das Problem zu lösen, wo sich Bibliotheken befinden
- genau ein Toolset.
Menschen brauchen in Wirklichkeit weniger Freiheit, damit sie sich auf die eigentliche Arbeit konzentrieren können, und sie sind nicht darin geübt, den Compiler auf die bestmögliche Weise aufzurufen.
Die Lösung
Eine Lösung gibt es noch nicht. Ich schreibe in meiner Freizeit an klb, aber im Moment ist es keine Lösung. (Es braucht Zeit und Geld.)
Aber es ist klar, was Menschen brauchen: nicht mehr Optionen, sondern weniger Optionen. Weniger Optionen bedeutet, dass es weniger Möglichkeiten gibt, die Kompilierung eines Projekts zu ruinieren.
CMake ist in der C++-Welt derzeit immer noch die beste Option, aber zugleich auch das Schlimmste, was C++ in den letzten 20 Jahren passiert ist. Alles andere wird besser, aber die Build-Systeme werden nur schlechter.
10 Kommentare
Die Syntax ist zwar etwas unschön, aber etwas Besseres als CMake habe ich bisher nicht gefunden.
Wenn man so etwas wie M4 in einer Nicht-POSIX-Umgebung laufen lassen will, bekommt man schnell Kopfschmerzen.
Da ich von vornherein keine Build-Umgebungen mag, an denen alles Mögliche dranhängt, greife ich weder zu Meson noch zu SCons, und Premake wirkt auf mich auch irgendwie nicht ganz ausgereift. Deshalb lande ich am Ende doch bei CMake und nutze es einfach so schlicht wie möglich, im Grunde nur, um den Code zu definieren.
Ich habe CMake lange Zeit fluchend benutzt, aber am Ende gibt es doch kaum etwas, das so gut ist wie CMake. Bazel ist wirklich die Hölle … Wenn ich ein neues Projekt starten würde, würde ich wohl Meson in Betracht ziehen.
Wie sieht es mit Meson oder Bazel aus?
Ich habe beides noch nie verwendet, daher weiß ich es nicht genau...
Persönlich nutze ich für kleine Projekte gern
gprbuild.Andere Methoden als CMake sind genauso kompliziert
Plattformübergreifend ist es immerhin noch einigermaßen ...
Deshalb ist Visual Studio wohl so beliebt. Man kann sofort mit dem Coden anfangen.
Auch hier gilt allerdings: Wenn man ins Detail geht, ist das Thema praktisch unerschöpflich.
Schon der bloße Anblick von CMake löst bei mir Brechreiz aus...
Ich denke, man sollte CMake nicht als Ersatz für
make, sondern als Ersatz für autotools (automake) betrachten.Trotzdem scheint es vielleicht immer noch besser zu sein als einfach nur ein Makefile.
Letzten Monat musste ich eine Build-Umgebung analysieren, die aus Shell-Skripten, Perl, OS-Umgebungsvariablen und mehreren miteinander verwobenen Makefiles bestand, und ich wäre dabei fast wahnsinnig geworden.
Wenn man versucht, etwas bis ins Detail zu tun, gerät man in einen Kaninchenbau ...