Moderne Build-Systeme für C++

Hallo,

Also alles was ich machen möchte, ist, ein Projekt mit vielen Headern in include/ , vielen Quelldateien in src/ und mit einigen sowohl Header- als auch Quelldateien ein wenig verstreuten Ordnern kompilieren. Ich will aber natürlich auch nicht jede neue Datei manuell eingeben müssen; es soll alles in den betroffenen Verzeichnissen kompilieren. Dabei möchte ich verschiedene Profile haben (Debug, Release, ReleaseWithDebugInfo, Profiling, ...), die sich jedoch nur im Ausgabeverzeichnis und in den Flags unterscheiden. Ferner möchte ich nicht, dass die Objekt-Dateien in die Verzeichnisse geraten, in denen die Quelldateien sind, sondern stattdessen in ein separates Verzeichnis, abhängig vom Profil. Die Pfade sollten auch alle relativ sein, damit ich die selbe Konfiguration auf einem anderen Computer (sowohl Unix- als auch NT-basierende) nutzen kann.

Das sind meine Anforderungen, denen ich mit verschiedenen Tools gerecht zu werden versucht habe. Meine Erfahrungen:
IDE (hauptsächlich Code::Blocks):
- Jede neue Datei muss manuell eingefügt werden; sprich, einfach "alles aus Verzeichnis src/ kompilieren" funktioniert nicht.
- Relative Pfade funktionieren auch nicht, gab immer Probleme, wenn ich Projektdateien zwischen verschiedenen Maschinen austauschte.
- Resourcenbiest: Lässt sich zwar von Code::Blocks nun weniger behaupten als von anderen IDEs aber nichtsdestoweniger ist so eine IDE, die konstant im Hintergrund läuft, eine unnötige Belastung für das System.

GNU make:
- Sehr, sehr schwierig zu schreiben; die meisten meiner etwas komplexeren Makefiles haben nicht funktioniert, aber vielleicht bin ich einfach zu dumm dafür.
- Ich habe es nicht hinbekommen, dass es immer nur genau diese Dateien kompiliert, die ich verändert habe. Geht das überhaupt?

Bash- / Batch-Scripts:
- Nicht portabel.
- Kompilieren, nur wenn nichts verändert wurde, nicht möglich.

Wie macht ihr das? Wie machen Software-Firmen das? C++17 wird ja wahrscheinlich immer noch keine Modules bekommen also werde ich drei weitere Jahre dazu verdammt sein, mit diesem Mist fertig zu werden.
Ich habe etwas von Python-basierten Build-Systemen gehört, aber ich kann kein Python also fiele das auch weg...

Danke im Voraus.

SeppJ

GNU Make wäre von der Anfangsbeschreibung her meine Empfehlung gewesen, aber ich kann auch deine Kritik da dran verstehen. Ich habe eigentlich keine Probleme damit und es ist genau für die beschriebenen Anforderungen da. Aber ja, es ist zunächst sehr komplex; ich habe eben einfach mal ein paar Nachmittage damit verbracht, es zu lernen. Wenn man das nicht kann, dann kann ich Make auch nicht empfehlen wüsste aber auch nichts besseres.

Es gibt auch Systeme, um Makedateien automatisch zu erstellen (cmake, GNU Autotools), um noch einmal eine Schicht abstrakter und systemunabhängiger zu werden. Die sind jedoch kaum weniger komplex als Make selber, so lange man also nur wenige Zielsysteme hat, lohnt sich das nicht wirklich, diese zu erlernen.

C++ Forumbot

Dieser Thread wurde von Moderator/in nachtfeuer aus dem Forum Rund um die Programmierung in das Forum Compiler- und IDE-Forum verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Wutz

ziemlich neu ist:

https://build2.org/

QtCreator: Ist alles mit dabei.

Finnegan

Wutz schrieb:

ziemlich neu ist:

https://build2.org/

Danke auch von mir für den Hinweis, ich schaue mir das gerade mal an da ich gernerell immer daran interessiert bin, was sich beim Thema Build-Systeme so alles tut.
Spätestens wenn man für verscheidene Zielplattformen und Compiler entwickelt, und auch noch auf verschiedenen Systemen kompilieren möchte, merkt man schnell was für ein "PITA" das alles ist

Ich selbst bin gerade sehr zufrieden mit CMake, dem in meinen Augen am wenigsten schrecklichen der Cross-Platform-Buildsysteme

