Dieser Post wurde [wpstatistics stat=pagevisits time=total id=571] mal angesehen.
Wenn du eine Idee für ein neues Projekt hast und schnell etwas „rapid prototyping“ machen willst, aber gleichzeitig dein Projekt/Code mit Freunden / in kleinen Gruppen teilen möchtest, oder du auf unterschiedlichen Maschinen mit unterschiedlichem Setup coden möchtest (z.B. Workstation und Laptop), dann gibt es dafür einen netten Weg um das Aufsetzen der Projekte mit cmake am Anfang zu vermeiden.
Dadurch bekommst du mehr Speed beim „Rapid Prototyping“. Du willst coden und dich nicht mit Projekte-Bauen herumschlagen!
Wann ist das Ganze relevant?
Unterschiedliche Maschinen haben unterschiedliche Setups. Z.B. liegen manchmal die third-party Bibliotheken auf D:\Libs\ und manchmal auf E:\3rdparty-libs\ oder sonst wo.
Wenn du das Visual Studio Projekt in das Git Repository eincheckst, dann kann nur einer der Orte im Projekt eingestellt sein und bei Maschinen mit den anderen Orten wird es ohne Modifikationen nicht bauen.
Normalerweise erstellt man dafür cmake Dateien, so dass alles angepasst und gefunden werden kann. Die Projekte werden dann nicht in das Repository eingecheckt, sondern auf jeder Maschine durch cmake frisch erstellt.
Aber ist das eine Option für „rapid prototyping“, wenn man schnell seine Ideen ausprobieren aber auch teilen will?
Meiner Einschätzung nach nicht. Am Anfang ist möglicherweise die Projektstruktur auch noch gar nicht klar und wird sich oft ändern. Dann muss man immer die cmake Dateien anpassen, anstatt die Änderungen schnell in der IDE vorzunehmen und dann weiter zu coden.
Dieser Workflow jedoch funktioniert nicht, wenn unterschiedliche Maschinen mit unterschiedlichen Setups zum Einsatz kommen. Es müssen dann für jede Maschine die Projektsettings angepasst werden. Jedes Mal, wenn das Projekt geändert wird, muss man auf jeder Maschine wieder die Änderungen durchführen. Außerdem sorgt es potentiell bei jedem Update für Konflikte.
Natürlich ist das alles nur relevant, wenn man „rapid prototyping“ unter Windows mit Visual Studio betreibt. Meiner Einschätzung nach ist allerdings Visual Studio auch sehr gut dafür geeignet.
Sobald man dann anfängt die ersten Compile-Tests unter z.B. Linux zu machen und die Projektstruktur sich allmählich stabilisiert, ist es an der Zeit auf cmake umzusteigen. Aber dann ist das „rapid prototyping“ auch vorbei und man hat die Zeit dafür.
Dafür gibt es eine nette Lösung. Diese heißt:
Visual Studio Property Sheet
Die Idee ist, spezifische Projektsettings in separate Dateien aufzuteilen, welche dann einmalig auf jeder Maschine angepasst werden aber nicht Teil des Git Repositories sind. Im Repository befindet sich nur ein Template der Datei, welches genutzt wird um die Settings nach dem ersten Checkout zu erstellen.
Diese Technik existiert in Visual Studio und ist über den Property Manager verfügbar. Du kannst den Property Manager öffnen via Main Menu ➔ VIEW ➔ „Property Manager“.
Im Property Manager kannst du alle Property Sheets der Projekte deiner aktuellen Solution sehen. Wenn du eins öffnest, dann siehst du den bekannten Property Dialog, in dem man normalerweise die Projekt Settings ändert.
Der Unterschied ist, dass die geänderten Settings in einem Property Sheet als eigenständige Datei gespeichert werden, welches dann im Projekt geladen wird.
Um in der Lage zu sein unterschiedliche third-party Orte per Maschine zu haben, erstellen wir ein neues Property Sheet welches nur dazu dient die Include Pfade zu konfigurieren.
Nachdem du das neue include.props Sheet hinzugefügt hast, öffne es (Doppelklick auf den Schraubenschlüssel 🔧 – NICHT auf den Namen!) und navigiere zu „Common Properties“ ➔ „VC++ Directories“ und wähle „Include directories“ aus. Öffne den Editor via „Edit“ und füge alle gewünschten Includepfade hinzu, so wie sie auf der aktuellen Maschine vorliegen.
Nachdem alle Pfade hinzugefügt worden sind, speichere das Sheet (den Knopf mit dem Disketten-Symbol drücken) und browse via Explorer zum Top Level Ordner deines Repos.
Kopiere includes.props und nenne es in includes.props.template um.
Nur die includes.props.template Datei wird in das Git Repository eingecheckt. Die includes.props Datei ist nur eine lokale Datei auf der aktuellen Maschine.
Um sicher zu gehen, dass die includes.props nicht irgendwann ausversehen eingecheckt wird, fügen wir sie in die .gitignore Datei hinzu.
Nachdem die Projektdateien sowie die includes.props.template Datei committed hast, kannst du das Repo auf einer anderen Maschine auschecken.
Kopiere die includes.props.template Datei, nenne sie in includes.props um und editiere sie so in einem Editor, dass die Includepfade für die aktuelle Maschine angepasst sind.
Das war es! Jetzt kannst du das Projekt auf der anderen Maschine öffnen und bauen.
Deswegen weil die Includepfade vom Projekt getrennt und nicht Bestandteil des Repos sind, kann man jetzt einfach das Projekt ändern oder die Includepfade anpassen ohne den Build auf anderen Maschinen kaputt zu machen.
Natürlich sind die Includepfade nur ein Beispiel.
Man könnte z.B. auch die Compile-Settings in einem Property Sheet speichern und dieses als Vorlage für jedes neue Projekt nehmen, so dass alle Projekte automatisch dieselben Compile-Settings haben.
Ich hoffe dieser Artikel war für dich von Wert und du hast vielleicht etwas Neues und Nützliche gelernt. Lass doch einen Kommentar da, auch wenn es dir gefallen hat, oder du zu etwas eine andere Meinung hast.
Fröhliches Programmieren! 😊