AK's weblog

Beim Versuch, SQLite3 ohne Tcl-Support unter Cygwin mit --without-tcl statt mit --disable-tcl (beide ./configure-Optionen sind verfügbar...) zu bauen:

checking for Tcl configuration... configure: error: no directory doesn't contain tclConfig.sh

So, es ist offiziell: meine eingerichten Vorträge zu newsbeuter wurden sowohl auf den Grazer Linuxtagen als auch auf den Linuxwochen Wien genommen. Es erwartet jeden Besucher eine Einführung in newsbeuter, eine Feature Show, die zeigt, wie mächtig newsbeuter wirklich ist, und dann noch ein Blick "hinter die Kulissen", wie newsbeuter intern funktioniert, und welche Lehren ich aus der bisherigen Entwicklung gezogen habe. In spätestens einer Woche wird übrigens die Version 0.4 released werden, die einige tolle neue Features am Start hat.

• Vortrag in Graz, 19. Mai 2007, 17:00 - 18:00
• Vortrag in Wien, 2. Juni 2007, 09:00 - 09:45

Wieder mal ein wirklich lustiges Wochenende... mit den Ska Bucks nach Neusserling gefahren, und dort eine nette Zeit auf dem Noppen Air verbracht, jede Menge Fotos geschossen, und auch wieder das eine oder Video gemacht, und alle Annehmlichkeiten, die so ein Backstage-Ausweis mit sich bringt, ordentlich ausgekostet. Das Noppen Air ist einfach noch ein sympathisches kleines Festival, wo genug aber nicht zuviel los ist, wo alle Leute ziemlich gemuetlich drauf sind und wo man mit Backstage-Ausweis wie ein Koenig behandelt wird. Nach mehr als 9 Stunden Festival, geschaetzen 7 Bieren und 4 Caipirinhas haben wir dann wieder die Heimreise angetreten. Und naechstes Wochenende geht's schon wieder wo hin, dann auf's "Halabaluza" nach Markersdorf/St. Pölten.

Cooler Song, lustiges Video:

Unverhofft zu viel Geld kommen, das ist der Traum von wohl jedem Menschen. Bei mir war das gestern so: auf einmal hatte ich einen Brief des Finanzamts im Postkasten, in dem mir in einer kompllizierten Aufstellung mitgeteilt wurde, dass mir das Finanzamt im Zuge der Einkommenssteuererklärung für 2006 einen grossen Betrag, etwa 137 % meines derzeitigen Nettomonatsgehalts, ueberwiesen hat. Zuerst konnte ich es ueberhaupt nicht fassen, und hab mich deswegen noch beim Finanzamt erkundigt, ob das auch wirklich stimmt. Aber die haben das durchgerechnet, und offenbar bin ich durch den Umstand, dass ich 2006 nur 6 Monate gearbeitet habe (Bundesheer und so...), unter eine gewisse Einkommensgrenze gefallen, unter der ich ziemlich wenig Steuern zahle. Das ist natuerlich aeusserst erfreulich. Und da der Betrag in etwa dem entspricht, was ich vorhatte, fuer meinen Argentinienurlaub im Juni/Juli auszugeben, kann ich (stark vereinfachend) sagen, dass das Finanzamt meinen Argentinienurlaub finanziert. Das stimmt natuerlich nicht, weil das ja Geld ist, das ich durch meine harte Arbeit verdient habe, aber der Umstand, dass ich nicht damit gerechnet habe, dass der Staat Oesterreich es mir eventuell wieder zurueckueberweisen wuerde, macht es (zumindest psychologisch) zu einem unerwarteten, aeusserst erfreulichen Geschenk.

Gestern hab ich im Posthof auf dem "Connected"-Schulfest für die Ska Bucks fotografiert und ein wenig gefilmt, und weil's gleich in einem ging, auch gleich noch ein paar Bilder von The Smiling Sunrise Band gemacht.







Hier geht's zu allen Fotos von Ska Bucks





Hier geht's zu allen Fotos von The Smiling Sunrise Band

Ausserdem hier zwei Videos, die ich aufgenommen habe:

Der Standard stellt folgende Frage: Wie gefährlich sind Zecken wirklich? Aeusserst lesenswert. Michel Reimon hat mal der "Zeckenimpfung" (also der Impfung zum Schutz vor FSME) nachrecherchiert und ist auf bemerkenswerte Geflechte von Pharmafirmen, Aerzten, Apothekern und Selbsthilfegruppen gestossen, in deren (finanziellem) Interesse es liegt, dass moeglichst viele Österreicher sich Zeckenimpfen lassen, und diese Immunisierung möglichst oft auffrischen lassen.

Eine Sache, die mich ja schon immer gewurmt hat, ist ja der Umstand, dass bei einer FSME-Auffrischung keine Titerbestimmung durchgeführt wird, d.h. es wird - im Gegensatz zu z.B. Hepatitis - nicht nachgeschaut, ob nicht noch genug Antikörper vorhanden sind, sodass die Immunisierung noch weitere 10 Jahre reichen würde. Die Begründung, die ich bisher dazu gefunden habe, war, dass die Wirkstoff-Verträglichkeit so gut wäre und allgemein das Impfen als eine genauere Untersuchung wäre, frei nach dem Motto "lieber eine zuviel als zuwenig". Im Kontext des Artikels macht dieser Umstand natürlich mehr Sinn, nämlich dass es im Interesse ebendieses Geflechts liegt, dass keine Titerbestimmungen durchgeführt werden, weil einfach mehr Kohle durch Impfungen als durch Titerbestimmungen zu machen ist.

Für die Österreicher in meiner Leserschaft interessant ist wohl auch, dass es neben Österreich kein Land gibt, bei dem die FSME-Durchimpfrate auch nur annährend so hoch ist. In Deutschland etwa wird die FSME-Impfung nur in Epidemie-Gebieten für Hochrisiko-Gruppen (also z.B. Forstarbeiter) empfohlen.

Aufgenommen irgendwo am Grachtengürtel auf dem Weg vom Dam zum Filmmuseum.

So, wieder zurück aus Amsterdam. Ein paar Impressionen: Aufstehen um 4:30 ist einfacher, als man denkt. Der Venusgürtel als Hintergrund zu den OMV-Werken auf dem Weg nach Wien-Schwechat sieht spannend aus. Auf demselbigen Flughafen ist um 6 Uhr früh wesentlich mehr los, als man denkt. Sich nicht einfach beim Checkin anzustellen, sondern eine Infodame zu fragen, wo man sich am besten anstellen soll, kann ziemlich viel Zeit ersparen. Anscheinend gibt es auf AUA-Flügen erst ab einer gewissen Flugdauer was zu essen (Wien-Berlin: nein; Wien-Asterdam: ja). Amsterdam-Schiphol ist so riesig, dass die Flugzeuge von Landebahn zur Parkposition sogar über eine Autobahnbrücke rollen müssen (also eine Brücke über eine Autobahn, keine ins Autobahnsystem integrierte Brücke). Für die Strecke Schiphol - Amsterdam Centraal Station zahlt es sich nicht aus, ein 1.-Klasse-Ticket zu kaufen, weil man sowieso nicht kontrolliert wird. Die Innenstadt ist nur scheinbar kompakt, alle Wegstrecken, die uns südlich des Dam geführt haben (gewohnt haben wir am nördlichen Ende der Singelgracht), waren irgendwie zu lang. Das Bier war schrecklich, sowohl vom Geschmack her (Spülwasser würde besser schmecken), als auch vom Preis her (EUR 4,- für 0,5 l Heineken gilt als Okkasion). Die Fahradfahrer sind gemeinfährlich, ich wurde fast von einem niedergefahren, weil er partout weder klingeln noch anhalten wollte (man entwickelt nach kurzer Zeit eine gewisse, moeglicherweise durchaus gesunde Paranoia vor Fahradfahrern). Nicht alles, was an Restaurants in erstklassigen Reiseführern empfohlen wird, ist auch nur annähernd so gut wie beschrieben. Das "Filmmuseum" ist keines. Und last but not least: wer im Burgerking auf dem Flughafen gratis essen will, der sollte zielstrebig und mit suchendem Blick an der Kassiererin vorbei gehen (bei Richard hat's - zumindest ungewollt - geklappt). Das ist allerdings nicht empfohlen, will man sein köstliches Flugzeug-Menü genießen.

So, das war's für erste. Strukturiertere Reiseberichte später.

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.

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*