Finnegan

Mechanics

ShadowClone schrieb:

QtCreator: Ist alles mit dabei.

Das ist überhaupt kein Build System. Wie wilst du das auf einem Build Server "ausführen"? QtCreator benutzt qmake. Wir benutzen übrigens auch qmake. Haben da aber sehr viel umgebaut, weil für komplexe Projekte einfach sehr viel an Funktionalität fehlt.

Mechanics schrieb:

ShadowClone schrieb:

QtCreator: Ist alles mit dabei.

Das ist überhaupt kein Build System. Wie wilst du das auf einem Build Server "ausführen"? QtCreator benutzt qmake. Wir benutzen übrigens auch qmake. Haben da aber sehr viel umgebaut, weil für komplexe Projekte einfach sehr viel an Funktionalität fehlt.

Wir haben auch Anpassungen. Aber die musst du bei komplexeren Projekten sowieso machen. Aber so Grundfunktionalitäten sind bei qmake geschenkt.

Mechanics

Dann schreib zumindest "qmake" und nicht "QtCreator".
Ich wüsste aber ehrlich gesagt nicht, warum jemand, der kein Qt benutzt, qmake benutzen wollen würde.

TyRoXx

produktionsbeauftragter schrieb:

Wie macht ihr das?

CMake. Das ist das, was du suchst.

produktionsbeauftragter schrieb:

Wie machen Software-Firmen das?

Irgendein Gemisch aus den unpassenden Optionen, die du aufgezählt hast, oder einfach CMake.

produktionsbeauftragter schrieb:

C++17 wird ja wahrscheinlich immer noch keine Modules bekommen also werde ich drei weitere Jahre dazu verdammt sein, mit diesem Mist fertig zu werden.

C++ Modules haben nichts hiermit zu tun. Das sind orthogonale Probleme. Auch mit Modules wird man CMake benutzen.

schön wäre ein Anhang zum C++ Standard mit der Beschreibung eines einheitlichen Build-Systems.

Finnegan

versionsnummer schrieb:

schön wäre ein Anhang zum C++ Standard mit der Beschreibung eines einheitlichen Build-Systems.

Build-Systeme machen im Allgemeinen noch wesentlich mehr, als lediglich dafür zu sorgen, dass ausschliesslich C++-Code gebaut wird, daher ist der C++-Standard nicht der richtige Ansatz.
C++-fremde Aufgaben von Build-System, die ich schon selbst genutzt habe:

- Linken des Programms (!)
- Bauen und einbinden von C-Code und Bibliotheken.
- Kompilierung und Durchführung von automatisierten Tests.
- Gernerieren der Entwickler-Dokumentation (z.B. via Doxygen) oder einer Nutzerdoku via Latex.
- Installation/Deinstallation von Programmen.
- Signieren von Programmen.
- Erzeugen von Installationspaketen.
- Vorverarbeitung von GLSL/HLSL-Shadern.
- Konvertierung und "verpacken" von Assets (Grafiken/Texturen, 3D-Modelle/Animationen, Audiodaten, Schriftarten, etc.).
- etc.

In dieser Richtung lassen sich noch beliebig viele andere Anwendungsfälle für in Build-System finden.

Finnegan

ein einheitliches Build-System kann ja offen für Custom Targets sein, solange garantiert ist, daß einige wesentliche Targets (incremental build, clean, debug, release) vorhanden sind, um aus Quellcode X die Binaries Y zu machen.

Wenn ich eine 3rd Party Library kompilieren muß, weil mein Code diese benötigt (und weil es keine plattformspezifisch einheitliche Spezifikation für Object Files gibt), dann interessiere ich mich weniger für Signaturen und Installationspakete, sondern mehr dafür, aus dem Quellcode Binaries zu machen, die ich linken kann, und zwar möglichst ohne daß ich in Makefiles herumfrickeln muß oder Build-Systeme installieren muß, die ich sonst gar nicht benutze.

Plattformspezifisch einheitliche Formate für Object Files und einheitliches Build-System für die o.g. Grund-Targets wären wirklich wünschenswert und würden die Schlagkraft von C++ vermutlich erhöhen, weil sich die Entwickler von Projekten mit zahlreichen 3rd Party Libraries mehr auf die eigentliche Entwicklung konzentrieren könnten und C++-Anfänger nicht noch Experten in make, cmake, bash ... werden müßten.