C/C++ Forum :: Build-Systeme: Vorwort

GPC Moderator 12:22:51 04.12.2005 Titel:

Mit diesem Artikel leite ich einen Mehrteiler zu Build-Systemen ein, der von SideWinder, Talla, Artchi und mir verfasst wurde.
In diesem Artikel werde ich versuchen, grundsätzliche Fragen zu klären, um die Leser somit auf die kommenden Artikel vorzubereiten.

Inhalt:

1 Was ist ein Build-System?
2 Wozu brauche ich ein Build-System?
3 Allgemeine Funktionsweise von Build-Systemen
4 What comes next...

1 Was ist ein Build-System?
Sagen wir ruhig, wie es ist: Ein Build-System ist schlicht ein Tool, welches z.B. Source-Code kompiliert und auf Wunsch zu einer Executable linkt, also den Build-Prozess automatisiert. Nicht sehr aufregend? Das könnt ihr auch mit einer IDE, z.B. KDevelop? Dann dürfte es überraschend sein, dass KDevelop im Hintergrund die Autotools (ein weit verbreitetes Build-System) benutzt, um ein Projekt zu builden.

Ein Build-System fasst u. a. folgende Schritte zusammen:

Aber Build-Systeme können noch mehr, man kann mit ihnen z.B. automatisch die Dokumentation seines Projekts mitaktualisieren oder eine LaTeX-Datei erstellen.
Die meisten Build-Systeme sind sehr flexibel und mächtig in ihrer Anwendung; die Autotools z.B. kann man mit bash-Code und SCons mit Python erweitern, um sie spezielle Aufgaben erledigen zu lassen.

2 Wozu brauche ich ein Build-System?
Für das erste "Hello World"-Programm reicht ein kurzer Aufruf des Compilers, aber sobald man Projekte mit vielen Source-Dateien und mehreren Verzeichnisbäumen betreut, verliert man schnell den Überblick und hat auch keine Zeit mehr, um alles manuell durchzuführen. Genau hier kann einem ein Build-System die Arbeit erleichtern, indem es das komplette Programm mit ein, zwei Befehlen neu übersetzt. Das bedeutet höhere Produktivität und schnellere Builds.

Da es bei großen Projekten durchaus keine Seltenheit ist, dass der Build-Prozess einen halben Tag und mehr dauert, zeigt sich hier der Vorteil, dass kein Entwickler anwesend sein muss, um die einzelnen Schritte durchzuführen.
Außerdem wäre es auch viel stupide Tipparbeit, wenn ein Projekt, welches mehrere Bibliotheken wie Gtkmm, glibmm und die sigc++ verwendet, jedes Mal von Hand kompiliert und gelinkt werden müsste.

3 Allgemeine Funktionsweise von Build-Systemen
Vereinfacht gesagt arbeitet ein Build-System nach folgendem Schema: Es wird eine Konfigurationsdatei gelesen, in welcher u. a. Folgendes beschrieben ist: Was soll erstellt werden, wo liegt der Source-Code, welche Abhängigkeiten (z.B. in Form von Bibliotheken) gibt es und welcher Compiler soll benutzt werden.
Natürlich kann oder muss eine solche Datei noch viel mehr Informationen enthalten, aber wir beschränken uns auf das Minimale.

Um das zu verdeutlichen, werden wir ein hypothetisches Build-System betrachten. Eine Konfigurationsdatei könnte etwa so aussehen:

Code:
TARGET = BUILD_EXEC(FuzzyProgramm, SOURCE_DIR, LIBRARY_DEPENDENCIES, COMPILER) SOURCE_DIR = src/ LIBRARY_DEPENDENCIES = gtkmm; glibmm; sigc++; boost; COMPILER = g++

Code:
TARGET = BUILD_EXEC(FuzzyProgramm, SOURCE_DIR, LIBRARY_DEPENDENCIES, COMPILER) SOURCE_DIR = src/ LIBRARY_DEPENDENCIES = gtkmm; glibmm; sigc++; boost; COMPILER = g++

Code:
TARGET = BUILD_EXEC(FuzzyProgramm, SOURCE_DIR, LIBRARY_DEPENDENCIES, COMPILER) SOURCE_DIR = src/ LIBRARY_DEPENDENCIES = gtkmm; glibmm; sigc++; boost; COMPILER = g++

Das Build-System arbeitet einfach jeden Punkt ab und versucht, die Informationen, die es beim Einlesen der Datei erhält, Stück für Stück zusammenzusetzen, um den Build-Prozess durchzuführen, der hier nur aus Kompilieren und Linken besteht.
Hier z.B. sieht es, dass es eine Executable bilden muss (BUILD_EXEC(...)). Es holt sich dazu das Source-Verzeichnis und die benötigten Bibliotheken aus den Variablen SOURCE_DIR und LIBRARY_DEPENDENCIES, um sie dann mit dem Compiler aus COMPILER zu kompilieren und zu linken.

