AK's weblog

Ein paar Alternativen zum derzeitigen make-basierten Buildsystem bei newsbeuter evaluiert. SCons und CMake. Frustriert wieder aufgegeben, weil sich die Anforderungen, die ich habe, entweder mit viel Fummelei oder gleich gar nicht umsetzbar sind. Mit SCons hab ich durch etwas umstrukturieren (gemeinsam genutzte Objekte musste ich in eine statische Lib zusammenfassen, sonst will SCons da garnichts compilieren) den Buildprozess so hingebracht, wie ich wollte, und CMake... naja, sagen wir mal so, man merkt an der Qualitaet der CMake-Dokumentation, dass es auch ein CMake-Buch gibt.

Was sind überhaupt meine Anforderungen? Es sollen zwei Binaries erzeugt werden, aus C++-Sourcecode, wobei sich beide Binaries eine gewisse Anzahl von C++-Sourcefiles teilen. Zusaetzlich gibt es noch regulaere Header-Files sowie .stfl-Files, die durch ein Perl-Preprocessor-Script in Header-Files umgewandelt werden. Die Umsetzung als Makefile ist halbwegs kompakt, und noch gut wartbar.

Wie schon oben beschrieben, der vielversprechendste Kandidat schien SCons zu sein, bis ich mir dann genauer angeschaut habe, wie man die Installation von Dateien umsetzen soll. Das ist, mit Verlaub, der hirnrissigste Schwachsinn, den ich jemals gesehen habe. Die SCons-Leute haben eindeutig die falschen Drogen konsumiert, wie sie das designed haben. Nein, das will ich nicht benutzen.

Warum tu ich mir das ueberhaupt an? Weil ich vor dem eigentlichen Compile auch ein paar Details ueber die Zielplattform rausfinden will (und zwar mehr als nur triviales "ist Header foobar.h vorhanden" und "ist Library libquux eh da"), und mit reinen Makefiles ist das ein einziger PITA. Tja, mit autoconf waeren meine Anforderungen hinreichend gut umsetzbar, weil das Makefile ohne viel Aufwand portierbar waere, aber das will ich mir selbst nicht antun. autoconf ist zwar gut customizable, aber ein einziger Haufen Dreck, vor allem weil es dann zu Zustaenden wie den folgenden fuehren wuerde:
-rwxr-xr-x 1 ak ak 43K 2007-04-02 13:03 config.guess
-rwxr-xr-x 1 ak ak 15K 2007-04-02 13:03 config.rpath
-rwxr-xr-x 1 ak ak 28K 2007-04-02 13:06 config.status
-rwxr-xr-x 1 ak ak 31K 2007-04-02 13:02 config.sub
-rwxr-xr-x 1 ak ak 156K 2007-04-02 13:05 configure
-rwxr-xr-x 1 ak ak 9.1K 2007-04-02 12:43 install-sh
Ja, richtig gesehen, das sind knapp 280 kB Skripte, die da zusaetzlich mitgeshipped werden wuerden, fuer ein paar simple Tests.

Und eines kann ich auch ausschließen: ich werde sicher kein zusaetzliches Build-Tool entwickeln, das kann nur in die Hose gehen. Tja, alles scheisse eben.

Nachdem das Ranten über GNU so schön ist, hier noch ein kleiner Nachschlag. Wieder fast jeder, der schon mal Software unter Linux selbst compiled hat, weiß, muss man vor dem Übersetzen meist noch ./configure aufrufen, welches dann ein paar systemspezifische Konfigurationsinformationen sammelt und ein Makefile generiert.

