Programmierer kennen das Problem mit der Wartezeit beim Kompilieren nur zu gut: Sie ist zu kurz für eine andere Tätigkeit und dauert zu lange, um sie zu ignorieren. Dieser Artikel stellt ein Verfahren vor, das die Kompilierzeiten drastisch reduziert.

Noch mehr Vor-, aber auch ein Nachteil

Während der Entwicklungsphase eines Programms wird öfter zwischen -O2 (optimierter Code) und -g (debuggbarer Code) umgeschaltet. Jedes Mal sind ein make clean- und ein erneuter make-Lauf mit den geänderten Optionen notwendig. Das ist ärgerlich, denn der Computer hat die Dinge früher schon mit denselben Optionen kompiliert. Compilercache dagegen holt die Files aus dem Cache statt sie neu zu übersetzen.

Wer ein Projekt von Anfang an entwickelt, beginnt oft mit einem einfachen Shellskript, das die Compileraufrufe durchführt. Mit wachsender Größe des Programms ist die Wartezeit für eine komplette Neukompilierung kaum mehr erträglich. Der gängige Weg führt normalerweise über das komplexe Automake. Makefiles sind fehleranfällig, was tagelanges Debuggen von Dateien nach sich ziehen kann, die nur aufgrund falscher Abhängigkeiten existieren. Mit Compilercache kann man noch lange beim einfachen Shellskripts bleiben.

Der Maintainer eines RPM-Pakets berichtete, dass beim Bauen eines Pakets der Quellcode mehrfach kompiliert werden muss, falls etwas schief gegangen ist. Bei entsprechender Größe der Quellen (in seinem Fall Mozilla) ist das ein schwer wiegendes Problem, das durch den Compilercache lösbar ist.

Fragt sich, wodurch die Vorteile des Cache erkauft werden. Die Antwort: durch Plattenplatz. Der jedoch ist im Gegensatz zur eingesparten Zeit käuflich und außerdem erzeugt der Cache nicht viele Daten. Wenn es dennoch einmal zu viele werden, kann man einfach die ältesten löschen. Das README-File nennt Details.

Eines der wichtigen Designkriterien beim Entwickeln von Compilercache war die Forderung, dass er keinen Schaden anrichten darf. Er muss sich unter allen Umständen genau so verhalten wie der wirkliche Compiler. Lediglich das Zeitverhalten darf anders sein.

Weg durch den Dschungel

Zunächst überprüft der Compilercache, ob eine -c-Option auf der Kommandozeile angegeben wurde. Falls der Compiler stattdessen beispielsweise als Linker aufgerufen wird, dann leitet der Cache direkt an den Compiler weiter.

Nun wird der Sourcecode zuerst durch den C-Präprozessor geschickt. Hierbei werden alle Makros ausgewertet, Kommentare entfernt und vor allem sämtliche Includefiles eingelesen. Als Ergebnis kommt ein einzelnes C-Sourcefile heraus. Das wird in seine lexikalischen Tokens zerlegt und jedes davon wird auf eine einzelne Zeile geschrieben. Das entstehende Sourcefile sieht immer gleich aus, egal wie viele Leerzeichen, Kommentare, unbenutzte Makros oder ähnliches Sie in Ihrem Quellcode eingebaut haben.

An diese Sourcedatei werden noch die Version des Compilers und die verwendeten (und relevanten) Kommandozeilenoptionen sowie der Name der Quelldatei angehängt. Dann ist die Berechnung des Hashwerts dieser Datei mit Hilfe von Md5sum an der Reihe. Der Hashwert ist der Dateiname des entstehenden Objektfiles im Cache-Verzeichnis. Ist also eine solche Datei bereits vorhanden, wird sie kopiert. Andernfalls ruft Compilercache den Compiler auf und kopiert das Ergebnis zusätzlich noch in den Cache.

Programmierer kennen das Problem mit der Wartezeit beim Kompilieren nur zu gut: Sie ist zu kurz für eine andere Tätigkeit und dauert zu lange, um sie zu ignorieren. Dieser Artikel stellt ein Verfahren vor, das die Kompilierzeiten drastisch reduziert.