4 What comes next...
Jetzt, da die Grundlagen geschaffen sind, können wir beginnen, mehr ins Detail zu gehen. Mit jeder neuen Runde wird ein Artikel erscheinen, der sich mit einem Build-System auseinandersetzt.

Den Anfang wird SideWinder mit seinem Artikel über Ant machen. Wir dürfen gespannt sein.

Unregistrierter

Und was ist jetzt der Vorteil gegenüber einer IDE?

Korbinian Moderator 11:50:14 14.12.2005 Titel:

naja manche wollen keine ide verwenden, bei anderen projekten ist die umgebung zu gross, dass man nur einen teil bearbeitet.

GPC Moderator 12:10:44 14.12.2005 Titel:

hmmmmm schrieb:

Und was ist jetzt der Vorteil gegenüber einer IDE?

Es geht nicht darum, die Vor - und Nachteile von IDEs zu diskutieren. Wir wollen zeigen, was es für Build-Systeme gibt und wie sie arbeiten. Jedesmal wenn ihr in euren IDEs auf Build klickt, benutzt ihr in irgendeiner Form ein Build-System, KDevelop z.B. nimmt die autotools.

Termite Mitglied 12:20:26 14.12.2005 Titel:

Zu 2.

Sollte man nicht vergessen, das bei grossen Systemen es auch fehleranfälliger wird alles von Hand zu übersetzen. Wie schnell ist eine Datei vergessen neu zu compilieren und es wird doch die alte Object File dazu gelinkt.

Meist lassen sich auch andere Arbeiten mit erledigen. Wie z.B. Buildnummern generieren, Sourcen im Repository mit eiem Label versehen, Dateien für den Installer bereitstellen, ....

Artchi Autor 13:07:30 14.12.2005 Titel:

Der Sinn und Zweck ist doch aber eher, wenn man schon eine IDE hat, das man auch ohne IDE etwas erstellen kann. Das beste Beispiel ist doch boost. Warum sollen die Boost-Entwickler für jede IDE auf jedem OS (Windows, Mac usw) und für jeden Compiler eine Projekt-Datei bereit stellen? Nein, sie haben ihr bjam, tragen in die bjam-Steuerdatei ein, wie boost gebaut werden soll, und boost kümmert sich um den Rest (je nach OS und Compiler), unabhängig von der IDE.

In unseren Artikeln zu den Build-Tools geht es nur im entferntesten um IDEs.

Jester Moderator 12:12:14 17.12.2005 Titel:

Außerdem ist es günstiger einen cronjob einzurichten, der um 0:00 das Repository auscheckt und das Buildsystem laufen läßt, als einen Entwickler dafür zu bezahlen, daß er sich nachts an den Rechner setzt und in der IDE auf "build" klickt.

Oder kurz: für nightly builds nützt einem ne IDE wenig.

m3ph1570 Mitglied 12:28:28 17.12.2005 Titel:

@Jester:
Nicht ganz korrekt :xmas2: Ich hab vor ein paar Monaten ein Eclipse-Plugin für nightly builds entwickelt. Rudimentär, aber funktioniert. Checkt alle gewünschten Projekte aus dem CVS aus, baut sie und lässt gegebenenfalls sogar die Unit-Tests ablaufen. Am Morgen danach bekommt man dann eine schöne Zusammenfassung was funktioniert und was nicht.

Aber prinzipiell sind build-systeme sehr wichtig, v.a. was die Entwicklung im Team, sowie Plattformunabhängigkeit angeht. Und zuletzt sind die Build-Systeme durchaus um einiges leistungsfähiger und können z.B. Shellkommandos oder komplette Scripten in den build integrieren. So kann man z.B. immer automatisch eine zusätzliche Version generieren lassen, die sofort ausgeliefert werden kann.

SideWinder Moderator 13:00:45 17.12.2005 Titel:

m3ph1570 schrieb:

@Jester:
Nicht ganz korrekt :xmas2: Ich hab vor ein paar Monaten ein Eclipse-Plugin für nightly builds entwickelt. Rudimentär, aber funktioniert. Checkt alle gewünschten Projekte aus dem CVS aus, baut sie und lässt gegebenenfalls sogar die Unit-Tests ablaufen. Am Morgen danach bekommt man dann eine schöne Zusammenfassung was funktioniert und was nicht.

Das hättest du mit Ant ohne Probleme ebenfalls erledigen können

MfG SideWinder

m3ph1570 Mitglied 10:43:44 21.12.2005 Titel:

@sidewinder:
Naja, prinzipiell schon, aber nicht so schön und übersichtlich und vor allem vollständig in eclipse integriert.