Das Problem

Schon früh nach der Einführung von Compilern und mit dem Aufkommen der ersten, großen Softwareprojekte wurde klar, dass ein System benötigt wurde, welches den komplizierten und fehlerträchtigen Prozess der Umwandlung von Quellcode zu lauffähiger Software koordiniert. Natürlich lässt sich bis zum heutigen Tag jeder Compiler manuell ohne eine solche Automatisierung aufrufen und für Mini-Projekte mag dies auch ausreichend sein, dennoch kommt man heutzutage nicht um ein ausgefeiltes Build System herum, welches diese Aufgabe erledigt. Das Problem dabei ist nur, dass es eine unermessliche Anzahl solcher Systeme gibt, sowohl im Bereich der freien als auch der proprietären Software. Hinzu kommen moderne IDEs, welche ebenfalls derartige Features integrieren.

Gerade bei quelloffener Software können die GNU Autotools als Platzhirsch bezeichnet werden. Aufgrund ihre langen Verfügbarkeit und der langjährigen Unix-Erfahrung der GNU-Entwickler bieten diese einen großen Funktionsumfang, gelten allgemein jedoch als komplex und schwer verständlich. Aus diesem Grund sind mit QMake, CMake, Scons, Waf und vielen weiteren nennenswerte Alternativen entstanden, die an dieser Stelle ebenfalls untersucht werden sollen.

Das Testprogramm

Alle Build Systeme sollen anhand desselben Beispiels untersucht werden. Es handelt sich um ein einfaches C-Programm, das neben der Standard C-Blbiothek noch libcaca braucht, um compiliert und gelinkt zu werden. Somit wird verhindert, dass ein einfache Aufruf von gcc ohne weitere Parameter genügt. libcaca ist eine einfache Ascii Art-Bibliothek mit wenig Systemanforderungen. Sie wurde gewählt, da sie relativ kompakt ist und eine einfache API besitzt, welche das Testprogramm nicht unnötig verkompliziert.

/*
 *  build_test.c
 *  Copyright 2009 Dennis Schulmeister <dennis()ncc-1701a.homelinux.net>
 *
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation; either version 2 of the License, or
 *  (at your option) any later version.
 */

/* libc standard */ 
#include <string.h>

 /* Non-standard library */
#include "caca0.h" /* libcaca-dev */


int main(int argc, char** argv) {
      /* Set up a display to draw upon */
     if (caca_init()) {
         return 1;
     }

     /* Draw something */
     {
         int width  = caca_get_width();
         int height = caca_get_height();

         /* Background */
         caca_set_color(CACA_COLOR_GREEN, CACA_COLOR_GREEN);
         caca_clear();

          /* First message */
         caca_set_color(CACA_COLOR_RED, CACA_COLOR_BLACK);
         caca_draw_thin_box(1, 1, (width - 2), 3);

         int i;
         for (i = 1; i <= width - 2; i++) {
             caca_putstr(i, 2, " ");
         }

         char* message = "Hello, World!";
         caca_putstr((width - strlen(message)) / 2, 2, message);

          /* Second message */
         caca_set_color(CACA_COLOR_YELLOW, CACA_COLOR_BLUE);
         caca_draw_thin_box(3, 5, (width - 6), 3);

         for (i = 4; i <= width - 5; i++) {
             caca_putstr(i, 6, " ");
         }

         char* message1 = "Press ESC to exit";
         caca_putstr((width - strlen(message1)) / 2, 6, message1);

          /* Show it */
         caca_set_window_title(message1);
         caca_refresh();
     }

     /* Wait for ESC key */
     {
         int quit = 0;
         while (!quit) {
             int event;
             while ((event = caca_get_event(CACA_EVENT_KEY_PRESS))) {
                 if ((event & 0xffff) == CACA_KEY_ESCAPE) {
                     quit = 1;
                 }
             }
         }
     }

      /* Clean up */
     caca_end();
     return 0;
}

Das Programm zeichnet zwei Boxen mit einem "Hello, World!"-Text und einem Hinweis, dass das Programm mit ESC beendet werden kann. Da hierfür eine einfache Polling-Schleife verwendet wird, ist das Warten sehr CPU-intensiv. Auf eine Verbesserung dessen via usleep() und dergleichen wird dennoch verzichtet.

In den folgenden Unterkapiteln werden verschiedene Varianten des Testprogramms verwendet, um auch Situationen nachzustellen, in denen aus mehreren Quelldateien mehrere Objektdateien entstehen. Trotz dieser Abweichungen bleibt das Ausgangsprogramm aber immer das gleiche,

Die Lösungsansätze

Folgende Lösungsansätze werden auf jeweils einer eigenen Seite näher beschrieben:

• Direktaufruf aller Werkzeuge ohne Build System
  
• Einfache make-Files für GNU make?
  
• Mit GNU Autotools generierte make-Files?
  
• Mit Trolltech QMake generierte make-Files?
• MIt Premake generierte make-Files?
• CMake statt make?
• Rake statt make?
• BSDBuild im Sourcetree?
• Scons (Python) statt make?
• Waf (Python) im Sourcetree?

Schlussfolgerung