Jammer-Thread

[CodingCat]

Nachdem ich vor kurzem die Sources dreier ganze Qt-Bibliotheken (winmain, corelib, gui) in meinen Projektordner kopiert habe, um diese mit ordentlichen Einstellungen selbst kompilieren zu können, hätte ich die Sources heute gerne wieder rausgeworfen und nur die Projektdateien dort behalten. Visual Studio's User Macros hatten sich bis hierhin als enorm nützlich und konsequent implementiert erwiesen, ich bin in den Projektdateien tatsächlich alle absoluten Abhängigkeitspfade losgeworden. Warum also zum Schluss nicht auch noch die Source-Files im Projektordner loswerden und alle relativen Pfade durch $(MY_QT_SRC)<qt lib>\<relative path> ersetzen ...

Über die UI lassen sich für Source Files gar nicht erst Pfade mit Makros eintragen, alle Sonderzeichen werden sofort durch Escape-Sequenzen ersetzt. Trägt man in den Projektdateien direkt per Text-Editor Makropfade zu Source Files ein, kommt die IDE zwar insgesamt scheinbar problemlos damit klar, aber ausgerechnet die Custom-Build-Tool-Logik nicht. Qt ... war da nicht was mit diesem Pre-Compiler? Richtig, und das heißt, ich werde die Sources ums Verrecken nicht los. Nun enthält mein Projektordner also weiterhin zu über 90% Qt-Sources. :-[

[Schrompf]

Ich muss auch nochmal meckern.

Mein handgepflegtes Assimp-Projekt ist langsam mächtig veraltet - es knirscht nach geschätzt zweihundert Änderungen an der Verzeichnisstruktur langsam im Gebälk. Also habe ich gestern Nacht mal das vielgerühmte CMake ausprobiert, was ja jetzt angeblich unsere offizielle Build-Methode ist. Irgendwann früh um drei bin ich dann frustriert ins Bett, denn SO eine Grütze habe ich noch nicht gesehen:

- CMake ist unfähig, eine VS-Solution zu erzeugen, die gleichzeitig 32Bit- und 64Bit-Builds erzeugt
- CMake erzeugt Projekte, die das einfache Häkchen "Parallel Build" nicht gesetzt haben und daher schonmal ~8mal langsamer bauen.
- CMake hat anscheinend keine Ahnung von Precompiled Headers, weswegen nochmal Faktor 5 an Buildzeit hinzukommt
- CMake generiert ein Rudel nutzloser Dummy-Projekte für Install und so ein Ruß - lasst den Scheiß doch bitte auf Linux.
- CMake hat anscheinend einen Linux-spezifischen Header irgendwo bei mir entdeckt und konfiguriert deswegen zlib darauf, Huge File Support mit Linux-Funktionen zu probieren. Beim Kompilieren wird der Header dann natürlich nicht mehr gefunden.
- CMake hat keine Ahnung von VisualStudio-spezifischen Projekt-Einstellungen, weswegen die Assimp-DLL für alle Aufgaben gemessene drei Mal so lange braucht wie meine handgebaute Version vorher.
- CMake müllt alle Build Configs in allen Projekten mit manuellen Verzeichnissen zu, weswegen alle temporären Files bunt durch die Landschaft verstreut werden
- und man das nur sehr mühsam wieder rausholen kann, weil man durch ALLE Projektkonfigs durchmuss.
- CMake überschreibt manuell die Lib-Pfade, weswegen meine Einstellung des Ausgabe-Namens ignoriert wurde. Das Feature kannte ich noch nichtmal...
- CMake benannt alle DLLs aller Targets identisch, weswegen ich grad echte Probleme habe, eine 64Bit-Exe und eine 32Bit-Exe ins selbe Verzeichnis zu packen.
- und wenn man all diese Dummheiten dann korrigiert hat, stellt CMake über irgendein Skript fest, dass es gern alle Projektdateien neu generieren möchte, macht dann aber nur die Hälfte und reist bei der anschließenden Neulade-Orgie Visual Studio mit runter. All meine Einstellungen waren natürlich auch weg.

Das war dann der Punkt, wo ich ins Bett gegangen bin. Ab sofort wieder handgebaute Solutions. Es ist am Ende nämlich gar nicht so viel... deutlich weniger jedenfalls, als CMake zur Vernunft bringen zu wollen.

[Jonathan]

Ja, die ersten 5 mal, die man CMake benutzt, ist es die reinste Grütze. Aber mitlerweile finde ich es schon gut.
- 64 bit hab ich noch nie gemacht, kann man aber in der CMake List gewiss irgendwie einstellen
- Parallelbuild hab ich bei mir in den Vererbten User Projekteigenschaften, wodurch ich es bei eigenen Projekten nicht einstellen muss und und allen CMake Projekten immer habe
- PCHs: Ja, das ist ärgerlich. Es gibt wohl einen Workaround, aber der ist komisch und so
- Identische dll-Namen: Man kann so Postfixe setzen, zumindest ein D für Debug Versionen soltle mitlerweile drin sein. Wie es mit 32/64 bit aussieht weiß ich nicht, da ich damit nie etwas gemacht habe.

Ansich verwendest du CMake glaube ich etwas falsch. Die Philosophie davon ist nicht, dass man sich schöne VC Projekte generieren lässt, die man weitereditieren und auf anderen PCs benutzen kann, sondern dass man ein fertiges Buildsetup für diesen PC aufsetzt. Die Trennung finde ich dann auch sehr schick, man hat ein Source Verzeichnis, dann ein Verzeichnis mit den Projekten und den ganzen temporären Dateien und so, und dann das Install-Verzeichnis, wo der fertige Kram liegt. Das Projektverzeichnis ist zwar unordentlich, aber das soll man ja auch nicht anfassen. Nach dem Compilieren kann man dann das ganze Installieren, wodurch man einen sauberen Ordner nur mit den Header, Bibliotheksdateien und dll's erhält, den man dann für seine Projekte weiter benutzen kann. Von daher finde ich dieses Install-Target recht nützlich.
Ich würde auch gar nicht versuchen, generierte Projektdateien irgendwie zu editieren. Die haben meist haufenweise absolute Pfade und so drin, wenn man etwas ändern möchte, sollte man das in der CMake-List machen und dann das Projekt neu generieren.

Es wäre natürlich schön, wenn CMake saubere Projektdateien generieren würde, die man dann auch weiterbenutzen kann, aber so ist wohl einfach die Philosophie nicht. Andererseits sind die Projekteinstellungen in VC durch die unendlich langen Menüs die teilweise einfach nur albern umständlich programmiert sind, sehr mühsam. Sobald man CMake kann, sieht man in seinen CMake-Dateien recht übersichtlich, was wo wie konfiguriert ist. In VC ist es mir wie oft passiert, dass ich Libs z.B: nur im Debugbuild gelinkt habe, weil ich beim einstellen wieder nicht "alle Konfigurationen" angegeben habe. In CMake geht das wesentlich einfacher und schmerzfreier.

Also: Wenn man CMake benutzt, sollte man sich ausführlich damit befassen, ich kenne keinen, der es Anfangs nicht gehasst hat. Aber wenn man einmal drin ist, ist es irgendwie ganz cool, besonders wenn man mal fix auf einem anderen Rechner oder gar Linux kompilieren möchte.

[Schrompf]

Für Multiplattform-Betrieb gibt es auch kaum Optionen zu CMake, glaube ich. Und dass die Projektfiles nicht zum Bearbeiten gedacht sind, wird einem an jeder Ecke entgegengeschrien. Ich war halt einfach richtig richtig stinkig gestern - CMake hat einen einfachen Auftrag mal eben um drei Stunden Kampf erweitert, bei so kleinen Aufträgen schiebt mich das viel zu sehr in Richtung "hat sich nicht gelohnt". Da hab ich mir mal die Freiheit genommen, mir meinen Frust von der Seele zu jammern :-)

