AK's weblog

Ich bin kein Berliner. So heißt das neue Buch von Wladimir Kaminer, das ich heute zufällig entdeckt und gekauft habe, und das übrigens im April 2007 erscheint. Meine Vermutung ist ja, dass da das limitierte Vorab-Exemplar versehentlich ins Regal gerutscht ist. Ansonsten hab ich mir noch ein paar Reiseführer gekauft, einen über Amsterdam und zwei über Argentinien, und dann noch ein paar fehlende Ingredienzen für die große Hamburger-Braterei heute abend.

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.

Manchmal könnte man die GNU-Leute so richtig schön verprügeln. Weil die linke Hand nicht weiß, was die rechte tut. Konkret ärgere ich mich derzeit wegen iconv(), der SuSv3-standardisierten Funktion zum Konvertieren zwischen verschiedenen Zeichensätzen, bzw. der Signatur ebendieser.

SuSv3 schreibt vor:

die glibc hat:
die dietlibc hat:
GNU libiconv hat (wenn das System keine iconv-Implementierung hat):
und NetBSD hat diesen Bloedsinn gleich nachgemacht:
Wer immer auf diese hirnrissige Idee gekommen ist, gehört einmal ordentlich verprügelt. Standards aren't there for no reason. Und falls sich jemand denkt, "ach, das macht doch nichts, char ** ist sowieso auf const char ** zuweisungskompatibel", der hat sich geschnitten. Noch dazu bin ich völlig unmotiviert, für kaputte Systeme Workarounds zu basteln. Oder anders ausgedrückt: glibc und dietlibc gut, GNU libiconv und *BSD böse.

Soweit ich übrigens rausfinden konnte, liefern FreeBSD und OpenBSD keine eigene iconv-Implementierung mit, sondern es gibt lediglich die GNU libiconv in den Ports. Was ich übrigens nicht verstehen kann, eine rudimentäre iconv-Implementierung, die UTF-8, UTF-16[bl]e, ISO-8859-x, und die gängigsten Codepages unterstützt, ist in einer Woche gebastelt. Nur halt nicht von mir.

Update: ich hab den Grund für die Diskrepanzen gefunden. Und zwar ist das const in der SuSv2-Definition drinnen, in der SuSv3-Definition jedoch nicht mehr. *gna*

Um 7 Uhr hat der Wecker geklingelt, ich drehe mich im Bett um, und der erste Gedanke, der mir durch den Kopf geht: "Ich habe in der CXyzFile-Klasse ein Memory Leak beim Anlegen von CFooIterator-Objekten". Was dann auch gestimmt hat, und das erste, was ich heute in der Arbeit gefixt habe. Sehr schräg.

Sonntag hab ich mich spontan entschlossen, mit einem Freund übers Osterwochenende nach Amsterdam zu fliegen. Lange haben wir gehadert, um einen passenden Flug zu kriegen (Sky Europe hat irgendwann Montag vormittag die Preise für Wien-Schwechat - Amsterdam-Schiphol drastisch erhöht, und auch die AUA hat am Montag abend die Preise für die Strecke während des Buchens geändert), und lange haben gezittert, um überhaupt eine angemessene Schlafgelegenheit zu finden (so spontan über Ostern nach Amsterdam zu fahren war buchungstechnisch keine gute Idee), aber letzten Endes hat's dann doch geklappt, und wir haben ein Appartment zu einem fairen Prais in der Grachtengordel ergattert. Der AK freut sich, dass die Umsetzung einer spontanen Idee so gut geklappt hat, und ist auf Amsterdam gespannt. In die Niederlande hab ich's bisher ja noch nie geschafft, und gemeinsam mit der 3-wöchigen Reise nach Argentinien im Juni/Juli wird 2007 wohl das Jahr des Reisens werden.

Heute hab ich wieder einiges an Arbeit investiert, um newsbeuter (besser) zu internationalisieren. Und das ist dabei herausgekommen:

Von oben nach unten: Japanisch, Chinesisch, Arabisch und Hebräisch.

Gestern haben Ska Bucks im Planet Music in Wien am Viertelfinale des Austrian Band Contest teilgenommen. Nachdem die Band einen Bus organisiert hat, war ich dabei, und habe ein paar Eindrücke des Auftritts gesammelt. Leider sind sie nur 7. von 9 Bands geworden, allerdings waren einige Bedingungen, unter denen der Auftritt erfolgte, eher nicht so toll.











Einen Videomitschnitt von einem Song hab ich ebenfalls gemacht, sobald der bei Youtube online ist, werde ich ihn entsprechend verlinken.

Update: hier das Video des Songs "Fast Way":

Heute geht's mit ein paar Arbeitskollegen, nämlich Hilli, Udo und Jeid, ins City-Kino, auf zwei in Zusammenhang stehende Filme hintereinander (neudeutsch heisst das wohl "Double Feature"), und zwar einerseits Letters from Iwo Jima, andererseits Flags of Our Fathers, beides Filme von Clint Eastwood, die von der Schlacht um Iwojima im 2. Weltkrieg handeln. Nachdem ich ja schon länger nicht mehr im Kino war, weil länger nix mehr war, das mich auch nur annähernd interessiert hätte, bin ich schon ziemlich gespannt darauf.