CONAN 2
« | 15 Jul 2023 | »Das Buildsystem CONAN hatte einige Fehlerchen in seinem Konzept. Doch schon seit Jahren läuft parallel die Entwicklung von CONAN 2. Und dieses Projekt wälzt jetzt quasi alles um.
Vorgeschichte
Ich wurde vor 4 Jahren eigentlich durch ein Migrationsprojekt in der Firma auf
CONAN aufmerksam. Ein bestehendes CMake
Projekt sollte in CONAN Packages aufgeteilt werden, damit diese versioniert im
dortigen jfrog Repository abgelegt werden können.
Der Vorteil von CONAN liegt vor allem im Dependency-Management, wenn es um die Bereitstellung aller notwendigen Drittkomponenten geht.
Niemand befasste sich damals mit den unterschiedlichen “Generatoren” innerhalb
von CONAN v1, sondern man nahm den offensichtlich passenden, nämlich den
cmake Generator.
Dieser erzeugt aus den aufgelösten Abhängigkeiten eine cmake-include Datei,
welche vom Projekt CMakeLists.txt inkludiert wird. Und alle Details der
Abhängigkeiten liegen im Form von CMake Variablen vor, die das Projekt nun
integrieren kann, also z.B mit:
Daraus ergibt sich leider das Problem, dass diese “magischen” CONAN-CMake
Variablen dann nur noch innerhalb einer von CONAN erstellten Umgebung
korrekt funktionieren.
CMake hingegen würde normalerweise ohne CONAN per find_package(dependency)
Abhängigkeiten suchen …
Und so wurde eine Entscheidung getroffen:
Der CMake-Generator aus CONAN v1.x wurde in CONAN v2 entfernt.
Migration nach CONAN v2
Neue Generatoren
Anstatt also eine zirkuläre Abhängigkeit zwischen CONAN und CMake zu erzeugen, arbeitet CONAN v2 also “Zulieferer” für CMake.
Der CMakeDeps Generator erzeugt nun alle erforderlichen .cmake Dateien,
die per find_package dann die Abhängigkeiten im korrekten CMake-Stil in ein
Projekt integrieren. Man nutzt also keine CONAN-CMake-Variablen, sondern schreibt
die CMakeLists.txt so, als ob CONAN nicht involviert wäre.
Der CMakeDeps Generator aus v2 ähnelt sehr dem cmake_find_package Generator
aus v1.
Der CMakeToolchain generator hingegen erzeugt eine Toolchain-Datei, die
notwendige Informationen über den zu nutzenden Compiler und die Zielplattform
enthält. Man startet also CMake mit dem Verweis zu Toolchain-Datei um den
CMake-Build einzurichten. Auch hier haben wir keine magischen Variablen mehr
im Hintergrund.
Diese beiden neuen Generatoren sind also der Nachfolger des abgekündigten
v1 cmake-Generators.
Das wäre ja alles super, wenn es nicht bedeuten würde, dass jedes Projekt
und vor allem alle CMake-Dateien jetzt umgeschrieben werden müssen.
Änderungen in conanfile.py
Eine weitere gravierende Änderung ist, dass CONAN’s Python Framework ebenso
geändert wurde. Befanden sich bisher alle Klassen und Hilfswerkzeuge im
Python Modul conans, so ist man jetzt zum Namen conan zurückgekehrt.
Aus
1from conans import ConanFile
wird
1from conan import ConanFile
Auch andere neue Methoden in einer Conan Klasse wurden geändert.
So werden Generatoren nun in der neuen Method generate() geladen und angewendet
und die layout() Methode gestattet Änderungen von Attributen, wo Pfade für
Quellcodes und Ausgabedateien hinzeigen sollen.
imports() wurde vollständig entfernt, an dessen Stelle treten die neue
“Deployer”, mit denen Dateien aus Abhängigkeiten extrahiert werden können.
Damit ändert sich auch die Funktion der bestehenden deploy() Methode, die
nun mit dem eingesetzten Deployer zusammenspielen muss.
… und vieles mehr.
Fazit
CONAN v2 macht technisch vieles richtig. Es gestattet einem Projekt vor allem nach einer einmaligen Konfiguration durch CONAN, selbständig zu laufen. In v1 waren die engen internen Verflechtungen zwischen CONAN und CMake häufig die Ursache von Problemen, die damit behoben sein sollten.
Doch leider macht dieses Neudesign die Migration von großen Projekten mehr als schwierig.
Ich bin gespannt, wie wir jetzt in der Firma mit dem Thema umgehen. Es steht jedenfalls fest, dass eine Migration auch viele Vorteile und vor allem Zukunftssicherheit bringen wird.