spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

@dot: Jetzt interessiert mich aber schon, was genau dich an CMake stört
Die Syntax und ein paar fehlende oder umständlich zu nutzende Features, haben mich auch schon mal genervt,
aber warum du es so sehr verachtest, kann ich im Moment nicht nachvollziehen.

Optimal wäre natürlich ein Maven/Gradle-Equivalent. Gestaltet sich aber schwierig, weil Java wesentlich freundlicher mit unterschiedlichen Plattformen umgeht. Gibt da ja nur wenige Ausnahmen.

Apropos schon mal Gradle für C++ ausprobiert? Unity wird ja auch damit gebaut.

Alternativen gibt's schon, ich finde Premake eigentlich nicht übel... CMake ist echt unheimlich ekelhaft. Inkosistenter Müll.

MfG
Check

Wenn CMake mal (wieder) nicht auf Anhieb funktioniert, weil es z.B. wieder Schwierigkeiten hat eine Abhängigkeit zu finden, ist es meiner Meinung nach viel zu undurchsichtig CMake zu "helfen".

Ich verwende CMake seit Jahren. Nicht weil ich so prufund in CMake bin, sondern weil es mMn am besten Abhängigkeiten auflösen kann, wenn man sich mal eine entsprechende Entwicklungsumgebung definiert hat (z.B. Verzeichnis mit ext. Abhängigkeiten und ENV-Varaibale, *.cmake-Tragets importieren etc.), was ich auch durch Erfahrungen mit zahlreiche Projekte in C++ bestätigen kann.
Wenn ich dann Postings lese, die einfach irgendwelche Behauptungen wie "inkonsistenter Müll" und "...ist doof..." in den Raum werfen, ist das für eine objektive Diskussion nicht nützlich.

Mal konkret zu Beispiel-Problemen, die der eine oder andere haben könnte, ohne diese genau zu kennen, da sie ja nicht benannt werden:

1. Abhängigkeiten finden:
- Dafür gibt es FindModule. CMake bringt dafür einen erheblichen Satz an Modulen für Bibliotheken mit sich.

Beispiel: Qt5
FIND_PACKAGE(Qt5 REQUIRED Core Sql Gui Widgets Network)
Das entsprechende Modul bringt CMake schon mit.

Mit ein bißchen Recherche im Qt-Forum bekommt man dann auch noch die fehlenden den Optionen
gesetzt. Dieses Skript schreibe ich genau einmal. Und dann nie wieder, sondern verwende es nur noch.

Beispiel: Eigene Abhängigkeit aus meinem Dev-Verzeichnisbaum
include("${PROJECT_SOURCE_DIR}/../iomessages/installed/lib/iomessages.cmake")
INCLUDE_DIRECTORIES(${IOMESSAGES_INC_DIR})
Fertig. Ich verwende das CMake Library-Export-Skript meiner C++ Bibliothek "iomessages", um es in meiner EXE
einzubinden. Zwei Zeilen.

2. Install-Target
Ich halte es für unerlässich, nach einem Kompiliervorgang auf Basis von CMake auch das Installtarget zu bauen. Sprich
also eine saubere Verz-Struktur mit includes, libs und bins erstellen zu lassen, die man durch einfaches kopieren
dort nutzen kann, wo man es braucht, bzw. in eigenen Find-Modulen wieder entsprechend in weiteren Projekten einbinden
kann.

Beispiel:
# install
INSTALL(TARGETS iomessages
EXPORT iomessages
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib)
INSTALL(FILES ${PROTO_H} DESTINATION "include")
INSTALL(EXPORT iomessages DESTINATION "lib")

Von dieser Basis ausgehend, kann man ganz gut CMake-basierte C++Projekte auch wieder in andere Projekte einbinden. Und die Verzeichnisstruktur des Installtargets ist so ordentlich, dass mMn auch andere Buildsysteme damit klarkommen sollten.

