 "Aufmacher Artikel")
Ein großer Vorteil freier Software liegt darin, dass jeder die Möglichkeit zum Studium des Programmcodes hat und ihn an eigene Bedürfnisse anpassen kann. Damit sich nun aber nicht jeder, der eine freie Software installieren möchte, zwangsläufig mit den Programmquellen auseinandersetzen muss, gibt es Tools, die dem Benutzer die Anpassungsarbeit an das eigene System abnehmen.
Das Einmaleins der Installation
Software, die unter die GNU General Public Licence oder eine andere Open-Source-Lizenz fällt, wird meist in Form mehr oder weniger großer "gezippter" tar-Archive bereit gestellt. Wer ein solches Paket installieren möchte, muss es zunächst auf der eigenen Festplatte entpacken.
Als Beispiel soll hier das GIMP-Toolkit gtk+-1.2.2.tar.gz dienen:
gunzip gtk+-1.2.2.tar.gz tar xf gtk+-1.2.2.tar
Diese zwei Schritte – der erste dekomprimiert die tar.gz-Datei zu einem reinen tar-Archiv, der zweite entpackt das dadurch erzeugte File – lassen sich mit der unter Linux gebräuchlichen tar-Version auch zu einem zusammenfassen:
tar xzf gtk+-1.2.2.tar.gz
Dabei erhält man ein Verzeichnis mit dem Namen gtk+-1.2.2, in dem sich die einzelnen Dateien und Unterverzeichnisse des Pakets befinden. Nachdem man in das soeben erzeugte Verzeichnis gewechselt ist, kann man mit der eigentlichen Arbeit beginnen.
Zunächst startet man das configure-Skript:
./configure
Dadurch passt der Anwender die Software – oder vielmehr die zur Übersetzung benötigten Makefiles – automatisch an das eigene System an. Wie ein solches configure-Skript entsteht, sehen wir etwas später.
Trat ein Fehler auf, kann dies zum Beispiel an einer Library liegen, die für die Programmgenerierung benötigt wird, jedoch nicht oder in einer veralteten Version installiert ist. Diese muss dann zunächst eingespielt werden. Wenn die Konfiguration ohne Fehlermeldung ablief, kann mit dem Kompilieren der Programmquellen begonnen werden. Nach Eingabe von
make
wird der Quellcode übersetzt. Bei großen Programmpaketen, wie dem hier als Beispiel angeführten gtk+-1.2.2, ist spätestens jetzt die Zeit für eine Teepause gekommen. Das Kompilieren dieses Pakets dauert auf einem Pentium 266 beispielsweise ganze 13 Minuten.
Ging beim Kompilieren alles glatt, müssen die neu erzeugten Dateien an die "richtige" Stelle kopiert werden. Für ausführbare Binärdateien kann dies zum Beispiel das Verzeichnis /usr/local/bin sein. Man verschafft sich also root-Rechte und startet den Kopiervorgang:
su make install
Jetzt sollte jeder "normale" User das neu installierte Programm durch Eingabe des entsprechenden Namens starten können. Da es sich bei unserem Beispiel um eine Library handelt, können wir allerdings gar nichts ausführen.
Möchte man ein neues Paket auf einem Rechner installieren, auf dem man selbst keine root-Rechte besitzt, entfällt natürlich der letzte Schritt, und man muss das Programm direkt aus dem entsprechenden Unterverzeichnis heraus aufrufen (oder z.B. einen symbolischen Link setzen). Der Kasten "Installationsdreiklang" fasst alle Schritte noch einmal kurz zusammen.
Installationsdreiklang
Konfiguration:
./configure
Übersetzung:
make
Für systemweite Installationen als root:
su make install
Jetzt wissen wir also, wie man als Anwender einen Sourcecode übersetzt und zum "Laufen" bringt. Was aber ist alles nötig, um solch ein Paket zu erstellen?
Wo soll das nochmal enden?
Damit die Installation wirklich so reibungslos wie oben beschrieben funktioniert, müssen verständlicherweise einige Konventionen beim Erstellen der Quellpakete beachtet werden. Jede GNU-Software wird deshalb (normalerweise) in einer festgelegten Verzeichnisstruktur abgelegt und mit ein paar Standarddateien versehen. Auch wenn man sein Programm unter einer anderen Lizenz freigeben will, bietet sich eine entsprechende Strukturierung an. Tabelle 1 zeigt, wie diese aussehen sollte. Die angegebenen Verzeichnisse befinden sich alle unterhalb des eigentlichen Projektverzeichnisses. Es müssen keineswegs immer sämtliche Directories verwendet werden – einige sind optional.
Tabelle 1: Verzeichnisstruktur eines (GNU-)Programmpakets
| src | Hier liegt der eigentliche zu kompilierende Sourcecode. Bei komplexen Programmen können und sollten auch weitere Unterverzeichnisse eingerichtet werden. |
| lib | In diesem Verzeichnis befinden sich Sourcen oder Tools, die für die Portierung des Programms notwendig sind, beispielsweise Implementierungen von Systemaufrufen, die nicht auf jedem System zur Verfügung stehen. |
| doc | Keine gute Software ohne gute Dokumentation. Deshalb wird hier alles, was das Programmpaket beschreibt, zusammen gefasst. Wie die Dokumentation aussieht, bleibt jedem selbst überlassen. Bei GPL-Software sollte aber bevorzugt Texinfo [5] eingesetzt werden. |
| m4 | Hier liegen neue m4-Makros. Näheres zu Makros erfahren Sie aus der autoconf-Dokumentation [2]. |
| po | In diesem Verzeichnis sollten die in verschiedene (natürliche) Sprachen (Deutsch, Englisch, Japanisch usw.) übersetzten Textmeldungen liegen. |
| intl | Hier wird Quellcode für die Internationalisierung des Programmpakets abgelegt. |
Bei den in Tabelle 2 aufgeführten Dateien handelt es sich um allgemeine Dokumentation, die auf jeden Fall im Projektverzeichnis vorhanden sein muss. Für jede dieser Dateien ein Beispiel abzudrucken würde an dieser Stelle jedoch den Platz sprengen. Aber da sie in den verschiedenen GNU-Software-Paketen ohnehin enthalten sind, werfen Sie doch einfach bei Ihrer nächsten Kompilieraktion einen Blick darauf!
Tabelle 2: Dokumentationsdateien
| README | Diese Datei sollte jeder, der das Paket installieren möchte, als Allererstes lesen. Hierin wird das vorliegende Programm kurz beschrieben. Außerdem enthält sie ggf. Verweise auf andere Dokumentationsdateien. |
| INSTALL | Die INSTALL-Datei wird automatisch von automake erzeugt. Sie richtet sich vor allem an Diejenigen, die noch nie eine GNU-Software installiert haben. Wenn man als Programmautor etwas Außergewöhnliches mitzuteilen hat, sollte man dies deshalb besser in der README-Datei tun. |
| AUTHORS | Diese Datei enthält die Namen aller Autoren, die am vorliegenden Programmpaket mitgearbeitet haben. Außerdem sollte erkennbar sein, von wem welche Programmteile stammen und ob diese vom Autor erstellt oder nur modifiziert wurden. |
| THANKS | Die "Danksagungsdatei" besteht normalerweise aus einer zweispaltigen Liste aller am Projekt beteiligten Personen: links der Name, rechts die E-Mail-Adresse. Am einfachsten sortiert man sie alphabetisch, ohne eine Gewichtung bestimmter Mitarbeiter vorzunehmen. |
| NEWS | Die wichtigsten neuen Eigenschaften des Programmpakets. Alte Auflistungen sollten nicht gelöscht werden, damit man die Neuerungen zwischen beliebigen Programmversionen jederzeit nachvollziehen kann. |
| ChangeLog | Hier werden alle Veränderungen am Sourcecode dokumentiert. Wie so etwas im Detail aussieht, schaut man sich am besten an einer Beispieldatei an. Für jeden "Arbeitstag" sollte es eine kleine Gruppe von Änderungsnotizen geben. |
| COPYING | COPYING enthält die "General Public License". Diese muss aber nicht etwa selbst abgetippt werden, sondern wird von automake automatisch erstellt. |
Abbildung 1 zeigt ein Sourcecode-Paket mit einigen der eben beschriebenen Verzeichnisse und Dateien.
Abbildung 1: Eine typische Datei- und Verzeichnisstruktur
Einem Freund empfehlen
