spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

CMake ist halt extrem verbreitet. Ich rege mich ständig darüber auf, nicht nur, weil die Sprache (für die Projektdateien) ziemlich bescheuert ist, sondern auch, weil (vermutlich deshalb) ziemlich viele CMake Scripte haarsträubend grottig geschrieben sind. Es gibt auch nahezu beliebig viele Alternativen dazu, aber alles was ich mir bisher angeschaut habe, hat mich auch nicht überzeugt. Und da CMake mittlerweile sowas wie ein Standard ist, muss man es sowieso irgendwie können.

Gerade wenn man auf unterschiedlichen Plattformen entwickelt, ist man geneigt, unterschiedliche IDEs zu benutzen, und dann führt eigentlich kein Weg an derartigen Build-Tools vorbei.Und CMake kann für (glaube ich) alle hier genannten IDES Projektdateien erstellen, was definitiv sehr nett ist.

F+r mehrere Plattformen mit mehreren Compilern in unterschiedlichen IDEs zu entwickeln, sehe ich ein Stück weit sogar als Vorteil, weil einem einfach Unterschiede und Details klar werden, die man sonst nie gesehen hätte. Und unterschiedliche Compiler zeigen vielleicht unterschiedliche Warnungen und Hinweise an. Letztendlich wird man also robusteren Code schreiben, aber es kann natürlich vorkommen, dass man auf manche neue Features verzichten muss, die noch nicht unterstützt werden.

Für Memory Leaks unter Windows kann ich Dr. Memory empfehlen. Ich habe damit schon sehr fiese Bugs gefunden (funktioniert in etwa wie Valgrind, nur angeblich schneller). Wobei besser als dass natürlich die Bemühung ist, sich einen Code-Stil anzulegen, der Memory-Leaks im Grunde unmöglich macht. Für den Rest sollte man dann natürlich aber trotzdem derartige Tools benutzen.

Zitat von »Sacaldur«

Ich hatte erst am Wochenende erst von jemanden mitbekommen, dass das Arbeiten mit XCode durchaus unangenehm sein soll. Es solle wohl so weit gehen, dass das erwähnen des Satzes "Ich hatte bereits 1 Woche mit XCode gearbeitet" im Lebenslauf der Gegenseite vermitteln solle, wie viel man in seinem Programmiererleben bereits durchlebt hat.

Na ja, dem kann ich so nicht zustimmen. Viele Dinge in Xcode sind in der Tat schlechter. Es stürzt gern ab, Build-Einstellungen sind gewöhnungsbedürftig, Debug-Ausdrücke enden gern in "invalid expression". Allerdings bietet Xcode auch Dinge, die man in anderen IDEs vermisst: Sources parallel nebeneinander aufmachen - einfach für Refactoring oder Copy/Paste, integrierte automatische Erkennung und Unterstützung für SVN/Git inklusive History, Blame, Compare und Konflikt-Auflistung.

Ich persönlich verwende für verschiedene Plattformen verschiedene IDEs. Ich kenne ohnehin fast alle und statt mich mit den Makeln einer IDE für alle Systeme zu quälen, wähle ich für jedes System die mMn am besten passende IDE. Eclipse CDT finde ich persönlich noch immer grauenvoll, mag aber daran liegen, dass der Debugger bei mir einfach nie die Sources finden will, egal was ich einstelle. Entweder pflegt man die Projektfiles von Hand, was man ja eigentlich nur einmal macht - oder man nutzt wie gesagt CMake und lässt sie sich erzeugen - wobei CMake noch immer nicht in der Lage ist für Xcode verschiedene Build-Einstellungen basierend auf den Zielsystemen gleichzeitig zu hinterlegen (z.B. iPhone-Simulator-Architekturen [i386/x86_64] vs. iPhone-Architekturen [arm]); das muss man von Hand nachpflegen, was sehr lästig sein kann.

Ich teste die letzten Monate Clion. Ist eigentlich recht gut und plattformunanhängig. Und weil es auch schonerwähnt wurde: Es benutzt intern CMake, somit kann man auch einfach direkt CMake Projekte damit laden.

Zitat von »BlueCobold«

Ich persönlich verwende für verschiedene Plattformen verschiedene IDEs. [...] und statt mich mit den Makeln einer IDE für alle Systeme zu quälen, wähle ich für jedes System die mMn am besten passende IDE.

same

Zitat von »Jonathan_Klein«

Und unterschiedliche Compiler zeigen vielleicht unterschiedliche Warnungen und Hinweise an. Letztendlich wird man also robusteren Code schreiben [...]

Das kann ich aus meiner Erfahrung nur bestätigen.

Dito. Man muss zwar hier und dort Kompromisse machen, aber es ist erschreckend, was verschiedene Compiler teilweise für Zeug kompilieren, wohingegen andere Warnungen oder gar Fehler werfen, was am Ende dazu führt, dass man weniger Fehler im Code und somit besseren und robusteren Code hat.