Softwareentwicklung und Versionskontrolle unter Linux
Haben Sie schon einmal gehört, dass Sie „ein Repo klonen und bauen“ sollen, aber waren unsicher, was das bedeutet? Keine Sorge, wir führen Sie durch den Prozess, wie Sie ein solches Programm unter Linux über GitHub zum Laufen bringen, auch wenn Sie noch wenig Erfahrung haben.
Computerprogramme bestehen aus Anweisungen, die in Textdateien geschrieben und gespeichert werden. Ein sogenannter Compiler übersetzt diese Dateien in eine ausführbare Version. Diese Textdateien mit den Anweisungen werden als Quellcode bezeichnet. Die lauffähige Version eines Programms nennt man Binärdatei oder Executable.
Das ist natürlich eine vereinfachte Darstellung, aber sie gibt einen guten Überblick. In der Praxis gibt es oft Abweichungen von diesem Muster. Manchmal werden die Textdateien von anderen Programmen erstellt, oder der Quellcode wird direkt durch einen Interpreter ausgeführt, ohne vorher kompiliert werden zu müssen.
Eines gilt jedoch für alle Softwareprojekte: Der Quellcode ist das wertvollste Gut und muss entsprechend sorgfältig behandelt werden.
Versionskontrollsysteme
Der gesamte Quellcode eines Projekts wird als Codebasis bezeichnet. In größeren Projekten arbeiten oft mehrere Entwickler gleichzeitig an der Codebasis. Jede Änderung am Code muss nachvollziehbar sein und bei Bedarf rückgängig gemacht werden können. Wenn mehrere Entwickler an derselben Datei arbeiten, müssen ihre Änderungen zusammengeführt werden.
Daher gibt es spezielle Programme, sogenannte Versionskontrollsysteme, die das Management von Änderungen an der Codebasis erleichtern. Sie speichern alle früheren Versionen jeder Datei und protokollieren jede Änderung mit Kommentaren.
Git: Ein wichtiger Akteur
Linus Torvalds, der Erfinder des Linux-Kernels, hat das Versionskontrollsystem Git entwickelt, um die Entwicklung des Linux-Kernels zu verwalten. Heute ist Git die weltweit am meisten genutzte Versionskontrollsoftware. Millionen von Menschen arbeiten täglich damit.
In Git wird die Codebasis eines Projekts in sogenannten Repositories (kurz: Repos) gespeichert. Neben lokalen Repositories auf den Rechnern der Entwickler und eventuell einem zentralen Server im Netzwerk, empfiehlt es sich auch, ein externes oder Remote-Repository zu nutzen.
Und hier kommt GitHub ins Spiel.
GitHub
GitHub entstand aufgrund des Erfolgs von Git. Die Gründer erkannten den Bedarf an sicher gehosteten Remote-Repositories. Sie gründeten ein Unternehmen, das eine Cloud-Plattform anbietet, auf der Entwicklungsteams ihre Remote-Repositories hosten können. Im April 2019 beherbergte GitHub über 100 Millionen Repositories.
Wenn eine Anwendung ein Open-Source-Projekt ist, ist es sehr wahrscheinlich, dass sie auf GitHub gehostet wird. Es gibt zwar auch andere Plattformen wie Bitbucket und GitLab, aber GitHub ist die führende Plattform für Open-Source-Repositories.
Die Struktur eines Repositories
Ein GitHub-Repository besteht aus Ordnern und Dateien, darunter die eigentlichen Quellcodedateien. Oft sind auch andere Arten von Dateien im Repository vorhanden, wie Dokumentationsdateien, Handbuchseiten, Lizenzdateien, Build-Anweisungen und Shell-Skripte. Es gibt keine festen Regeln, was ein Repository enthalten muss, aber es gibt Konventionen.
Wie man sich in jeder Küche zurechtfindet, so ist es auch mit Repositories. Wenn man die Konventionen kennt, weiß man, wo man die benötigten Informationen findet.
Aber wie gelangt nun eine Kopie des Repositorys auf Ihren Computer und wie wird daraus eine ausführbare Datei?
Die Readme-Datei
Es ist üblich, eine Readme-Datei in einem Repository zu haben. Sie kann „Readme“, „readme“ oder „README“ heißen und entweder die Dateiendung „.md“ haben oder ganz ohne Endung auskommen.
Sehen wir uns beispielsweise das Repository des Atom-Editors auf GitHub an. Sie sehen eine lange Liste von Ordnern und Dateien. Scrollen Sie nach unten und Sie sehen den Inhalt der Datei README.md.
GitHub zeigt den Inhalt der Readme-Datei automatisch auf der Startseite des Repositorys an. Wenn die Readme-Datei die Endung „.md“ hat, enthält sie Markdown-Markup. Damit können Entwickler Formatierungen wie Schriftarten, Aufzählungszeichen und Bilder hinzufügen.
Eine Readme-Datei enthält in der Regel Informationen darüber, worum es in dem Projekt geht, welche Lizenz gilt, wer das Projekt betreut, wie man sich beteiligen kann und wie die Anwendung erstellt und ausgeführt wird.
Sollten die eigentlichen Build-Anweisungen nicht direkt enthalten sein, findet man in der Readme-Datei Hinweise, wo diese Informationen zu finden sind. Auch Angaben zu benötigten Build-Tools oder anderen Abhängigkeiten können hier stehen, oder man findet einen Link zu diesen Informationen.
Das Beispiel: Das ‚Boxes‘-Repository
Wir wollen das Boxes-Repository klonen und die ‚Boxes‘-Anwendung bauen.
Das Repository ist ähnlich aufgebaut wie das von Atom: Eine Liste von Ordnern und Dateien, darunter der Inhalt der Readme-Datei. Es ist ein kleineres Projekt, daher gibt es weniger Ordner und Dateien.
Die Readme-Datei ist auch kürzer und enthält einen Abschnitt mit dem Titel „Entwicklung“. Dort findet sich ein Link mit der Bezeichnung „Building from Source“. Diesem Link folgend, sollten wir alle nötigen Anweisungen finden.
Normalerweise ist etwas Recherche nötig, um sich im Repository zurechtzufinden und die relevanten Informationen zu finden, aber es ist nicht schwierig. Lesen Sie alles auf der Repository-Seite aufmerksam durch. Manchmal sind Informationen vorhanden, aber nicht offensichtlich platziert.
Die Abhängigkeiten
Die Seite „Building from Source“ enthält einen Abschnitt „Building on Linux“. Dort steht, dass wir einen C-Compiler, Bison und Flex benötigen.
Die Build-Anweisungen besagen, dass wir den Befehl ‚make‘ ausführen sollen, also benötigen wir auch dieses Tool.
Zusammengefasst benötigen wir für den Bau der Anwendung: einen C-Compiler, Bison, Flex, make und Git (um das Repository zu klonen).
Wir haben diesen Artikel auf Rechnern mit Ubuntu, Fedora und Manjaro geschrieben. Keine dieser Distributionen hatte alle diese Tools vorinstalliert, auf jeder mussten einige nachinstalliert werden.
Installation der benötigten Tools
Unter Ubuntu fehlten Git, Flex, Bison und Make. Hier sind die Befehle:
sudo apt-get install git
sudo apt-get install flex
sudo apt-get install bison
sudo apt-get install make
Unter Fedora fehlten Flex, Bison und make. Hier die entsprechenden Befehle:
sudo dnf install flex
sudo dnf install bison
sudo dnf install make
Manjaro benötigte den GCC-Compiler, Flex und Bison. Hier die Befehle:
sudo pacman -Syu gcc
sudo pacman -Syu flex
sudo pacman -Syu bison
Klonen des Repositorys
Jedes GitHub-Repository hat eine eindeutige Webadresse, die wir mit Git verwenden, um das Repository auf unseren Computer zu klonen. Auf der Hauptseite des Boxes-Repositorys finden wir einen grünen Button mit der Aufschrift „Klonen oder herunterladen“.
Klicken Sie auf den Button, um die Webadresse anzuzeigen. Diese Adresse wird dem git-Befehl übergeben, um das Repository zu klonen.
Navigieren Sie zu dem Verzeichnis, in dem Sie das Repository speichern möchten und geben Sie dann folgenden Befehl ein. Wenn Ihr Terminal das unterstützt, können Sie die Adresse kopieren und einfügen. In einem GNOME-Terminal funktioniert das mit Strg+Umschalt+V.
Git klont das Remote-Repository und erstellt ein lokales auf Ihrem Computer. Es informiert uns auch darüber, dass es in ein Verzeichnis namens „boxes“ klont.
Das Verzeichnis ‚boxes‘ wird in dem Verzeichnis erstellt, aus dem Sie den git-Befehl aufgerufen haben. Wenn wir in das Verzeichnis ‚boxes‘ wechseln und uns den Inhalt ansehen, sehen wir die gleiche Liste von Dateien und Ordnern, die wir auf der GitHub-Seite gesehen haben.
Perfekt! Wir haben den Quellcode und andere Dateien erfolgreich auf unseren Computer geklont. Nun müssen wir die Anwendung erstellen.
Erstellen der Anwendung
Um die Anwendung zu erstellen, folgen wir den Anweisungen im GitHub-Repository. Manchmal wird ein bestimmtes Shell-Skript ausgeführt, manchmal ‚make‘. Die Build-Anweisungen in diesem Fall empfehlen, ‚make‘ zu verwenden.
Das Tool ‚make‘ liest eine Reihe von Anweisungen aus einer ‚Makefile‘ und führt sie aus. Diese Anweisungen erklären ‚make‘, wie das Programm kompiliert und gelinkt werden muss. ‚make‘ leitet diese Anweisungen dann an den Compiler und andere Build-Tools weiter.
Der Befehl, den wir verwenden sollen, ruft ‚make‘ zweimal auf. Der erste Aufruf erstellt die Anwendung, der zweite führt einige Tests aus.
Der von den Build-Anweisungen vorgeschlagene Befehl lautet:
make && make test
<img loading=“lazy“ decoding=“async“ src=“https://1