
CMake ALIAS target
« | 15 Sep 2024 | »Wie soll man CMake-Targets eigentlich benennen?
Die Authoren haben “Vorstellungen”, Conan hat “Alternativen” und ich habe meine eigenen Wünsche.
Doch zum Glück lassen sich solche Namen in CMake
leicht nachbessern.
Da meine GATE Builds auch mit antiken DOS-Compilern wie
OpenWatcom zurecht kommen müssen und deshalb
erweiterte Einstellungen notwendig sind, habe ich in den extlibs
den
Buildvorgang einiger Bibliotheken anpassen bzw. selbst ausimplementieren
müssen.
Damit am Ende alles mit CMake
läuft, habe ich mir auch ein paar
“Targetnamen” einfallen lassen, die vom Original abwichen.
Die zlib
ist hier ein etwas seltsames Beispiel, weil sie für Windows
und Linux unterschiedliche Bibliotheksnamen vorsieht
(zlib
und libz
, bzw. nur z
als Target)
Conan
hingegen stülpt über alle Projekte den neuen Standard für
Targetnamen drüber, und geht von ZLIB::ZLIB
aus.
Da das GATE Projekt sowohl mit der Eigenlösung, als auch mit Conan
Varianten
zurecht kommen soll, hatte ich ursprünglich jede Menge an if() else()
Zeilen im CMake
Code.
add_library(ALIAS)
Die Sache lässt sich aber viel einfacher lösen.
Anstatt beim Linken auszu-if-fen, ob Target-Name 1 oder 2 gewählt werden soll,
füge ich beim Importieren der gewünschten Quellen gleich einen Alias-Namen
ein, der alle Implementierungen auf den gleichen Namen umleitet, nämlich den
von Conan
.
Und so findet man im GATE CMakeLists.txt
Passagen wie:
Hier wird dann entweder “mein” lokaler Name auf das gesetzt, was
Conan
ansonsten erzeugen würde, oder ich benutzte find_package()
und erwarte von Anfang an das, was Conan
liefert.
Fazit
Die Alias Variante ist somit viel eleganter und vereinfacht den Code
im CMake
Projekt.
Parallel sollte man nicht vergessen, dass auch der von Conan
publizierte
Name im Endeffekt ein Alias auf einen internen Build-Namen ist.
Wie auch immer … Conan
sollte heute “der” Standard sein, wie
Bibliotheken benannt sind, damit wir endlich einheitlich mit
C oder C++ programmieren können.