spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

@BlueCobold: Ich kann Dir da nicht viel entgegensetzen. Jeder muss für sich alleine entscheiden wie er seine Builds erzeugen will. Ich habe mir nun vor etwa 8 Jahren meine Cmake-build Dateien für meine ersten Projekte erzeugt. Diese funktionieren heute noch. Kopieren, an das neue Projekt anpassen (Namensgebung, Targets) noch die Sourcefiles eintragen, die es eventuell schon gibt und es läuft auf Windows, Linux und potentiell auch auf Mac (hab leider keinen, hab den Teil des Skripts das letzte mal vor 6 Jahren verwendet). Aber ich will ja auch niemand auf CMake heben. Jedem sein Buildsystem. Aber die Frage war nun mal konkret nach CMake und dann finde ich es gerechtfertigt, dass man die Problematik des OP zumindest versucht zu lösen, was sich ja leider nun erledigt hat.

Gut, bei dem letzten Satz hast du an sich erstmal Recht. Nur sind manchmal die gesuchten Lösungen nicht immer die besten, wir wollen ja auch beratend wirken, nicht nur die konkreten Probleme lösen. Sicherlich wäre eine korrekte Lösung dennoch nett, also falls du Ideen hast, immer her damit.

Zitat von »Thoran«

@dot: Du hast also nicht genau verstanden was er will, *rantest* aber vorsorglich schon mal über CMake ab?

Ich dachte schon, dass ich ungefähr verstanden hatte, was er will. Der Grund wieso ich nachgefragt hab, war mehr um ihn dazu zu bringen, seine Annahmen zu hinterfragen...sokratische Methode und so... https://de.wikipedia.org/wiki/Mäeutik

Einen Rant kann ich in meiner ursprünglichen Antwort ehrlich gesagt nicht wirklich erkennen. (Rants sind normalerweise länger als ein Satz!?) Das war lediglich ein gut gemeinter Rat; meine persönliche Meinung, basierend auf meiner persönlichen Erfahrung...

Zitat von »Thoran«

[...] es einfacher ist über CMake zu schimpfen anstatt sich mit der Lösung des Problems auseinanderzusetzen.

Es ist meistens sogar unglaublich viel einfacher, über CMake zu schimpfen, als sich mit der "Lösung" des Problems in CMake auseinanderzusetzen. Wenn etwas in CMake keine direkte Lösung hat, dann läuft es in den meisten Fällen auf eine Kollektion von unterschiedlich ekelhaften Hacks hinaus, die gerade in Mode sind, aus der man dann wählt, basierend darauf, mit welchen Problemen man am ehesten leben kann. In vielen Fällen (wie offenbar auch dem konkreten Fall hier), gibt es aber auch andere Lösungen: Erkennen, dass CMake nicht unbedingt das beste Werkzeug für das gegebene Problem ist, und sich einer anderen Lösung zuwenden. Wenn du kein portables Buildsystem brauchst, dann brauchst du kein CMake. Nachdem "Visual Studio Projekt manuell einrichten" eine geeignete Lösung zu sein scheint, war ein portables Buildsystem wohl nicht wirklich gefragt...

Zitat von »Thoran«

@Strike: Du lässt Dich also aufgrund eines Threads in einem Hobbyentwicklerboard entmutigen Dein eigentliches Problem zu lösen?

Soweit ich das verstanden hab, war sein Ziel ein funktionierendes Visual Studio Projekt. CMake ist manchmal vielleicht der einzig gangbare, einfachste oder naheliegendste, aber nie ein guter Weg zu diesem Ziel (denn die von CMake generierten VS Projekte sind schrecklich, zumindest wenn man was von VS Projekten versteht; mir stellt es regelmäßig die Nackenhaare auf, wenn ich wieder mal in einem solchen Projekt herumstochern muss).

Zitat von »Thoran«

Was dabei mMn oft übersehen wird, ist, dass CMake einen vergleichsweise hohen initialen Aufwand hat, aber dann ziemlich stabil bleibt. Wenn ich alles platformspezifsich von Hand mache, habe ich potenziell n Fehlerquellen bei n Platformen und für jede neue Platform kommt neuer Initialaufwand hinzu.

