Dieser und noch weitere Artikel wurde von GPC erstellt.


Folgende Themen werden von diesem Artikel berührt:


Druckversion des Artikels


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?
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++

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.

Sie können Kommentare zu diesem Artikel im Forum schreiben. (Eine Registrierung ist nicht notwendig.)

Logo-Design: MastaMind Webdesign