Ich werde mich langfristig wohl mal mit CMake beschäftigen müssen.

[j.klugmann]

QMake ist auch noch ganz okay, vor allem etwas einfacher.

[Jonathan]

Ich war halt einfach richtig richtig stinkig gestern - CMake hat einen einfachen Auftrag mal eben um drei Stunden Kampf erweitert, bei so kleinen Aufträgen schiebt mich das viel zu sehr in Richtung "hat sich nicht gelohnt". Da hab ich mir mal die Freiheit genommen, mir meinen Frust von der Seele zu jammern :-)

Oh ja. Ich hatte das Glück, mich als studentische Hilfskraft mit CMake beschäftigen zu müssen. Wenn ich da 3 Stunden nach einem Fehler gesucht habe, war ich sehr viel entspannter, weil ich genau so dafür bezahlt werde, als hätte es nach 5 Minuten geklappt und ich noch 2:55 was anderes gemacht hätte. Bezahlt zu werden macht Fehlersuche echt sehr viel entspannter :)

[dot]

Ich werde mich langfristig wohl mal mit CMake beschäftigen müssen.

Ich weiß nicht. Also ich hab zwangsweise doch regelmäßig mit CMake zu tun, aber ich bin alles andere als begeistert davon.

Imo ist CMake gut gemeint, aber rein von der Idee her ein komplett falscher Ansatz.