Ich weiß ja nicht in welchem Umfeld du so mit CMake arbeitest, aber meiner Erfahrung über die letzten 10+ Jahre nach (darunter auch ausreichend komplexe Buildsysteme im professionellen Umfeld), funktioniert das Ideal vom plattformunabhängigen CMake Script vielleicht in erster Näherung für ein paar konstruierte Tutorial Beispiele, aber nicht in der Praxis. Das Design von CMake selbst hat dermaßen viele mit sich selbst inkompatible Auswüchse... wie eine Krake mit Armen, die sich alle gegenseitig nicht leiden können... Viele Features in CMake existieren überhaupt nur, weil ein konkretes Targetsystem ein solches Feature hat und sind damit nicht portabel by design. Beispiel: siehe das mit den Folders oben, die gibt's effektiv nur weil Visual Studio. Viel schlimmeres Beispiel: Der generelle Abgrund der sich zwischen single- und multi-configuration Builds auftut... schonmal versucht, eine Library die aus einem single-configuration build exportiert in einen multi-configuration Build einzubinden? Wenn du eine solide Lösung dafür kennst: Ich bin sehr gespannt und dankbar. Die einzigen mir bekannten Lösungen laufen alle darauf hinaus, dass du, nach ausreichend umfangreicher Studie der Skripte des anderen Buildsystems (mit dem du eigentlich nichts zu tun haben wolltest), dein Buildsystem entsprechend auf dessen Eigenheiten auslegen darfst. Und wenn sich beim nächsten Release im anderen Buildsystem was ändert, dann geht der Spaß von vorne los. Und das ist imo ziemlich repräsentativ für viele der Probleme mit CMake: Jeder macht es anders, weil CMake für alles vier verschiedene Lösungen hat, die gängigen Hacks zu denen Halbwissende überall im Internet raten noch gar nicht mitgezählt. Der ganze Import/Export/Interface Kram sieht mittlerweile ja auf den ersten Blick fast brauchbar aus. Die Schmerzen kommen wenn man es mal wirklich verwenden will. install(export) vs. export() ... Sorry, aber meine Erfahrung ist nunmal, dass CMake Bullshit ist. Nicht nur einfacher Bullshit, sondern systematischer Bullshit. Und daher kann ich auch niemandem guten Gewissens dazu raten, solange nicht gewisse Anforderungen gegeben sind, die CMake unvermeidlich machen...

So; ich denke, das qualifiziert nun tatsächlich als Rant...

Zitat von »dot«

Ich dachte schon, dass ich ungefähr verstanden hatte, was er will. Der Grund wieso ich nachgefragt hab, war mehr um ihn dazu zu bringen, seine Annahmen zu hinterfragen

Das ist mir dann entgangen.

Zitat von »dot«

Einen Rant kann ich in meiner ursprünglichen Antwort ehrlich gesagt nicht wirklich erkennen. (Rants sind normalerweise länger als ein Satz!?) Das war lediglich ein gut gemeinter Rat; meine persönliche Meinung, basierend auf meiner persönlichen Erfahrung...

Ich muss ehrlich sagen, dass ich den Hintergrund des ZFX-Artikels in Deine Antwort mit eingeblendet habe. Das war unfair, sorry dafür.

Zitat von »dot«

Soweit ich das verstanden hab, war sein Ziel ein funktionierendes Visual Studio Projekt. CMake ist manchmal vielleicht der einzig gangbare, einfachste oder naheliegendste, aber nie ein guter Weg zu diesem Ziel (denn die von CMake generierten VS Projekte sind schrecklich, zumindest wenn man was von VS Projekten versteht; mir stellt es regelmäßig die Nackenhaare auf, wenn ich wieder mal in einem solchen Projekt herumstochern muss).

Nun, ich habe dem Satz über die Plattformunabhängigkeit offensichtlich zu viel Gewicht beigemessen. Und das Argument mit den generierte VS-Projekten lass ich nicht gelten, weil ich ja CMake deswegen einsetze, um mich nicht mit den Projektdateien beschäftigen will. Für mich sind und bleiben das Blackboxen, wenn ich CMake einsetze.

Zitat von »dot«

Ich weiß ja nicht in welchem Umfeld du so mit CMake arbeitest, aber meiner Erfahrung über die letzten 10+ Jahre nach...

Ich habe CMake hauptsächlich private und bei vorherigen Arbeitgebern nur für kleine Projekte eingesetzt. Aktuell allerdings bin ich direkt involviert/betroffen von der Umstellung unseres Produktes von plattformspezifischen Builddateien auf CMake (alle gängigen Plattformen). Allerdings ist es dann dort auch so, dass wir zu CMake auch noch Conan fürs Dependency-Management einsetzen. Und ja, CMake ist nicht der Weisheit letzter Schluss, aber das hab ich nie behauptet.

