Welches Build-System?

[Krishty]

Ich brauche ein vernünftiges Build-System für C++-lastige Projekte.

Anforderungen:

1. Unterstützung auf Windows und Mac, langfristig auch Linux
2. Unterstützung von nicht-C-Tools (HLSL-Compiler, Setups & Co.)
3. Unterstützung von verschiedenen Zielplattformen und -Konfigurationen (Debug, Instrumented, Release)
4. Muss die eigenen Tools bauen können (also im Build die Compiler kompilieren können)
5. Leerzeichen in Datei- und Ordnernamen (extra wegen make)
6. Unterstützung gleichnamiger aber unterschiedlicher Quelldateien in verschiedenen Binaries ohne Kollision
7. Multi-Threading
8. Wenn es größer als 100 MiB ist, ist es raus

Bisher fahre ich MSBuild, also Visual Studio-Solutions. Die erfüllen alle Punkte außer der Plattformunabhängigkeit, aber sie kommen mit dem Kompilieren der Compiler langsam an ihre Grenzen. (Man braucht für jeden Zwischenschritt ein neues Projekt und muss die Projektabhängigkeiten verketten, aber auch dann werden irgendwie nicht immer alle Outputs neu gebaut. Auch kollidieren gleichnamige HLSL-Dateien aus verschiedenen Projekten dauernd miteinander.)

Ich habe es mit Makefiles versucht, aber die scheitern an Leerzeichen in Ordnernamen. Die Unterstützung von mehreren Konfigurationen ist möglich, aber entweder mit viel Tipparbeit (für jede Datei und jede Konfiguration einen eigenen Build-Schritt eintragen?) oder mit make, das anderes make aufruft (und das kann wohl undurchsichtige Fehler produzieren; was ich von der Arbeit kenne).

Außerdem gibt es noch CMake (nutzt Microsoft für die STL?) und tausend andere Generatoren.

Was könntet ihr mir empfehlen?

[xq]

Wie im Jammer-Thread schon geantwortet, kann GNU Make durchaus mit Leerzeichen umgehen:

Code: Alles auswählen

all: a\ b

a\ b:
        echo "hi" > a\ b

(Nachtrag: Quoted Strings klappen nicht, hatte mit vertan)

Ich persönlich nutze mittlerweile für viele Projekte auch nur noch Makefiles, da diese überraschend einfach zu warten sind und der Komplexitätsgrad überschaubar bleibt.

Die Unterstützung von mehreren Konfigurationen ist möglich, aber entweder mit viel Tipparbeit (für jede Datei und jede Konfiguration einen eigenen Build-Schritt eintragen?) oder mit make, das anderes make aufruft (und das kann wohl undurchsichtige Fehler produzieren; was ich von der Arbeit kenne).

Der afaik sauberste Weg hierfür ist ifdef, mit dem man dann seine Buildconfig anpasst:

Code: Alles auswählen

# Wenn kein CONFIG gesetzt, nehmen wir `debug` an
CONFIG?=debug

# Abhängige Variableninitialisierung
ifeq ($(CONFIG),release)
FOOFLAGS=release
else
FOOFLAGS=debug
endif

all: foo bar

foo: # verwendet nur die abhängige variable
        echo "foo" $(FOOFLAGS) > foo

# verwendet komplett andere build-regeln
ifeq ($(CONFIG),release)
bar:
        echo "release-bar" > bar
else
bar:
        echo "debug-bar" > bar
endif

[Krishty]

Ah okay, und ich würde dann make CONFIG=debug für Debug-Builds aufrufen und make CONFIG=release für Release. Fein. Könnte ich zufällig auch beides in einem Rutsch kompilieren?

[Chromanoid]

Probiere doch mal Gradle. Sehr flexibel und der Support für verschiedene Plattformen wird immer besser. Es ist recht komplex aber zumindest nicht so "emergent" designt wie manch andere Build-Systeme. JVM müsstest du halt als Abhängigkeit schlucken. Kann man aber alles recht portabel halten. Bei Gradle gibt es extra eine bat/sh Datei zum Ausführen, um ohne Installation einer Distribution auszukommen. Das erledigt der sog. Gradle wrapper sozusagen on demand. Die committet man zusammen mit einer Mini-Jar.

https://docs.gradle.org/current/usergui ... jects.html

[xq]

Ah okay, und ich würde dann make CONFIG=debug für Debug-Builds aufrufen und make CONFIG=release für Release. Fein. Könnte ich zufällig auch beides in einem Rutsch kompilieren?