Auf verschiedenen Plattformen hab ich nunmal völlig verschiedene Toolchains. Und das bedeutet, dass der Buildprozess eines nichttrivialen Projektes auf unterschiedlichen Plattformen naturgemäß auch sehr unterschiedlich aussehen wird.
CMake versucht nun, all dies zu abstrahieren und das ist imo einfach rein prinzipiell weder vernünftig möglich noch sinnvoll.
Denn was am Ende rauskommt ist, dass man die CMake Skripte erst wieder speziell für jede Plattform anpassen muss. Und bevor ich was Builden kann, darf ich erstmal hunderte Variablen setzen damit überhaupt irgendwas funktioniert. Und das natürlich auf jedem Rechner wieder aufs Neue.

Praktisch jedes CMake Projekt das ich kenne ist übersät mit if (WIN32) etc.
Und das ist doch eigentlich nichts anderes wie ein dynamic_cast. Es zeigt deutlich, dass hier falsch abstrahiert wurde.
Denn eigentlich will ich doch die Toolchain der jeweiligen Plattform optimal nutzen. Aber bevor ich das kann, muss ich mich unter CMake erstmal mühsam durch die Abstraktion hacken, die mir dabei im Weg ist. Und bezahlen tu ich das mit dem letzten Bisschen an theoretisch vielleicht noch vorstellbarer Portabilität.
Und Selbst wenn meine Arme dann nun endlich durch die Gitterstäbe des CMake Käfig passen, kann ich mich doch nie ganz daraus befreien.
Denn nun hab ich CMake zwar dazu gebracht, mir mein plattformspezifisches Buildsystem in etwa so zu generieren wie ich es haben will, aber trotzdem kann ich meine Toolchain nicht direkt verwenden. Denn was einmal aus CMake rauskommt, geht nie wieder dorthin zurück.
Und so wird ein geniales Visual Studio zum Texteditor mit eingebautem Debugger verkrüppelt.
Da frag ich mich dann schon was all der Aufwand eigentlich bringen soll.

CMake ist vielleicht wirklich als Paradies erdacht worden. Aber in einer Welt in der verbotene Äpfel das einzige sind, was es zu essen gibt, ist so ein Paradies eben nicht unbedingt sinnvoll.
CMake hat mir noch nie Arbeit erspart, ganz im Gegenteil.

Imo ist es sinnvoller, einfach auf jeder Plattform direkt das native Buildsystem zu benutzen.

[simbad]

Ich übersetze viel Software für meine Linux-Rechner selbst. Benutze also abgesehen von der Basisinstallation kein Paketmanagement. Dabei stolpert man immer wieder mal über Software, die mit CMake gebaut wird. Es funktioniert selten Problemlos. Da ist der Weg über configure/make/make install zuverlässiger.

Weil ich gerne alles selbst baue, habe ich mir einen recht gut ausgestatteten Abstraction-Layer für meinen C++ Code gebaut.
Dabei habe ich für Linux und für Windows absolut identische Verzeichnisstrukturen. Wenn das Projekt aus dem Repository kommt ist immer der komplette Code vorhanden.
Dann habe ich ein hierarchisches Makefile-System bei dem ich im Top-Level directory nur make eingebe, wie man das so unter Linux kennt, und ein Solution-File fürs devstudio-2003 und eins für devstudio-2008. Dazugehörend die vc-project files. Eigentlich alles wie man sich das wünscht.

