Das Ende der '.sln'
« | 13 Aug 2023 | »Seit meinen ersten Entwicklungs-Experimenten in Visual Basic sind sie fix
dabei: Die Verwaltungsdateien von Visual Studio.
Sie fassen die eigentlichen Source-Code-Dateien zusammen und heißen
“Projekte” im Einzelfall (.vcproj, .vcxproj) oder “Solution” (.sln)
als Sammlungen.
Jetzt ist Schluss damit. Ab jetzt kümmert sich ausschließlich CMake um diese Details.
Die Geschichte eines Fehlers
Da ich mit Windows aufgewachsen bin, habe ich das “grafische” Hinzufügen und
Entfernen von Quellcodes zu einem “Projekt” immer als die beste und stabilste
Form angesehen.
Ein neues Projekt wurde damit immer in der IDE erstellt und dann vollständig
in das Versionsverwaltungssystem eingespielt.
Und früher war das auch überlegen, denn ein Visual Studio 2005 Solution funktionierte bei rein nativem Code überall ohne Kunstgriffe.
Bei Linux hingegen funktionierte alles grundsätzlich nur auf dem Originalsystem. Wer also unter SUSE gegen 3 Bibliotheken per Makefile linkte konnte nicht wissen, ob die unter Ubuntu auch so heißen und durfte dann das Buildscript anpassen, oder lange aus-if-en, wie die Komponenten heißen.
Und um das “grafisch” besser kontrollieren zu können, nutzte ich lange Zeit Code::Blocks um auch Linux solche Projektdateien aufzuzwingen.
Ich generierte also “irgendwie” für jede Bibliothek ein Visual Studio und ein Code::Blocks Projekt und verwaltete diese dann für unterschiedlichen Plattformen.
Unter Linux war das … naja … immer schon blöd, es funktionierte aber unter Windows super, bis mit Studio 2012 neue Plattformtypen hinzukamen, die man nicht mehr in einer Solution unterbringen konnte.
Windows Phone und die Universal Windows Plattform brauchten eigene Solutions für sich, und so erzeugte ich eine Win32-Solution, eine UWP-Solution und später dann mit VS 2017 eine Android-Solution um immer die gleichen Sourcen zu einem Projekt zusammenzubinden.
CMake löst heute alles
Ich kann es heute ja immer noch nicht nachvollziehen, warum ich CMake so lange verweigert hatte. Grund dafür waren “komplizierte” Querschläger wie OpenSSL, die zwar für Win32 und Linux toll waren, bei WinCE oder UWP aber versagten. Doch das hätte ich auch damals schon angehen können.
Inzwischen hat CMake viele Tricks drauf um wirklich alle meine Wünsche zu
erfüllen und daher habe ich nun auch im GATE Projekt mit der Entfernung
aller Solution- und Projekt-Dateien begonnen.
Es ist heute auch gar nicht mehr möglich die Buildkonfiguration hart
festzulegen, denn jede Studio-Installation kommt mit einem anderen SDK und
mit jedem Update ändert sich dann auch noch der Minimum-Support der
Zielplattform. Man müsste also in jedem Studio mit der Hin- und
Herkonvertierung starten und das ist erst recht wieder Fehleranfällig.
CMake erkennt brav, was auf dem System vorhanden ist und erzeugt die Solutions und Projekte automatisch genau so, damit sie alles Vorhandene finden und nutzen.
Fazit
Good Bye SLN!
Es erzeugt in mir immer ein gewisses Retro-Feeling, wenn in einem Sourcepaket
eine .sln Datei oder was Ähnliches drinnen ist. Besonders auf
codeproject.com findet man noch viele solcher
alten C++ Projekte.
Heute erwarte ich von jedem C/C++ Projekt, dass eine CMakeLists.txt Datei
enthalten ist. Denn mit dieser lässt sich dann für wesentlich mehr Plattformen
eine Buildprozedur einrichten.