Zitat von »BlueCobold«

Nur sind manchmal die gesuchten Lösungen nicht immer die besten, wir wollen ja auch beratend wirken

Ich kann leider erst beratend wirken, wenn ich sein Problem kenne und verstanden habe. Da brauche ich u.U. manchmal mehr Infos als andere. Falls der OP nochmals Infos zum Problem liefert, kann ich gerne Ratschläge geben, aber angesichts der Tatsache, dass er wirklich nur ein Windowsprojekt aufsetzen will, halte ich dass dann tatsächlich für über das Ziel hinausgeschossen. Dafür war dann aber leider sein erster Post mit der Plattformunabhängigkeit irreführend. Da wäre ich dann wieder bei dem Punkt warum ich generell nach mehr Infos frage.

Zitat von »Strike«

Außerdem sollten so einfache Dinge wie Unterordner zur Übersicht (für die extra groups implementiert wurden!!!) wirklich kein Problem sein.
Wenn das schon nicht funkt fragt man sich wirklich was da noch kommt...

In aller Fairness muss man dazu sagen, dass das natürlich schon geht und auch nicht besonders schwer ist. Es bedarf dazu aber halt einiger Einarbeitung in die Grundlagen von CMake.

Ich bräuchte, wie im ersten Posting angedeutet, eine genauere Beschreibung, was genau du dir für eine Ordnerstruktur vorstellst.

Ok, dann hab ich das so verstanden, dass wir hier tatsächlich über Ordner auf der HD reden.

Nun ist es so, das CMake mit dem Grundsatz entwickelt wurde, dass es irrelevant ist wo der Builds-Ordner liegt. Er kann "Build" unter deinem Hauptverzeichnis sein. Er kann aber auch auf einem ganz anderen Laufwerk liegen und dort "\Bibs\Kompilate" heißen. Der Punkt auf den ich raus will ist, dass es ein CMake-Script absichtlich nicht vorgibt, wo deine "Builds" liegen. Im Gegenteil ist CMake dafür gedacht, das jeder der eine OSS-Lib runterlädt, sich das Projekt hinlegen lassen kann, wo er will. Im Zweifel (was aber mMn die schlechteste Alternative ist) direkt in das Hauptverzeichnis des Sourcecodes.

So nun mal zum begriff Build, eigentlich ist das was im klassichen Buildverzeichnis liegt nicht dein Build-Ergebnis sondern dein Projekt. So wie ich das bei Dir aus

Zitat von »Strike«

Die Buildstruktur die in Build1 und/oder Build2 entsteht soll folgendermaßen aussehen:

verstehe, willst du am Ende aber Verzeichnisse haben, die dein Kompilat enthalten. Dafür gibt es eigentlich das Install-Prefix. Zumindest verwende ich das so. Damit kannst du für unterschiedliche CMake-Aufrufe auf das gleiche CMakeLists.txt unterschiedliche install-Verzeichnisse mit den jeweiligen Kompilaten der jeweiligen Projektkonfigurationen bekommen. Dort kannst du dann reinpacken was du "veröffentlichen" willst. Bei mir sieht das, dann so aus wie im ersten Bild im Anhang.
Die Anweisungen im CMakeLists.txt sehen dazu so aus:

Tatsächlich ist der RUNTIME-Abschnitt unnötig, da es sich hier um eine Bibliothek ohne Executable handelt. Das ist dann wohl per Copy&Paste reingerutscht. Die Anweisung INSTALL(EXPORT...) sorgt dafür, dass sog. Exporttargets geschrieben werden. Das sind CMake-Dateien, die bei mir dann auch in "lib" liegen und einfach in einem referenzierenden Projekt per "include"-Anweisung eingebunden werden können (siehe Anhang 2). Dadurch habe ich dann in dessen CMakeLists.txt alle Informationen zum Einbinden dieser Bilbiothek hier automatisch verfügbar. Die Anweisung INSTALL(FILES kopiert einfach eine Sammlung von Dateien, die ich vorher in Variablen gesammelt hab, in mein Installverzeichnis.

Ich hoffe, ich habe damit etwa Deine Frage erwischt und konnte etwas helfen.