Vielleicht hilft dass hier ja dem einen oder anderen weiter zu kommen und er gibt CMake nochmal ne Chance.
Aber nicht falsch verstehen, ich bin kein Verfechter von Tools die jeder benutzen muss, sondern ich versuche hier eine Hilfestellung zu geben. Was ihr letzten Endes verwendet ist mir wurscht, ihr könnt das meinetwegen auch mit cl.exe von Hand kompilieren. Nur vermittelt hier keinen Eindruck ein Tool wäre schlecht, nur weil eventuell mangelnde Information zum nicht sachgemäßen Umgang mit dem Tool geführt hat.

In diesem Sinne.
Thoran

CMake befolgt keinen konkreten Standard bzw. keine Richtlinie, was es inkosistent macht. Die Syntax ist einfach nur Grauen. Mit CMake kann ich auch nichts wieder deinstallieren lassen. Teilweise muss man auch für einige Compiler Sonderregeln einfügen! (wozu benutze ich dann überhaupt das Build-System, das mir die Arbeit doch eigentlich abnehmen soll(te)?)
CMakes Modularisierung ist Fluch und Segen zugleich, wenn meine "Entwicklungsumgebung" funktioniert, dann ist alles tutti, aber wenn eine Abhängigkeit wegen irgendwas failed, hatte ich bisher nie eine angenehme Zeit, unheimlich nervig diesen Fehler dann zu beheben. Mag sein, dass ich was das betrifft dann einfach zu unerfahren mit CMake bin, aber genau das ist doch dann auch das Problem. Ein Tool sollte leicht verständlich sein, nur dann macht es auch Spaß, damit umzugehen. Die Dokumentation finde ich auch nicht so hilfreich, aber das mag auch daran liegen, dass ich mich zu wenig mit beschäftigt habe, weil mich genügend andere Faktoren total abgeschreckt haben. Ich meine, warum denn bitte set(foo "bar") statt foo="bar"? Und warum darf ich auch SET(foo "bar") schreiben!? Mag sein, dass CMake ein wirklich tolles (und großes....) Tool ist, aber wenn ich mich da erstmal heftig einarbeiten muss und dabei eine ähnliche Freude wie bei PHP habe, (was sich mittlerweile ja wirklich deutlich gebessert hat) dann vergeht so sehr der Spaß daran, dass ich es lieber links liegen lasse und in Forenbeiträgen dumm darüber herumflame.
Premake, für nicht Windows-Zeug Autotools oder ein schlichtes Bash-Script machen mir allerdings sehr viel Spaß.

MfG
Check

Es geht mir nicht darum dich zu etwas zu "bekehren". Ich mache hier auch keine Vorwürfe, aber eigentlich gibt es für das was du geschrieben hast ne einfache Regel:

Willst du ein hochflexibles Tool, das allesmögliche unter einem Dach vereint? Dann kommst du um Einarbeitung in das Tool nicht herum. Mit dem Funktionsumfang steigt die Komplexität eines Tools. Mit der Komplexität steigt die Dauer bis man es beherrscht.

Ob nun "set(" oder "SET(" bzw. set(FOO "bar") anstelle von FOO=bar, das ist Geschmacksache. Entweder man kommt damit zurecht oder auch nicht. Bestimmt kann man vieles besser machen im Syntax von CMake. Auf der anderen Seite, meckern Programmierer aber nicht, wenn es darum geht sich in Ihrer Lieblingssprache mit der Pistole durch die Brust ins Knie zu schießen.

Also kurz: Ja ich gebe dir recht, Cmake ist komplex und nicht einfach zu lernen, insbesondere wenn man die Installationstools, Testing und einen sauberen Ansatz für Abhängigkeitsauflösung beherrschen will. Mit der Syntax kommt man halt zurecht oder nicht.

Auf der anderen Seite habe ich auch mit Maven zu tun, dass ich konzeptionell echt super finde, aber praktisch zum Umsetzen eine Vollkatastrophe (eigene Repos ausfsetzen, verwalten). Aber das liegt garantiert nur daran dass ich bisher nicht genug und die richtige Doku dazu gelesen habe. D.h. was Dir Cmake ist, ist mir Maven.

Was ich nicht verstanden habe ist, warum etwas inkonsistent wird, wenn es keine Standards befolgt, mal abgesehen davon, dass ich auch schon genug inkonsistente Standards gesehen habe.