Make und Autoconf: Das GNU-Buildsystem

Wichtigster Kritikpunkt an Make ist aber, dass sich damit keine portablen, über mehrere Betriebssysteme hinweg gültigen Builddefinitionen schreiben lassen. Zu unterschiedlich sind Konventionen, Pfade, Shells, Compiler und so weiter auf den verschiedenen Plattformen. Hier kommen die Buildsysteme ins Spiel. Sie erzeugen aus abstrakteren Definitionen Plattform- und Tool-spezifische Makefiles. Bekanntestes Beispiel ist das GNU-Buildsystem (GBS) mit den Tools Autoconf und Automake.

Es gibt kaum einen Linux-Anwender, der nicht früher oder später den klassischen Dreischritt »configure; make; make install« aufruft. Er erzeugt dabei mit Autoconf das von ihm dann mit dem Quellcode ausgelieferte Configureskript. Dieses wiederum überprüft die Plattform des Anwenders und erzeugt daraus die eigentlichen Makefiles.

Das GBS ist fast omnipräsent, aber wichtige Projekte haben sich davon abgewandt. So verwendet das KDE-Projekt inzwischen Cmake [1]. Dafür gibt es mehrere Gründe. Ein Problem von Autoconf ist es, dass es die plattformspezifischen Prüfungen über so genannte M4-Makros definiert. M4 ist ein leistungsstarker, aber altertümlicher Textprozessor mit einer schwierigen Low-Level-Syntax. Damit ist einerseits die Einstiegshürde groß, andererseits die Pflege aufwändig.

Ein weiterer Kritikpunkt am GBS liegt im Mechanismus selbst begründet. Das Configureskript untersucht die aktuelle Plattform und baut dafür ein passendes Makefile. Cross-Compilation, für Embedded Devices eine Standardanforderung, ist damit prinzipbedingt schwierig bis unmöglich.

Zu guter Letzt unterstützt das GBS (verständlicherweise) nur GNU-Make als Buildtool. Cmake dagegen kann aus seinen Definitionen heraus Make-Beschreibungen für verschiedenste Tools erstellen. Die Liste ist lang, es unterstützt unter anderem Borland und Watcom Make sowie Microsofts Nmake. Neben Makefiles erzeugt Cmake auch noch Projektdateien für Eclipse CDT, Microsoft Visual Studio und Kdevelop.

Eine weitere Alternative zum GBS ist Trolltechs Qmake [2]. Doch die Namen täuschen, Cmake und Qmake sind keine Make-Alternativen, sondern beide Makefile-Generatoren.

Das Bessere ist des Guten Feind

Natürlich gibt es nicht nur Kritik an Make, sondern auch Anstrengungen, es durch eine bessere Alternative zu ersetzen. Abbildung 2 zeigt die Einträge im Softwareverzeichnis der Free Software Foundation [3]. Die Liste ist aber nicht vollständig, [4] hat noch weitere Links, und auch die Suche über die Softwarekategorien bei Sourceforge findet viele weitere Treffer.

Abbildung 2: Im Softwareverzeichnis der Free Software Foundation finden sich zahlreiche Make-Alternativen.

Bei der großen Auswahl sollte jeder etwas nach seinem Geschmack finden. Neben dem populären Ant (siehe weiter unten) sei insbesondere auf Scons [5] verwiesen. Scons ist in Python implementiert und verwendet Python-Syntax für die Formulierung der Buildregeln. Sein Vorgänger ist Cons [6], dessen Regeln an Perl angelehnt sind. Scons gilt als leistungsstark und einfach erweiterbar, aber auch als langsam.

Bei allen Alternativen muss der Entwickler aber beachten, dass ein einfacheres Buildtool als Make die Arbeit für ihn selbst erleichtern mag, aber für die Nutzer seiner Software eine Einstiegshürde aufstellt. Wer erst ein esoterisches Maketool herunterladen und bauen muss, um damit die eigentliche Software zusammenzustellen, greift dann doch eher zu einer alternativen Software. Unabhängig von dieser Erwägung haben sich in speziellen Ökosystemen eigene Buildtool-Standards durchgesetzt. Prominentestes Beispiel dafür ist Java.