Die Paket-Organisation mache ich mit einem UML-Tool und einem von mir selbst geschriebenen Code-Generator. Weder die Makefiles noch die Solution/Project Files werden von mir nachbearbeitet. Ich benutze sie und bin eigentlich nicht unzufrieden mit dem Ergebnis.

Vielleicht gibt es eine Komplexität, die sich damit nicht mehr regeln lässt, aber ich wüsste nicht, warum das nicht gehen sollte. Der Schlüssel zu dem ganzen ist eben die Strukturierung der Pakete. Wenn man da ein paar Regeln einhält, dann geht das auch.

[kimmi]

CMake ist ganz sicher nicht die Antwort auf das Problem der verschiedenen Build-Umgebungen. Allerdings löst es einige Probleme hier Iim Job sehr zuverlässig wie zum Beispiel den Umgang mit VS2003, 2008, 2010, Eclipse und das Erstellen von Makes für Linux. Allerdings ist dafür definitiv der Schlüssel eine sinnvolle Strukturierung.
Und man kann durch die Abstraktion in einigen CMake-Files Zeit sparen. Man kann sich auch vollkommen verfransen. Das Pflegen von mehreren unterschiedlichen Make-Umgebungen hat mir immer mehr Aufwand gemacht als CMake. Aber das ist meine Meinung bzw. Erfahrung :).

Gruß Kimmi

[Lynxeye]

Ganz einfache Lösung: seht euch das oder besser die Buildsysteme für Mesa3D an. Wenn ihr das gesehen habt, kommt euch alles andere wie ein Geschenk des Himmels vor.

[dot]

CMake ist ganz sicher nicht die Antwort auf das Problem der verschiedenen Build-Umgebungen. Allerdings löst es einige Probleme hier Iim Job sehr zuverlässig wie zum Beispiel den Umgang mit VS2003, 2008, 2010, Eclipse und das Erstellen von Makes für Linux.

Inwiefern? Ich finde die Tatsache dass CMake 50% meiner IDE wegsprengt ist eigentlich der Dealbreaker schlechthin...

[Aramis]

Ggf. sollte man CMake nur als Fallback sehen um mehr Plattformen bedienen zu koennen (oder veraltete VS-Versionen …).

Fuer die relevanten Plattformen kann man ja handgepflegte Makefiles/Solutions verwenden. So haben wir es bislang bei Assimp gehalten, Thomas' Erfahrungen bringen mich drauf dass es so vielleicht gar nicht so schlecht war.

[Jonathan]

Also ich muss sagen, ich finde die Projekteinstellungen in VC wirklich nicht schön. Zum Beispiel um zu Linkende Bibliotheken anzugeben: Rechtsklick auf Projekt, Klick auf Eigenschaften, Klick auf Linker, Klick auf Eingabe, bei Konfiguration 2 mal Klicken um 'für alle' auszuwählen, dann auf 'zusätzliche Abhängigkeiten' klicken, damit rechts dieser Pfeil erscheint, den anklicken, auf bearbeiten klicken und ENDLICH hab ich die Liste der gelinkten Bibliotheken. In Textform untereinander, so wie ich es in der CMake Datei direkt habe. Ach und wenn man Debug und Release Libs getrennt einstellen will, muss man noch mehr klicken, in CMake sagt man einfach ${ASSIMP_LIBS} oder so und hat dann automatisch die passenden Debug/Release Libs.
Und ja, in CMake muss man vorher eventuell viele Pfade eintippen. Aber bei VC muss man genauso die Standardverzeichnisse für Bibliotheken setzen. Und wenn man in CMake schön mit Pfadvariablen arbeitet, muss man jede installierte Lib auch nur einmal einrichten und CMake findet fortan alles alleine.

Ich hab in meinen CMake-Dateien auch noch nie ein if(WIN32) benutzt. Ich weiß ja nicht, was ihr so für Projekte habt, aber 'normale' OpenGL oder Qt Projekte liefen immer ohne Anpassung auf mehreren Plattformen direkt. Und auch so Dinge wie Abhängigkeiten mehrere Projekte (Lib aus einem Projekt in anderem automatisch Linken) gehen sehr einfach. Oder Qt-Moccing (Ich habe bis heute im VC Addin keinen Knopf gefunden, eine Datei zu mocken. Das ist imemr nur in durch Wizard erstellten Dateien voreingestellt, oder ich muss komplizierte Custom BUildsteps anpassen. In CMake muss ich die Datei nur in eine Liste eintragen...)

