[X] Build-Systeme (Vorwort)

Artchi

Der Umfang und der Inhalt sind soweit i.O. Würde da nicht weiter ausholen.

GPC

Also gut, da anscheinend inhaltlich keine Einwände bestehen, bräuchte dieser Artikel dann die Rechtschreibprüfung.

Thanks in advance.

GPC

audacia

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äzliche 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 weitverbreitetes Build-System) benutzt, um ein Projekt zu builden.

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

1. Kompilieren des Source-Codes
2. Erstellen einer ausführbaren Datei
3. Vorbereitung für (plattformunabhängige) Verteilung von dem Programm

Aber Build-Systeme können noch mehr, man kann mit ihnen z.B. automatisch die Dokumentation seines Projekt 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 Verzeichnis-Bä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~(ist die Schreibweise nicht eher GTKmm oder gtkmm?)~, glibmm und die sigc++ verwendet, jedesmal 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/muss eine solche Datei noch viel mehr Informationen enthalten, aber wir beschränken uns auf's Minimalste.

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

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 eim 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.

GPC

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äzliche 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 weitverbreitetes Build-System) benutzt, um ein Projekt zu builden.

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

1. Kompilieren des Source-Codes
2. Erstellen einer ausführbaren Datei
3. Vorbereitung für (plattformunabhängige) Verteilung von dem Programm

Aber Build-Systeme können noch mehr, man kann mit ihnen z.B. automatisch die Dokumentation seines Projekt 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 Verzeichnis-Bä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, jedesmal 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/muss eine solche Datei noch viel mehr Informationen enthalten, aber wir beschränken uns auf's Minimalste.

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

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 eim 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.

GPC

@audacia Danke nochmal wegen der Korrektur

michba

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:

1. Kompilieren des Source-Codes
2. Erstellen einer ausführbaren Datei
3. Vorbereitung für (plattformunabhängige) Verteilung von dem Programm

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 Verzeichnis-Bä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/muss eine solche Datei noch viel mehr Informationen enthalten, aber wir beschränken uns aufs Minimalste.

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

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.

Mr. B

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:

1. Kompilieren des Source-Codes
2. Erstellen einer ausführbaren Datei
3. Vorbereitung für (plattformunabhängige) Verteilung von dem Programm

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:

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.

Mr. B

da gabs noch n paar kleine fehler.

dürfte dann auch fertig zum rausschicken sein.

Mr. B

GPC