CONAN 2

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:

include_directories(${CONAN_INCLUDE_DIRS})

target_link_libraries(${PROJECT_NAME} ${CONAN_LIBS})

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

from conans import ConanFile

wird

from 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.