Die wahrscheinlich üblichste Variante ist:
Du hast im Root-Verzeichnis ein Makefile, welches "make all", "make debug", "make release" kann und dann jeweils für jede Komponente ein Untermakefile mit "make -f" (Datei wechseln) bzw. "make -C" (Ordner wechseln) aufruft. Dieses Makefile würde dann die Kinder eben jeweils aufrufen.

Bzgl. "Probleme mit Kindermakefiles" hab ich bisher noch nix gehört. Du kannst natürlich auch Include-Files für gemeinsam genutzte Konfig-Elemente nehmen, auch sehr angenehm.

Bzgl. Gradle: Ich fand Gradle so einen Moloch, dass ich nicht mal versuchen wollte, das zu verstehen :(

[Krishty]

Eben noch an Makefiles rumgetüftelt; das mit den Headern ist ja richtig übel. make versteht (logischerweise) nichts von #includes, also kann es auch keine Neukompilierung veranlassen, wenn sich ein abhängiger Header geändert hat. Entweder bildet man nun jedes #include als Abhängigkeit in der Makefile ab, oder man kompiliert blind alles neu. Damit habe ich dann auch endgültig verstanden, wofür es CMake gibt (und wofür der GCC Optionen hat, alle Header aus einer Datei auszuspucken).

Nun ist das händische Definieren jeder #include aber nicht so absurd wie man annehmen würde: Ich möchte ja schon länger meine Header wegschmeißen und auf Module umsatteln. Der Hauptgrund, warum ich’s meide, ist, dass MSBuild die Abhängigkeit durch import nicht erkennt und man alle Abhängigkeiten manuell behandeln muss. Also exakt wie make mit #include. Lol, alles Steinzeit.

Was die JVM angeht: Nö. Ein Antrieb, endlich von MSBuild wegzukommen, ist die stetige Umstellung Richtung PowerShell. PowerShell ist selbst auf meinem neuen PC inakzeptabel langsam zu starten (> 1 s nach Kaltstart) und schleppt das halbe .NET ein, deshalb will ich’s nicht mehr sehen.

An diesem Punkt ist eigentlich klar, was getan werden muss: Ich muss eine eigene IDE mit eigenem Build-System schreiben, um mit dieser Scheiße endgültig aufzuräumen … *rolleyes*

[Chromanoid]

Ich habe es noch nie eingesetzt und ich bin deine Liste nicht durchgegangen, aber vielleicht ist ja bazel einen Blick wert? https://docs.bazel.build/versions/maste ... l/cpp.html

[dot]

Leider gibt es kein wirklich gutes Buildsystem für C++. Zumindest wäre mir noch keines untergekommen. Aber das und das könnte dich vielleicht interessieren…

[kimmi]

Ich benutze seit Jahren CMake. Das hat sich, zumindest in meinen Projekten ( privater Natur sowie professionelles Zeug ) bewährt.

Wie kam ich dazu:

• Ich habe über Jahre meine eigenen Project-Files + makefile gepflegt, bis ich zusehends einen an der Waffel bekommen habe

• Daraufhin habe ich mit ( wie die Godot-Engine ) scons angeschaut und fand das großartig. Leider kam ich dann auf die Idee, VS so zu konfigurieren, dass ich debuggen kann und habe es gelassen.

• Ich habe bjam von boost benutzt, habe gelacht und es gelöscht

• Ich habe CMake eingesetzt und bin dabei geblieben

Ich benutze CMake für c/c++ mit C# und Python Bindings, generiere damit Code, kopiere Build-Artefakte und vieles mehr. Dazu benutze ich es, um plattform-unabhängig nur ein Build-System warten zu müssen ( also für verschiedene Windows-Versionen, Linux, MAC, Embedded-Versionen von Unix + vxWorks, Android etc. ) und es läuft.

Die CMake-Skripte sind hässlich, aber man findet schnell Hilfe ( Stackoverflow sei Dank ) und letztendlich generieren wir in Assimp damit sogar Debian-Packages.

[Krishty]

Kurzes Update:

Makefiles

Ich hatte nochmal mit Makefiles angefangen, weil ich halt gern alles Bottom-Up plane.

Makefiles sind an sich recht geil. Achtung: Sie erlauben beliebig komplexe Dinge. Man kann Ausdrücke schreiben, die man selber nach einer Woche nicht mehr versteht. Dem muss man widerstehen! Wenn man bei den Grundlagen bleibt, sind sie ziemlich portabel. Ich konnte sowohl auf Windows als auch auf Mac kompilieren, mit den jeweiligen Haus-Tools (nmake aus Visual Studio und make aus XCode). Auch für das Problem, zu einer C++-Datei die abhängigen Header zu finden, gibt es bewährte, portable Lösungen.

Hier ist das alles niederwälzende Aber: Ich benutze Leerzeichen in meinen Dateinamen. Und dafür haben GNU make und nmake unterschiedliche Syntax (Backslash-Leerzeichen vs. Anführungszeichen), die völlig inkompatibel ist. Man kann sich über Microsoft beschweren, dass sie ihre Extrawurst gebraten haben, klar. Dass make aber partout Anführungszeichen als Teil von Dateinamen und Ausdrücken wertet(!!!) ist nicht weniger lächerlich.

Ich habe hier hunderte Quelldateien mit Leerzeichen im Namen, und die werde ich nicht umbennen. Im Jahr 2020 ist mir das zu dämlich. Damit sind Makefiles für mich leider völlig unbrauchbar.

Ninja

Ninja ist das Low-Level-System, auf dem CMake & Co. mittlerweile aufbauen. Und das Ding ist verdammt geil: Eine einzige EXE pro Plattform ohne weitere Abhängigkeiten. Der gleiche Mechanismus wie Makefiles, aber stark vereinfacht, mit super Syntax. So weit verbreitet, dass ich mir keine Gedanken machen muss, dass das Projekt stirbt, falls der Haupt-Maintainer keinen Bock mehr hat. Ach, und es ist plattformunabhängig! Alle Pfade werden mit Forward Slashes angegeben, auch auf Windows, und unterstützen Leerzeichen!

Ninja-Dateien sind als unterste Schicht des Builds eigentlich dafür ausgelegt, von anderen Make-Systemen (wie CMake) erzeugt zu werden. Man kann sie meinen Tests nach aber trotzdem von Hand schreiben und pflegen. (Wenn man so bekloppt ist wie ich.)

Aber: Die stark vereinfachte Syntax und die Konzentration auf eine einzige Aufgabe (und das wirklich gut), fördern ein Problem zu Tage: Bedingte Kompilierung wird nicht unterstützt. Es wird alles gebaut, was vorgegeben ist. Nun gibt es aber unterschiedliche Konfigurationen (Debug vs. Release, Visual C++ vs. Clang, Windows vs. MacOS). Und damit steht man bei Ninja richtig tief in der Scheiße.

Immerhin gibt es Komposition, indem man eine Datei in eine andere inkludiert. Das bedeutet aber, dass man für alle Konfigurationen einzelne Dateien anlegt, und gemeinsame/spezielle Build-Pfade in andere Dateien auslagert. Statt einer einzelnen Makefile habe ich also 20 Ninja-Files.

Das Fehlen einfacher Bedingungen ist umso absurder, wenn man betrachtet, dass Ninja Extra-Code enthält, um Header-Analysen sowohl im GCC-/Clang-Format als auch im VC++-Format zu parsen. WTF?! Da war Weniger plötzlich nicht mehr Mehr?!

Okay, damit wären die Low-Level-Lösungen durch. Also weiter zu abstrakteren Lösungen wie CMake.

Falls die enttäuschen (oder keine C++-Modules unterstützen), kann ich Ninja immernoch als Notlösung verwenden.

[Krishty]

Fun fact: Ninja kann kein Unicode. Sie nehmen an, dass Ninja-Dateien immer ANSI sind(!!!). Sie parsen die Ausgabe der Build-Schritte, ohne die Kodierung zu kennen, und klatschen die Bytes des Ergebnisses aneinander und zeigen sie an. Sie konvertieren intern alles zu UTF-8 (weil, UTF-8-Everywhere!!!!1111) und lassen dann die Windows-Aufrufe zu UTF-16 zurückkonvertieren, was laut der Tabelle an die 10 % der Ausführungszeit ausmacht.

Guckt euch nur mal diesen Anfängerfehler an. Quasi der erste Unit-Test, den man für Lokalisierung schreibt. Man kriegt die Kinnlade nicht mehr hoch. Zehn Jahre alt ist das Projekt! Chromium und LLVM bauen drauf!

Und dann dieses Juwel:

If you're on the Visual C++ team, I would encourage you to internally communicate with the windows api team and request they offer real first class support for non-wide strings, so that a future version of Ninja can drop this ugly compatibility code entirely.

BWAHAHAHA jemand, der die Codepage auf ANSI setzt, beschwert sich, dass UTF-8 nicht Windows’ Lieblings-Encoding ist! So einen Linux-Depp lässt man den Pull Request für die Windows-Encoding-Fixes sichten!

Boah, ich kotze. Make kann keine Leerzeichen, Ninja kann kein Unicode. Und ich dachte immer, die bei Microsoft wären die Clowns.

Jetzt bin ich wirklich gaaaaanz nah davor, ein eigenes Build-System zu schreiben. Ninja erreicht tatsächlich viel höheren Durchsatz als MSBuild; ich kann mein Projekt für Visual C++ und Clang in zwei Sekunden komplett neu kompilieren (beide zusammen!). Ich mache mit Unicode grundsätzlich alles richtig und will einfache Conditionals haben. Also los …?!

[Tiles]

Ich kenne das Gefühl zu gut. So hats bei mir mit Blender angefangen. Aber bedenke, das Kind wirst du dann nicht mehr los :)