Auch wenn die genereiten Projektdateien nicht sehr schön sind, finde ich die Konfiguration über CMake mittlerweile einfacher und übersichtlicher. Natürlich ist CMake auch nur eine Programmiersprache und in jeder Sprache kann man sehr schlechte Programme schreiben, aber meine finde ich recht übersichtlich und ansehnlich und komme gut damit zurecht. Wenn man die nötige Erfahrung hat, natürlich, weil CMake schon ne Zicke ist.

Viel schlimemr finde ich eigentlich die Tatsache, dass C++ überhaupt so komplizierte Buildsysteme braucht. Ist eine Programmiersprache um eine Programmiersprache zu übersetzen nicht irgendwie ein Designfehler? Aber gut, das wird sich wohl nicht mehr ändern.

[Schrompf]

Das C++-Modulsystem... da war ja was vorgesehen, aber soll es erst in einen späteren TR schaffen. Hoffen wir mal das beste. Zumal bei einer öffentlich genutzten Lib wie Assimp das Geschrei sehr groß wäre, wenn man sich auf ein extrem junges Features verlassen würde. Meine unbedachte Nutzung von C++11-Merkmalen hat ja auch zu besorgten Nachfragen geführt.

Hier im Assimp-Fall löst CMake also zumindest das Problem des Bauens auf allen Plattformen. Das ist was wert. Von daher will ich mich gar nicht zu laut beschweren. Nur dass die für VC generierten Solutions halt vor absoluten Pfaden triefen, der Code unglaublich lahm kompiliert und der Ergebnis-Code dann noch ein Drittel so schnell ist, wie er sein könnte, kann man ihm durchaus zum Vorwurf machen. Die paar Häkchen bei LTGC und Konsorten zu setzen kann nicht das Problem sein.

[RustySpoon]

Ich hab mich die letzten Monate auch durch diverse Buildsysteme geackert und so richtig glücklich bin ich nirgends geworden.

Primär hab ich das Problem, dass ich hier mit furchtbar heterogenen System zutun hab. Meine Welt besteht leider nicht nur aus ein paar C++-Sourcen, die der Reihe nach gebaut und gelinkt werden müssen. Ich hatte hier mal 'nen Job in einem Projekt, welches aus einigen 100k Zeilen Prolog-Code bestand, mit C-Modulen, C++-Binaries, diversen Interfaces für Java und Co und einem Stoß Skripte verschiedener Sprachen.

In meiner Diplomarbeit möchte ich z.B. gern die Latex-Sourcen, Tikz-Bildchen, Statistik-Plots und Tabellen elegant und "sinnvoll" bauen. Da kommen auch schon wieder mindestens die (per se schon krüpplige) Latex-Kompiliererei, Ruby und R zusammen. Mal davon abgesehen, dass man das beliebig weiter treiben kann, wenn Daten auch einfach mal automatisiert neu generiert werden sollen.

Also hätt' ich einerseits gern ein regelbasiertes System á la Make, weil mir der ganze andere Kram irgendwie nicht flexibel genug ist, andererseits aber auch gern eine mächtige Skriptsprache um das ganze irgendwie halbwegs elegant und effizient ausformulieren zu können. Letztendlich bin ich gerade bei Ruby und Rake gelandet und bis dato zumindest ganz glücklich damit.

[kimmi]

Ich hab mal Python, F77, c, c++ und Doxygen per Buildsystem auf verschiedenen Plattformen beackern dürfen. Für Windows gab es da ein auf cygwin basierendern Ansatz, der mehr schlecht als recht tat. Ansonsten spezielle Makes, die die jeweilige Plattform abzudecken versuchten. das war auch nicht immer alles Gold.
Automake und Konsorten hatte ich auch mal in den Fingern und brach sie mir mehr als einmal pro Stunde. Buildsysteme sind halt komplex und sehr sehr plattform-spezifisch :).
Bauen bleibt komplex, egal womit. Und von meinem Standpunkt aus sollte man die Tools wählen, die einem behagen. ich mag halt CMake und habe damit weniger Probleme als mit VC, make, scons und wie die alle heißen.

