CONAN der Erbauer
14 Sep 2019Manche denken beim Title CONAN an den alten Kinofilm mit Arnold Schwarzenegger, andere erinnern sich an den Anime mit dem Detektiv-Jungen.
Und für einen meiner geschätzten Kollegen ist das Paket-Tool CONAN die Lösung aller Probleme in der C++ Entwicklung.
In der Theorie sieht es so aus:
- Wir schreiben einzelne C und C++ Dateien
- CMake fügt mehrere C/C++ Dateien zu einem generischen Projekt zusammen, das dann auf jeder Buildumgebung übersetzt werden kann
- Und
CONANverwaltet alle Abhängigkeiten von Paketen zwischen Projekten und erstellt automatisch CMake Files um mehrere Projekte unter einen Hut zu bekommen.
Ob das in der Praxis auch so sein wird … das lerne ich gerade im Zuge meiner Arbeit.
Beispiel Szenario
Angenommen wir schreiben ein Programm, das Kompression einsetzt, z.B. durch die gute alte ZLIB.
Jetzt können wir die Sourcen in ein Unterverzeichnis unseres Projektes
kopieren und einfach mitkompilieren.
Oder: wir nutzen CONAN und setzen eine Abhängigkeit auf ein CONAN-ZLIB-Paket.
Dann brauchen wir nämlich nur noch unsere eigenen Sourcen speichern und
ausliefern, und CONAN wird die fehlende ZLIB aus dem Internet (oder einem
lokalen Build-Artifactory) herunterladen.
CONAN stellt unterschiedliche Möglichkeiten seiner Nutzung zur Verfügung,
einige davon sind:
- Ein Paket kann alle Sourcen eines Moduls beinhalten und wird dann lokal bei bzw. vor der Nutzung neu kompiliert
- Ein Paket enthält Header und vorkompilierte Binärdateien. Damit lädt
CONANdie fertigen Dateien herunter und stellt sie dem Linker automatisch zur Verfügung. - Oder
CONANbesteht nur noch aus Binärdateien, die für die Auslieferung benötigt werden und wird so zu einem Setup/Deployment-Builder.
Implementierung
Ist CONAN auf dem System installiert, erweitert man CMAKE um ein paar Zeilen
und fügt die Datei conanfile.py hinzu.
Dabei handelt es sich um Python-Script, das eine spezielle Klasse
implementiert, deren Methoden in den einzelnen Ausführungsschritten das
Verhalten von CONAN beieinflussen.
Am wichtigsten sind dabei die Abhängigkeiten, wo wir festlegen, welche
anderen Pakete für den Einsatz unseres Pakets benötigen.
Diese haben das Format:
name/version@remote/branch
Im Falle des offiziellen ZLIB-Pakets für CONAN lautet der Pfad:
zlib/1.2.11@conan/stable
Der remote Parameter ist mit der Installation automatisch auf die
Server von conan.io und bintray.com gesetzt. Will man Pakete von
anderen bzw. eigenen Servern nutzen, muss ein entsprechender Name
registriert und der CONAN-Konfiguration mitgeteilt werden.
Wird nun direkt oder indirekt ein Paket installiert, z.B. mit
conan install zlib/1.2.11@conan/stable
dann lädt CONAN alle benötigten Dateien herunter und speichert
sie in einem (zugegeben etwas merkwürdigen) Pfad im Home-Verzeichnis.
Wenn wir dann unser leicht modifiziertes CMAKE nutzen, um Projektdateien
zu erzeugen, setzt CONAN automatisch alle Pfade für CMAKE auf die
richtigen INCLUDE- und LIB- Verzeichnisse, womit wir unser Projekt
kompilieren können, ohne komplexe Such-Routinen in CMAKE implementieren
zu müssen.
Denn dass CMAKE alle seine Dateien findet, kann bei größeren Projekten
mit mehreren Abhängigkeiten durchaus herausfordernd werden. Und genau
diesen Job soll hier CONAN erledigen.
Ein wichtiges Detail ist, dass im Falle von Binärdateien CONAN für jede
Plattform und Build-Option ein eigenes Paket erstellt. Für Windows
gibt es in der Regel 4 unterschiedliche Pakete für ein Modul, nämlich
- Debug Win32
- Release Win32
- Debug Win64
- Release Win64
Und CONAN leitet an CMAKE genau die Pfade weiter, die für die gewünschte
Build-Konfiguration notwendig ist. Und bei unterschiedlichen Compilern
bzw. auf Linux ist das ebenso.
Fazit
Nun, noch ist CONAN für mich ein Novum und die Umstellung eines größeren
Projektes (an der ich mitarbeiten darf) ist das teilweise recht aufwendig.
Tatsächlich liegt ein ordentlicher Teil des Migrationsaufwandes an jenen
Stellen, wo CMAKE Workarounds benutzt wurden um Features zu generieren,
die es ohne CONAN eben nicht gibt.
Solche Codes umzuschreiben und durch CONAN-Standards zu ersetzen erfordert
also dann doch etwas Programmieraufwand in Python und auch
Verzeichnisstrukturen oder Unit-Tests sind unter CONAN anders organisiert,
als bei einigen bestehenden Projekten.
Werde ich CONAN im GATE Projekt einsetzen?
Nein, vorerst nicht. Einerseits fehlt mir das Wissen, wie ein “ideales”
CONAN Projekt aussehen soll und außerdem sind externe Abhängigkeiten genau
das, was GATE vermeiden will. Dennoch bleiben stets ein paar Abhängigkeiten
auch bei mir übrig (z.B. GTK unter Linux) und vielleicht werden diese
in Zukunft auch durch eine CONAN-Lösung aus dem Weg geräumt werden.
Bis dahin gibt es aber noch viel für mich zu entdecken …