spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Meine Projekte werden meist es ziemlich modular und deswegen werden meine buildsystem scripte meistens ziemlich groß. Ich schreibe hauptsächlich c++, wenn ich die Wahl habe und benutze deshalb Cmake. Jeder der cmake kennt versteht meinen Schmerz. In der letzten Zeit habe ich privat immer häufiger mehrsprachige Projekte und dann müsste man gleich zwei. Unterschiedliche buildsysteme aufsetzen.

Da ich garantiert nicht der einzige bin, der solche Probleme hat, dachte ich wir könnten mal Drüber reden, ob wir uns nicht auf ein paar Standards einigen können und können das in eine art Framework zur Verwaltung von Projekten und ihren Teilen schreiben können.

Ich finde zu einem solchen System gehören mindestens folgende funktionen:

• Eine Workspace Ordnerstruktur die eine Art globalen Kontext für alle Teile eines großen Projekts darstellt.
  
• Automatisches erstellen von Ordnerstruktur en für teilprojekte oder Bibliotheken.
  
• weitest sinnvolle Abstraktion von tatsächlich meta-/buildsystem.
  
• Einzelne teilprojekte sollen ohne großen Aufwand autark verwendet werden können.
  
• Pfade zu konfigurationsdateien und assets verwalten können.
  
• für alle wichtigen Operationen bei denen leicht Fehler auftreten können einen Assistenten anbieten.
  
• unterschiedliche Tools über ein einheitliches interface bereitstellen und zusammengehörige Schritte gruppieren.
  
• Bibliotheken bietet um grundlegende Operationen wie z.B. Das laden von configuration en,... Plattformunabhängig zu erlauben.
  

Ich hoffe das klingt jetzt nicht unglaublich viel komplizierter, als ich mir das vorstelle.

Hier meine bisherigen Gedanken dazu. Ich habe in der Uni bereits einmal mit ROS und catkin gearbeitet und nehme deswegen wahrscheinlich hin und wieder Referenz auf meine Erlebnisse damit. Selbst wenn es features gibt, die catkin dazu bringen mehr Sachen selbst zu machen, sind sie schlecht genug dokumentiert um sie auch bei gründlichem lesen leicht zu übersehen.

1. Cmake als default buildsystem. Bevor ihr über cmake haltet, lasst mich bitte erklären wieso ich finde cmake eignet sich sehr gut dafür. Zuerst ist es weitgehend unabhängig von der Sprache, weit verbreitet und gut dokumentiert. Außerdem lässt es sich ziemlich einfach modularisieren und man kann Dinge in Funktionen auslagern.
   Ich gebe euch recht, dass die Sprache ziemlich doof ist, aber ich habe nicht vor besonders viel cmake Code innerhalb eines workspaces selbst zu schreiben. Ich möchte, dass die Cmake Dateien aus der Beschreibung eines Projektes generiert werden können - zumindest initial - und möglichst wenig von Hand bearbeitet werden müssen.
   Ich würde einen Wrapper um cmake packen, der die Projektbeschreibung in cmake Code verwandeln kann. Entweder würde ich die Beschreibung in python machen oder in json.
   
2. Ich möchte python als Sprache verwenden, da python relativ leicht zu lernen und für Anfänger gut zugänglich ist. Außerdem ist python ziemlich Plattform unabhängig.
   
3. Ich würde jedem teilprojekte einen eigenen config und asset Ordner anlegen, damit die configurationen mit in dem git repo verwaltet werden können.
   
4. Ich würde Bibliotheken, die als Sourcecode heruntergeladen und gebaut werden sollen, sollen zentral im Workspace abgelegt werden. Das ermöglicht es, dass es im Workspace nur eine Version des Codes gibt.
   
5. Ich möchte die systemeigenen Paketmanager bevorzugen, wenn die gewünschte Version verfügbar ist.
   
   

Ich würde folgende Ordnerstruktur vorschlagen:


Was das generieren von Code angeht würde ich einen grundlegend ähnlichen Ansatz nehmen wie zum Beispiel blockly ihn gewählt hat.

Jeder Befehl von cmake bekommt eine eigene Wrapper Klasse mit Attributen für jeden Parameter und eine Methode die den Aufruf eines Befehls als string ausgibt. Darauf lassen sich relativ leicht komplexere Patterns aufbauen. Außerdem lässt sich ein solcher Ansatz relativ leicht für andere buildsysteme anwenden.

Ich möchte, dass andere Teilprojekte mit einem download link verbunden werden können, damit diese von cmake automatisch heruntergeladen werden können. Zumindest finde ich das relativ sinnvoll um abhängigkeiten zwischen selbstgeschriebenem Code darstellen zu können ohne dass man einen Umweg über einen Paketmanager und den library Ordner gehen muss.

Ich würde die üblichen Tools, wie beispielsweise bei C++ clang-tidy, cppcheck, sanatizer, valgrind wrappen um einfach nur das Tool aktivieren zu müssen und alles nötige um die entsprechenden cmake targets zu generieren passiert von selbst.

Außerdem wäre es gut für verschiedene Umgebungen Features ein und auszuschalten, damit man damit beispielsweise auch in unity arbeiten kann.


Jetzt zum wichtigsten Teil, was meint ihr dazu und wie könnten wir uns einigen, damit nicht nur ich das am Ende benutzen könnte? Wäre doch cool, wenn zumindest ein paar Leute da mitmachen würden.

So ein einheitliches projektverwaltungssystem hat den Vorteil, dass man sich schnell in ein neues Projekt einfinden kann, da man weiß wo man nach Dingen suchen soll.

Frohe restliche Ostern.

Sry übrigens für die seltsamen Fehler in meinem Post. Der ist auf einem Telefon getippt und die autokorrektur schießt mir manch mal in den Fuß, ohne dass ich es merke.

Ich würde mich da ungefähr an catkin orientieren. Weil ich persönlich mit Linux vertrauter bin, werde ich hier mal spontan linux Befehle schreiben.




Init ws und init component werde dir ein paar Fragen stellen, die ich mir mal gespart habe, aber so ungeqefähr hätte ich gerne den workflow. Ich hoffe das beantwortet was du wolltest.