@dot: vielleicht solltest du IDE wegsprengen etwas detailierter ausführen :).
@Schrompf: Dass das alles so langsam ist, liegt eher an meinen mangelnden Kenntnissen von CMake, glaube ich :).

Gruß Kimmi

[Chromanoid]

Hat jemand eigentlich mal Maven für C++ ausprobiert? In Java bin ich mittlerweile ziemlich begeistert davon. Allerdings weiß ich nicht inwieweit da der Support für ausgebaut ist. Ich hab nur mal vom http://duns.github.com/maven-nar-plugin/ maven nar plugin gehört, allerdings scheint mir das nicht mehr aktualisiert zu werden oder es ist stable wer weiß ^^.

[antisteo]

Ganz einfache Lösung: seht euch das oder besser die Buildsysteme für Mesa3D an. Wenn ihr das gesehen habt, kommt euch alles andere wie ein Geschenk des Himmels vor.

Wieso? ich mach einfach

Code: Alles auswählen

./autogen.sh --prefix=$prefix --with-dri-drivers= --with-x --enable-debug \
 --with-gallium-drivers=r600,swrast --enable-shared-glapi\
 --enable-egl --with-egl-platforms=x11,drm \
 --enable-texture-float --enable-gallium \
 --enable-gles2 --enable-gles1 --enable-gallium-llvm \
 --with-dri-searchpath=$prefix/lib/dri
make -j4
make install

Naja, die Methode mit 'ner autogen.sh ist irgendwie Standard.

[Lynxeye]

Ganz einfache Lösung: seht euch das oder besser die Buildsysteme für Mesa3D an. Wenn ihr das gesehen habt, kommt euch alles andere wie ein Geschenk des Himmels vor.

Wieso? ich mach einfach

Code: Alles auswählen

./autogen.sh --prefix=$prefix --with-dri-drivers= --with-x --enable-debug \
 --with-gallium-drivers=r600,swrast --enable-shared-glapi\
 --enable-egl --with-egl-platforms=x11,drm \
 --enable-texture-float --enable-gallium \
 --enable-gles2 --enable-gles1 --enable-gallium-llvm \
 --with-dri-searchpath=$prefix/lib/dri
make -j4
make install

Naja, die Methode mit 'ner autogen.sh ist irgendwie Standard.

Du folgst der Mesa Entwicklung? Hast du öfters mal verschiedene Konfigurationen nach dem 8.0 Release gebaut? Dort kann man sehr schön sehen, dass selbst ein Buildsystem nach Jahren der inkrementellen Weiterentwicklung selbst bei trivialsten Änderungen zusammenbrechen kann. Abgesehen davon, dass Mesa drei verschiedene Buildsysteme hat, welche bei Änderungen synchron gehalten werden müssen. Meistens verwenden die jeweiligen Entwickler aber nur eines der Systeme und ändern dann die anderen beiden Systeme immer nur oberflächlich und ohne größeres Testen, was zusammen mit der eingangs erwähnten Problematik sehr oft zu Problemen führt.

Das ganze ist ein Kartenhaus, da ist ein nicht standardmäßig aktivierter paralleler Build einfach ein Luxusproblem dagegen. Und jetzt komm nicht mit "make -jX" löst das Ganze sowieso ohne im Buildsystem verankert zu sein: ich hatte mit Mesa schon sehr obskure Buildfehler bei parallelen Builds, weil das Dependancytracking nicht funktioniert hat. (Fällt natürlich erst auf, wenn man mit mehr als 6 Kernen gleichzeitig baut)

[dot]

Also ich muss sagen, ich finde die Projekteinstellungen in VC wirklich nicht schön. Zum Beispiel um zu Linkende Bibliotheken anzugeben: Rechtsklick auf Projekt, Klick auf Eigenschaften, Klick auf Linker, Klick auf Eingabe, bei Konfiguration 2 mal Klicken um 'für alle' auszuwählen, dann auf 'zusätzliche Abhängigkeiten' klicken, damit rechts dieser Pfeil erscheint, den anklicken, auf bearbeiten klicken und ENDLICH hab ich die Liste der gelinkten Bibliotheken.