[Alexander Kornrumpf]

Ich bin nicht sicher ob der "Linux-Depp" hier wirklich das Problem ist. Der eigentliche Spaß geht ab https://github.com/ninja-build/ninja/pu ... -606100061 los.

Da hat man ja richtig Lust dieses Projekt in seine Infrastruktur einzubauen - nicht. Versteh mich nicht falsch, ich habe keinen Grund zu der Annahme, dass es bei den OSS-Projekten, die ich benutze anders läuft, aber sowas ist der Grund dass wir 2020 immer noch Diskussionen haben ob OSS "Enterprise Ready (tm)" ist.

Subjektiv habe ich den Eindruck, dass sich die Leute bei Linus die Attitüde und den Tonfall abschauen und nicht merken, dass das nur cool ist, wenn man Linus _ist_. In die andere Richtung kaum besser, oder denkt jemand dass der Hass gegenüber z. B. Lennart Poettering angemessen ist?

Und da bist du mit "Linux-Depp" auch voll Teil des Problems und nicht der Lösung. "Assume positive intent" und so.

[Krishty]

Der eigentliche Spaß geht ab https://github.com/ninja-build/ninja/pu ... -606100061 los.

Woah, so weit bin ich gar nicht vorgedrungen! Das grenzt ja an Beamtenkultur :-O

