Du bist nicht angemeldet.

Werbeanzeige

Thoran

Alter Hase

Beiträge: 512

Wohnort: Stuttgart

Beruf: Senior Software Engineer

  • Private Nachricht senden

11

03.06.2018, 17:34

@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.
Mein Entwicklertagebuch
Aktuelles Projekt: Universum Espionage
Eingestellt:Spieleengine SilverCore
Organisator "Spieleentwickler Stammtisch Stuttgart"

BlueCobold

Community-Fossil

Beiträge: 10 890

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

12

03.06.2018, 17:52

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. :)
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

dot

Supermoderator

Beiträge: 9 850

Wohnort: Graz

  • Private Nachricht senden

13

03.06.2018, 18:01

@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...

[...] 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...

@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).

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... ;)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (03.06.2018, 18:07)


Thoran

Alter Hase

Beiträge: 512

Wohnort: Stuttgart

Beruf: Senior Software Engineer

  • Private Nachricht senden

14

03.06.2018, 18:24

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.

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.

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.
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.

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.
Mein Entwicklertagebuch
Aktuelles Projekt: Universum Espionage
Eingestellt:Spieleengine SilverCore
Organisator "Spieleentwickler Stammtisch Stuttgart"

Strike

Frischling

  • »Strike« ist der Autor dieses Themas

Beiträge: 36

Wohnort: Wien 1200 und Techelsberg 9212

Beruf: Junior Software-Entwickler & Software Testing

  • Private Nachricht senden

15

03.06.2018, 21:58

@Thoran. Danke für dein Antwort

Was ist denn eigentlich Deine Erwartung? Eine Executable zu erstellen? Dann bekommst du nach Ausführen von Install ein Verzeichnis mit der Exe-Datei drin. Welche Ordner erwartest Du hier?


Meine Erwartung war dass die als source_group zusammengefassten Files einen Folder in der Solution bilden. In VS glaub ich auch Filter genannt.

Quellcode

1
2
source_group(includes FILES ${includes_list})
source_group(sources FILES ${sources_list})


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


Nein weniger deswegen. Sondern eher weil ich 2 Tage damit verschwendet hab die sonst besser investiert wären.


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.


Ja so seh ich das ja auch. Mein Problem ist nur dass es sich für mich kaum lohnt wenn ich die Plattform nicht ändert solang das Projekt noch klein ist.
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...

dot

Supermoderator

Beiträge: 9 850

Wohnort: Graz

  • Private Nachricht senden

16

03.06.2018, 22:11

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.

Strike

Frischling

  • »Strike« ist der Autor dieses Themas

Beiträge: 36

Wohnort: Wien 1200 und Techelsberg 9212

Beruf: Junior Software-Entwickler & Software Testing

  • Private Nachricht senden

17

03.06.2018, 22:20

Das hab ich mir auch gedacht.

Hast du eine Idee?


Auch wenn ich vorerst das Projekt anders builde würd mich die Lösung interessieren.
Werd damich auch sicher noch meine Kollegen nerven :vain:

dot

Supermoderator

Beiträge: 9 850

Wohnort: Graz

  • Private Nachricht senden

18

03.06.2018, 22:21

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

Strike

Frischling

  • »Strike« ist der Autor dieses Themas

Beiträge: 36

Wohnort: Wien 1200 und Techelsberg 9212

Beruf: Junior Software-Entwickler & Software Testing

  • Private Nachricht senden

19

04.06.2018, 19:26

Meine ursprüngliche Vorstellung...

Meine ursprüngliche Vorstellung war folgende:
"Ausgehend von dieser Sachlage"

Projectfolder
-----+-----CMakeLists.txt
-----+-----Game (folder)
-------------+-------CMakeLists.txt
-------------+-------Game.cpp
-------------+-------Game.h
-------------+-------main.cpp
-----+-----Weiteres Unterprojekt (folder)
-------------+-------CMakeLists.txt
-------------+-------SomeLogic.h
-------------+-------SomeLogic.cpp
-----+-----Builds (folder)
-------------+-------Build1 (folder - leer - bereit für Build)
-------------+-------Build2 (folder - leer - bereit für alternativen Build


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

Buildfolder
------+------Game (folder)
------+----------+------includes
------+----------+---------+------Game.h
------+----------+------sources
------+----------+---------+------Game.cpp
------+----------+---------+------main.cpp
------+------Weiteres Unterprojekt (folder)
------+----------+------includes
------+----------+---------+------SomeLogic.h
------+----------+------sources
------+----------+---------+------SomeLogic.cpp

Das wäre meine Vorstellung.
Danke für die genaue Nachfrage.
Ich habe mich am Anfang nicht gut genug ausgedrückt.

Thoran

Alter Hase

Beiträge: 512

Wohnort: Stuttgart

Beruf: Senior Software Engineer

  • Private Nachricht senden

20

04.06.2018, 21:13

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
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:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
TARGET_LINK_LIBRARIES(conserv iomessages Qt5::Core Qt5::Gui Qt5::Sql Qt5::Widgets Qt5::Network) 

#INSTALL target
INSTALL(TARGETS conserv 
        EXPORT conserv 
        RUNTIME DESTINATION "bin"
        LIBRARY DESTINATION "lib"
        ARCHIVE DESTINATION "lib")
INSTALL(EXPORT conserv DESTINATION "lib")
INSTALL(FILES ${H_FILES} 
              ${H_CLIENTS} 
              ${H_SERVERS} 
              ${H_VALIDATE}
          ${IFACE_FILES}
              DESTINATION "include")

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.
»Thoran« hat folgende Bilder angehängt:
  • install_cmake.png
  • lib_cmake.png
Mein Entwicklertagebuch
Aktuelles Projekt: Universum Espionage
Eingestellt:Spieleengine SilverCore
Organisator "Spieleentwickler Stammtisch Stuttgart"

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Thoran« (04.06.2018, 21:18)


Werbeanzeige