Oder wenn man's richtig macht: Property Sheets > Add Property Sheet > vorbereitetes Property Sheet für die jeweilige lib auswählen > fertig. Und zwar gleich für alle möglichen Plattformen und Build Configs. Und ganz ohne irgendwelche globalen Pfade oder Env Vars zu verpesten :)

Und ja, in CMake muss man vorher eventuell viele Pfade eintippen. Aber bei VC muss man genauso die Standardverzeichnisse für Bibliotheken setzen. Und wenn man in CMake schön mit Pfadvariablen arbeitet, muss man jede installierte Lib auch nur einmal einrichten und CMake findet fortan alles alleine.

Siehe oben. Die Standardpfade sind bei mir immer noch so wie sie's direkt nach der Installation von VS waren ;)

Ich hab in meinen CMake-Dateien auch noch nie ein if(WIN32) benutzt. Ich weiß ja nicht, was ihr so für Projekte habt, aber 'normale' OpenGL oder Qt Projekte liefen immer ohne Anpassung auf mehreren Plattformen direkt.

Ja, wie gesagt, für triviale Projekte funktioniert's.
Aber ich will z.B. üblicherweise Shader in meine Binaries integrieren. Dazu hab ich mir für Windows fxc in MSBuild und Visual Studio integriert. Sobald ich eine .hlsl Datei zu meinem VS Projekt hinzufüge, wird die automatisch gebaut, die resultierenden Shaderbinaries in ein obj gepackt, ein Header dazu generiert und das obj zur exe gelinked. Natürlich komplett mit Dependency Tracking und Incremental Build. Abgesehen davon kann ich ganz bequem an den Compilerswitches drehen.
Unter Linux muss ich stattdessen leider OpenGL verwenden. Da ich GLSL nicht vorkompilieren kann, werde ich, vermutlich per Linkscript den Shader Source in mein Binary packen.
Builds von komplexeren Projekten sind einfach notwendigerweise nicht 100% Plattformunabhängig. Und dann wird CMake meiner Erfahrung nach zur Qual.

Viel schlimemr finde ich eigentlich die Tatsache, dass C++ überhaupt so komplizierte Buildsysteme braucht. Ist eine Programmiersprache um eine Programmiersprache zu übersetzen nicht irgendwie ein Designfehler? Aber gut, das wird sich wohl nicht mehr ändern.

Ehrlich gesagt find ich den C++ Buildprozess nicht schlecht. Wenn auch etwas komplex, so ist er doch, passend zur Sprache, sehr sehr mächtig.

Die paar Häkchen bei LTGC und Konsorten zu setzen kann nicht das Problem sein.

Ist es auch nicht.
if (WIN32) ... ;)

@dot: vielleicht solltest du IDE wegsprengen etwas detailierter ausführen :).

Die Konfiguration und Steuerung des Buildsystems ist für mich essentielles Feature einer IDE. Sobald ich CMake verwende kann ich das nichtmehr über meine IDE erledigen.
Ich hab z.B. sehr oft mit Projekten zu tun, die auf CUDA bauen und um der "Portabilität" willen CMake verwenden. Selbst wenn ich nur eine neue .cu Datei zu meinem Projekt hinzufügen will -> IDE schließen, CMake Skript anpassen, Buildsystem neu generieren, im Idealfall hat alles gleich geklappt, IDE neu starten. Und es gibt kaum etwas anstregenderes als jedesmal, wenn man nur schnell schaun will wie irgendwelche Compilerflags sich auf die Performance auswirken, die IDE zu schließen, das CMake Skript anzupassen, neues Buildsystem generieren, IDE neu starten, Rebuild, nach 10min merken dass der Build kaputt is, zurück zum Start, ...

[kimmi]

Öhm, du mußt nicht die IDE schließen, wenn du etwas am CMake Script anpasst. Zumindest unter VS gibt es da ein Plugin, dass die Project-Dateien ohne Restart aktualisiert.

Gruß Kimmi

[dot]

Öhm, du mußt nicht die IDE schließen, wenn du etwas am CMake Script anpasst. Zumindest unter VS gibt es da ein Plugin, dass die Project-Dateien ohne Restart aktualisiert.