Zum Erstellen dieses configure-Skripts gibt es ein Tool namens autoconf. Dieses generiert aus einem configure.in bzw. configure.ac File das configure-Skript. Das configure.ac wiederum kann man sich aus dem bestehenden Sourcetree generieren lassen und dann händisch anpassen. Das Makefile, das man dann zum Compilieren benötigt, wird übrigens vom configure-Skript i.A. aus dem Makefile.in erzeugt, wobei hierbei Platzhalter durch die entsprechenden ermittelten bzw. gesetzten Werte (./configure lässt sich ja relativ gut durch Commandline-Switches steuern) ersetzt werde. Makefile.in's schreiben sich ähnlich wie Makefiles. Und weil das Schreiben von Makefile.in's sooo schwer ist, gibt es auch gleich noch ein weiteres Tool, automake, mit dem man sich das Makefile.in aus einem Makefile.am erzeugen lassen kann.

Durch einen jahrelangen Reifungsprozess sind autoconf und automake schon so gut integriert, dass sie fast eine Symbiose bilden. Diese Symbiose ist so gut, dass es vom GNU-Projekt keine Dokumentation gibt, wie man autoconf ohne automake verwendet. Das heisst, jeder enthusiastische Programmierer, der auf die Vorteile von autoconf zurückgreifen will, und sich das selbst anhand der Doku aneignet, wird auch automake verwenden. Am Ende der Integration von autoconf und automake ins eigene Sourcepaket bleiben dann ein ca. 200 kB grosses configure-Skript und ein 50 kB grosses Makefile.in übrig, sowie noch 50 - 100 kB andere Dateien wie z.B. diverse Helper-Shellskripte. Das ist natürlich sehr toll, wenn das eigene, selbstgeschriebene Tool aus vielleicht 15 kB Sourcen besteht.

Aber trotzdem gibt es Mittel und Wege, um ohne automake auszukommen, was die Gesamtgröße der generierten Dateien um einiges herabsetzt. Wie das im Detail geht, wäre jetzt zuviel des guten, jedoch nur ein kurzer Tipp: wer Makefiles schreiben kann, und /usr/local durch _prefix und gcc durch _CC ersetzen kann, der kann Makefile.in's schreiben, und braucht kein automake.

Hier noch mal die Erklärung: autoconf sorgt für das configure-Skript, das Systemkonfiguration sammelt und das Makefile erzeugt, und automake sorgt für das Makefile.in-Template, sodass der Programmierer sich um weniger Makefile-Details kümmern muss (muhahahaha). Eigentlich eine gute Trennung. Theoretisch. Wie sieht es praktisch aus? Nun, das Dokumentationsproblem habe ich schon erwähnt, aber etwas wesentlich perfideres hab ich heute wieder mal entdecken müssen: autoconf ist ja m4-basiert, und bringt einige fertige m4-Makros zum Testen auf bestimmte Konfigurationen mit. Allerdings gibt es noch wesentlich mehr Makros. Zum Beispiel bei automake. Bei automake sind wirklich jede Menge m4-Makros dabei, die wesentlich mehr können, und die einfach eingebunden werden können. Welche Möglichkeiten hat Joe Average Programmer hier? Entweder er kopiert die m4-Makros aus dem automake-Paket in seinen eigenen Sourcetree, oder aber integriert einfach automake in sein eigenes Buildsystem.

Warum GNU diese Makros nicht zu autoconf dazugepackt hat? Nun, das weiß nur Gott ("Gott? welcher Gott?"). Auf jeden Fall haben diese Beobachtungen bei mir den schalen Nachgeschmack hinterlassen, GNU will möglichst viele Programmierer mit autoconf und automake "zwangsbeglücken". Mittlerweile ist es ja fast nicht mehr möglich, ohne das Konfigurieren des Sourcetrees auf Systemeigenheiten noch portable Programme zu schreiben, die "out of the box" unter einem Allerwelts-Unix wie Linux, *BSD und Solaris compilieren und linken. GNU hat sicherlich seines dazu beigetragen, und bringt gleichzeitig ein "Wundermittel" mit, das halt zu 300 kB Scheisse in jedem Sourcepaket führt. Leider sind autoconf und automake als de-facto-Standard etabliert, andere Buildsysteme dagegen finden kaum Beachtung oder Einsatz.