Subjektiv habe ich den Eindruck, dass sich die Leute bei Linus die Attitüde und den Tonfall abschauen und nicht merken, dass das nur cool ist, wenn man Linus _ist_. […] Und da bist du mit "Linux-Depp" auch voll Teil des Problems und nicht der Lösung.

Wieso? Ich weiß, wie es richtig geht, und nach zwei Jahren unter Linux-Entwicklern würde ich sagen, dass dort zwei völlig bekloppte Annahmen tatsächlich zu den religiösen Grundlagen gehören:

1. ein Betriebssystem darf nur auf UTF-8 basieren;
2. wenn der hingeklatschte Code-Pfusch unter Windows hurr durr macht, ist Microsoft schuld weil pöse.

… und beide finden wir hier wieder.

Die Beobachtung mit Linus ist aber klasse; den Zusammenhang hatte ich bisher übersehen.

In die andere Richtung kaum besser, oder denkt jemand dass der Hass gegenüber z. B. Lennart Poettering angemessen ist?

Keine Ahnung; nicht mein Thema. Darum würde ich dazu auch niemals so einen kräftigen Kommentar abgeben wie hier zum Win32-Encoding.

[Chromanoid]

Wenn Du doch ein eigenes Build-System baust :) Bitte teile es in einen deklarativen und einen imperativen bzw. funktionalen Teil auf. Letzteres kann man auch weglassen. Der deklarative Teil sollte nicht Turing-vollständig sein. Und verzichte auf eine DSL. Ich wäre dafür die Build-Logik (des nicht deklarativen Teils) über die Programmiersprache zu steuern in der auch das Projekt ist. Die API kann man dann ja für mehrere Programmiersprachen bereitstellen.

[Alexander Kornrumpf]

Richtig ist sicherlich die Erkenntnis, dass man alles selbst machen muss, wenn man nicht bereit ist, die nicht perfekte Arbeit anderer, von der man alternativ ohne Kosten profitieren könnte, als wohlmeinend aber eben nicht perfekt zu akzeptieren ohne in (wie auch immer milde) Beleidigungen zu verfallen.