In der Theorie. In der Praxis ist dieses Plugin auf allen Rechnern auf denen ich zu tun hab völlig unbenutzbar weil es, nachdem ich die 100 Messageboxen weggeklicked hab, ständig mal festfriert und die IDE blockiert...

[kimmi]

Hm, dann hast du definitiv andere Installationen als ich, mal die Logs gecheckt? Aber sei es drum. Jedem das seine!

Gruß Kimmi

[Krishty]

Ich habe vorhin meinen Rechner aus dem Energiesparmodus geweckt, mich aber nicht angemeldet und bin duschen gegangen. Als ich wiederkomme wundere ich mich, warum die ganzen Flash-Videos laufen und merke, dass alle nicht gespeicherten Daten weg sind.

Der Countdown zum automatischen Neustart zwecks Windows-Aktualisierung lief während ich nicht angemeldet war. Da der Restart Manager nach dem Neustart fast alle Anwendungen (Browser, Visual Studio, usw.) exakt so wiederhergestellt hat, wie ich sie vor dem Energiesparmodus verlassen hatte, habe ich erst garnicht begriffen, dass die Kiste neugestartet wurde.

So eine Scheiße.

[Schrompf]

Collada hat mich wieder. Ich hätte mir schon Sorgen machen sollen, als dieser gewisse Assimp-Klient "a couple of hundred dollars" für eine "kleine" Änderung bezahlen wollte. Und damit exakt 200$ meinte, obwohl er vorher noch schrieb "name your price." Und jetzt sitze ich inzwischen den dritten Tag an diesem Job und jage Kleinst-Warnungen im Collada-Exporter, weil dieser Typ nicht begreift, dass die Collada-Spec zu vielfältig ist, um wirklich *jeden* Loader warnungsfrei zu kriegen. Nebenbei nimmt er auch noch Worte in den Mund wie "yet another Microsoft virus", die ich von erwachsenen Menschen so eigentlich nicht mehr erwartet hätte. Es geht um eine ganz banale Runtime. Im nächsten Satz sagt er schon, dass er sonst immer die MinGW-Runtime beilegt. Es ist zum Kotzen.

Im Nachhinein betrachtet hätte ich eigentlich auch am Anfang drauf kommen können. Niemand betraut einen produktiven Mitarbeiter mit Externen-Pflege, weil die alle was Richtiges zu tun haben. Solche Jobs schiebt man nur an Leute, die in der Hauptentwicklung mehr Schaden als Nutzen anrichten.

[Jonathan]

Ich wollte eigentlich nur mit Assimp ein Modell aus Venetica laden, dass ich mit dem OgreXMLConverter in eine xml Datei umgewandelt hat. Gut, die Änderungen an der Vertexstruktur gegenüber den Dateien aus dem Blender XML-Exporter sind noch zu verschmerzen, aber jetzt stell ich fest, dass die Materialdateien komplett anders aufgebaut sind? Na klasse.

[kimmi]

Januar bestand aus 2 Wochen spannender Nebenhöhlen-Entzündung, danach der 24-Stunden-Darm-Virus und nun habe ich einen Schnupfen. Vor so etwas warnt einem keiner, wenn man Eltern bzw. Vater wird.

Gruß Kimmi

[CodingCat]

Wenn Reflection zuschlägt.

Code: Alles auswählen

return lean::any_value<RenderableMaterial*>(
	sceneParameters.Renderer->RenderableMaterials()->GetMaterial(
		sceneParameters.ResourceManager->MaterialCache()->GetMaterial(
			creationParameters.GetValueChecked<beGraphics::Effect*>("Effect"),
			creationParameters.GetValueChecked<beCore::Exchange::utf8_string>("Name")
		)
	)
);

[j.klugmann]

Meine Engine hatte ich anfangs nur unter Linux entwickelt und das kleine Detail vergessen, dass msvc noch keine variadischen Templates unterstützt. Resultat ist, dass ich wohl die kompletten Reflections nochmal neubauen muss. -.-

[CodingCat]

Ich glaub mich verreißts. Nicht nur, dass sie in VS 2011 über Jahre exzellent erkennbare Icons zu unkenntlichen monochromatischen "Glyphen" entstellt haben. Nein, sie haben neben der Farbe auch gleich noch den Kontrast abgeschafft. Dagegen war jede Windows-95-Oberfläche Hochglanz.