Die meisten von uns akzeptieren wahrscheinlich den Tradeoff in dieser Art Situation entweder Geld auf den Tisch zu legen oder mit der Imperfektion zu leben, aber dass du den Tradeoff manchmal anders wählst macht natürlich das technisch spannende an deinen Beiträgen aus.

[Krishty]

Richtig ist sicherlich die Erkenntnis, dass man alles selbst machen muss, wenn man nicht bereit ist, die nicht perfekte Arbeit anderer, von der man alternativ ohne Kosten profitieren könnte, als wohlmeinend aber eben nicht perfekt zu akzeptieren ohne in (wie auch immer milde) Beleidigungen zu verfallen.

Wenn ihnen jemand einen Pull Request hinlegt, der ihre Fehler ordentlich korrigiert, und sie dann in Querulantentum verfallen und herummotzen, statt den einfach anzunehmen, kann ich das immernoch nicht als wohlmeinend interpretieren ;)

[Alexander Kornrumpf]

Wenn ihnen jemand einen Pull Request hinlegt, der ihre Fehler ordentlich korrigiert, und sie dann in Querulantentum verfallen und herummotzen, statt den einfach anzunehmen, kann ich das immernoch nicht als wohlmeinend interpretieren ;)

Ich weiß nicht ob du mal die 120 versteckten Kommentare zwischen dem, über den du dich beschwerst, und dem, den ich oben verlinkt habe, aufgeklickt hast. Da reviewt der "Linux-Depp" tatsächlich den Code. Jetzt kann man sich natürlich darüber streiten, ob der Reviewer überhaupt qualifiziert ist, den Code zu beurteilen (das Problem bei allen code reviews). Vielleicht sind es auch Verschlechterungen, die er fordert. Ich habe das nur überflogen und könnte es für plattformunabhängiges C++ wahrscheinlich sowieso nicht beurteilen. Jedenfalls passiert da was und sie einigen sich auf irgendwas.

Es fällt mir sehr schwer zu glauben, dass jemand sich diese Arbeit aus reinem Querulantentum macht. Vielleicht ist er nicht der richtige für den Job (er ist ein Volunteer, right?) aber für mich sieht das aus, als hätte er ernstes Interesse daran, das Ding gemerged zu bekommen, obwohl er, als "Linux-Depp" ja gar nichts von Fixes für Windows hat. Aus den Kommentaren am Ende wird das auch deutlich also dass er mergen will, nicht dass er ein "Linux-Depp" ist.

Und nachdem er die Arbeit da rein gesteckt hat, sagt ihm sein Maintainer per königlichem Erlass, dass das nicht gemerged wird bevor nicht jemand noch mehr Arbeit investiert, in ein völlig willkürliches Issue ohne irgendeinen Zusammenhang mit diesem. Und er muss sich gefallen lassen "Linux-Depp" genannt zu werden (was er wahrscheinlich nicht gesehen hat, aber egal).

Ich an seiner Stelle wäre an dem Punkt raus aus dem Projekt. Ich finde Open Source großartig, as much as your next guy, aber sowas ist scheiße. Es muss ja jeder selbst wissen aber nach meinem Empfinden ist da was mit der Kultur kaputt. Und mit deinem "Linux-Depp" machst du dich zu einem Teil dieser Kultur -- meine obige Klassifikation dessen als "Problem" war natürlich subjektiv.

All das ist völlig off-topic hier und ich habe kein Problem damit mir deinen quality content zwischen den kleineren "Ausrastern", die ja irgendwo auch zur Marke gehören rauszusuchen, aber ich denke wirklich, dass das Problem an der Geschichte nicht da liegt wo du es identifiziert zu haben glaubst.

[xq]

[Krishty]

Ich habe mir mal erlaubt, die Frustration meines letzten make-Anlaufs letzten Monat als Artikel über Stärken und Schwächen aufzuzeichnen. Ist auf Englisch und vor allem für mich selber, aber vielleicht hilft das jemandem: http://krishty.com/articles/build-systems-1-make.html

————

Wie im Jammer-Thread schon geantwortet, kann GNU Make durchaus mit Leerzeichen umgehen:

Code: Alles auswählen

all: a\ b

a\ b:
        echo "hi" > a\ b

Mittlerweile weiß ich, dass auch pures GNU Make nicht mehr mit Leerzeichen zurechtkommt, sobald man irgendwas mit Makros oder Funktionen oder Variablen macht. Diese Bug-Ticket hat jede Menge Beispiele. Es ist zwecklos außer für die einfachsten der einfachen Projekte.