Assimp - Brainstorming zum Release

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Einen hab ich auch noch:
  • - Prototyp vom Q3-Loader aus ZFXCE nach AssImp.
Gruß Kimmi
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Die letzteren beiden wird's aber wohl nicht geben. Dazu hab ich einfach so schon zu viel um die Ohren. Nur leider wären das zwei recht wichtige Formate.
Ja, dann werde ich mir Milkshape, deine Zustimmung vorrausgesetzt, in naher Zukunft mal angehen. Die Spezifikation des Formats sieht ja eigentlich so aus, als sei es recht einfach in unsere Datenstrukturen konvertierbar. Einzig bei den Animationen gibt es Unterschiede, so ganz steige ich aktuell noch nicht durch.

Von mir noch:
  • Testsuite - hab ich letztes WE erstmals wieder dran weitergemacht ... grade in Bezug auf diese ganzen unvermeidbaren Regressionen (siehe Obj) wird es wohl recht nützlich werden.
  • Subdivision im AC-Loader
  • Java/C#-Bindings: zusammen mit Jonathan herausfinden ob SWIG uns die Arbeit und die spätere Codepflege abnehmen kann.
  • (für's erste auf 'nach unserem Release, in welchem Jahrzehnt dieses auch stattfinden mag' verlegt): .blend-Support.
  • ... viele, viele Kleinigkeiten an einzelnen Loadern. Da hab ich in letzter Zeit mal so sporadisch was gefixt.
PS: *lechz* nach Q3-Maps.
Benutzeravatar
dowhilefor
Moderator
Beiträge: 173
Registriert: 27.02.2009, 15:44
Alter Benutzername: 6SidedDice
Echter Name: Nico Probst
Wohnort: Bochum
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von dowhilefor »

Ja, dann werde ich mir Milkshape, deine Zustimmung vorrausgesetzt, in naher Zukunft mal angehen. Die Spezifikation des Formats sieht ja eigentlich so aus, als sei es recht einfach in unsere Datenstrukturen konvertierbar. Einzig bei den Animationen gibt es Unterschiede, so ganz steige ich aktuell noch nicht durch.
Ich hätte noch sehr sehr seeeehr schlechten Milkshape Code zur Verfügung ... Meine auch mit Animation. Wobei der zum größtenteil auf dem Code aufbaut den im alten Forum jemand mal in seiner Terrain Demo benutzt hat (wer war das nochmal *grübel*). Den würde ich aber zur Verfügung stellen, damit du vielleicht einen Einstieg hast, falls dir das hilft.
Mein Gehirn besteht nur noch aus einem hash-index, ich weiss was ich kenn aber kenn nicht was ich weiss
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Wo kann man eigentlich mehr Zeit kaufen ;)...
Habe ich erwähnt, daß die ZFXCE nun die AssImp benutzt?

Kimmi
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Nein, hast du bislang noch nicht erwähnt. Schöne Sache!
Ich hätte noch sehr sehr seeeehr schlechten Milkshape Code zur Verfügung ... Meine auch mit Animation. Wobei der zum größtenteil auf dem Code aufbaut den im alten Forum jemand mal in seiner Terrain Demo benutzt hat (wer war das nochmal *grübel*). Den würde ich aber zur Verfügung stellen, damit du vielleicht einen Einstieg hast, falls dir das hilft.
Das wäre super, insbesondere falls tatsächlich Animationen enthalten sind. Ich finde zwar brauchbare Spezifikationen/Header, aber ganz eindeutig sind die nicht. Etwas Referenzcode sollte als kräftig Trial&Error einsparen :-)
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

So, ich habe mal einen ersten Versuch in Richtung make install committet und auch gleich die ersten Fehlermeldungen bekommen. Ich korrigiere die bzw. werde das Makefile, daß uns auf der Mailingliste angeboten wurde, versuchen zu adaptieren.
Dazu habe ich eine Lösung für die berichteten Probleme mit den Materialien geliefert. Ich werde den aber noch aufhüpschen. Dann dachte ich daran, den BSP-Loader mal klarzumachen und den CMake mit einem Install-Target zu versehen.
Und der Schnee hier oben im Norden geht mir langsam auf den Geist. Ich hab heute 35 Minuten ins Büro gebraucht ( sonst unter 15 Minuten mit dem Rad ). Ich will Frühling!

Gruß Kimmi
Benutzeravatar
Jonathan
Establishment
Beiträge: 2353
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Jonathan »

Weiß grad nicht ob es schonmal vorgeschlagen wurde. Aber was haltet ihr von einem Wechsel Svn->git?
Imo sollte es möglich sein, die komplette History zu übernhemen und so.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf »

Wenn Sourceforge das unterstützt? Ich hab kein Problem mit SVN, ich hätte es also allein aus Mangel an echten Ärgernissen beibehalten.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Git wird unterstützt. Wir haben das mal bei der ZFXCE probiert und sind dabeigeblieben. Allerdings bin ich mit dem TortoiseGit noch nicht ganz so zufrieden. Es ist auf jeden Fall schneller als svn und man kann lokal seine Modifikationen überarbeiten. Der Merge ist ebenfalls einfacher. UNd man hat das gesamte Repo lokal bei sich vorliegen, also auch ohne Sourceforge kann man diffen etc. . Es dauerte allerdings einige Zeit, bis ich da einigermaßen reingekommen bin.
Allerdings stellt sich auch bei mir die Frage: wollen wir dazu wechseln? So richtig viele Vorteile fallen mir da gerade nicht ein. Für unsere Bedürfnisse reicht doch svn erst einmal aus.

Gruß Kimmi
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Eine Stimme gegen einen Wechsel. Wir nutzen SourceForge doch als Server mit uns als Clients - genau der Zweck, für den SVN konzipiert ist. Dass Git und Mercurial gewisse Vorteile für verteilte Entwicklerteams sowieso Projekte mit vielen parallel laufenden Branches aufweisen steht außer Frage. Jetzt aber noch zu wechseln nachdem wir alle User schon dazu verdonnern sich für aktuelle Versionen den Quelltext aus dem Repos zu ziehen? Man sollte nicht vergessen dass Subversion immer noch deutlich verbreiteter ist.

Übrigens hab ich vor einiger Zeit mal einen Mercurial-Clone von Assimp auf Bitbucket erstellt (aktuell nutze ich Mercurial für alle privaten Projekte). Seit 3xx aber nicht mehr aktualisiert. Einen solchen Clone könnte man auch für Git-User auf Gitourious oder GitHub hosten - wenn sich ein Maintainer findet, der regelmäßig aktualisiert.
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

Aramis hat geschrieben:Einen solchen Clone könnte man auch für Git-User auf Gitourious oder GitHub hosten - wenn sich ein Maintainer findet, der regelmäßig aktualisiert.
Mein persönlicher Git-Clone auf GitHub: http://github.com/klickverbot/assimp. Ich aktualisiere das Repository per Hand, deswegen ist es meist nicht am allerneuesten Stand, aber als Ausgangsbasis (um für eine vollständige History nicht alle alten Revisionen importieren zu müssen) sollte es durchaus taugen.

Ich würde übrigens vorerst auch nicht wechseln, SVN ist ja derzeit so etwas wie der kleinste gemeinsame Nenner in der Open-Source-Welt: Die Entwicklung findet (zumindest bis dato) vollständig in der Mainline statt, also legt einem SVN nicht übertrieben viele Steine in den Weg, und als »Frontend« verwenden wahrscheinlich ohnehin viele Entwickler ihr DVCS der Wahl (was in meinem Fall mit git-svn auch recht komfortabel von der Hand geht).
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

So, ich hab mal etwas .. aufgeräumt. Assimp kompiliert jetzt mit GCC4.4 auf -wall mit nur noch einer Warnung. Die Änderungen waren überschaubar, betrafen aber fast alle Loader. Solltet ihr in nächster Zeit merkwürdige Regressionen entdecken, so prüft bitte ob es in r541 evtl. unbeabsichtigte Verhaltensänderungen am jwlg. Loader gab.

Hinzu kam gestern noch ein Patch um Assimp's Abschneiden bei VC2010's statischer Codeanalyse zu verbessern (dafür an dieser Stelle nochmals vielen Dank an Krishty!).

Loader für statische Milkshape-Files steht, Animationen stehen noch aus.
EDIT - Aktueller MS3D Prototyp auch gleich eingecheckt.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

klickverbot -

kann ich deinen Git-Clone von der Assimp-Seite aus verlinken?
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

Aramis hat geschrieben:kann ich deinen Git-Clone von der Assimp-Seite aus verlinken?
Verlinken kannst du den Clone natürlich gerne, auch wenn ich nicht versprechen kann, dass ich ihn in Zukunft stets aktuell halten werde.

Vor dem Release sollten wir unbedingt noch einen Anlauf unternehmen, das »aiGetMaterialProperty«-Problem zu lösen – da es für SOs ja keine Import-Libraries wie für DLLs unter Windows gibt, die das Problem gewissermaßen maskieren (korrigiert mich bitte, wenn ich die Lage nicht richtig erfasst haben sollte), ist es derzeit schwierig bis unmöglich, Assimp unter Linux als dynamische Bibliothek zu verwenden. Zumindest hat ein schneller Versuch vor ein paar Tagen nicht so funktioniert, wie er sollte – ich habe aber zugegebenermaßen nicht viel Zeit in eine mögliche Lösung des Problems investiert.

Aus meiner Sicht ebenfalls wünschenswert und für ein »richtiges« Release wohl bitter nötig ist »make install«-Unterstützung für CMake unter *nix, das ja jetzt unsere Standard-Build-Methode ist, das sollte aber nicht besonders schwer umzusetzen sein. Ich werde mich dessen in den nächsten Tagen annehmen.

Mit SWIG (siehe oben) habe ich mich mittlerweile schon etwas intensiver auseinandergesetzt und sogar ein mehr oder weniger komplettes D-Backend geschrieben, meine Versuche, es auf Assimp loszulassen waren aber leider wenig erfolgversprechend. Die Pointer-in-den-Speicher-samt-Längenangabe-API verträgt sich wohl nicht so gut mit der Herangehensweise von SWIG – ich lasse mich aber gerne eines Besseren belehren.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Der Blocker der Shared-Object-Version hängt mit aiGetMaterialProperty zusammen, habe ich das richtig verstanden?

Gruß Kimmi
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

Ja, damit, dass das Symbol aus irgendeinem Grund mit C++-Name-Mangling exportiert wird, und zwar sowohl unter Windows/MSVC als auch unter Linux/GCC, wenn ich den letzten Stand der Dinge richtig im Kopf habe. Diese Tatsache ist aus meiner Sicht bemerkenswert, denn ein Compiler-Fehler als Auslöser wird dadurch deutlich unwahrscheinlicher.

Ursprünglich bin ich darauf gestoßen, als ich die D-Bindings geschrieben habe. Dort hole ich mir die Adressen der Funktionen der C-API zur Laufzeit, und so ist es nicht weiter verwunderlich, dass das falsch benannte Symbol einen Fehler verursacht. Kürzlich habe ich es aber geschafft, auch bei »normaler« Verwendung, also dem Übergeben der Library beim Linken eines C++-Programms, einen diesbezüglichen Fehler zu erzeugen – der Versuch, das gelinkte Programm auszuführen, erzeugte eine »unresolved symbol«-Fehlermeldung.

Die genauen Umstände habe ich leider nicht mehr im Kopf, aber ich würde es mir so erklären, dass der Compiler beim Verarbeiten der Assimp-Includes der Meinung war, das Symbol würde mit C-Linkage exportiert – was es ja eigentlich auch sollte, aber aus bisher ungeklärten Gründen wird es eben dem C++-Name-Mangling unterzogen.

Edit: Wieso befindet sich pstdint.h eigentlich in include/Compiler und nicht in code? Wenn ich nichts übersehen habe, wird die Datei ja nur intern gebraucht, in den öffentlichen Headern findet sich kein Verweis darauf.

Edit 3: Das Gleiche gilt auch für BoostWorkaround. Oder ist include gar nicht als »öffentliches« Include-Verzeichnis konzipiert?

Edit 2: Was ist jetzt eigentlich die »offizielle« Schreibweise? »Assimp«? »ASSIMP« (wird in der Doxygen-Dokumentation verwendet)? Ist »AssetImporter« auch eine mögliche Form (ist derzeit der CMake-Projektname)? Meiner Meinung nach wäre es gerade vor dem ersten Release nett, sich auf eine »Marke« festzulegen, gerade auch im Hinblick auf Release-Verlautbarungen und deb/rpm/…-Pakete.
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

CMake unterstützt »make install« recht unkompliziert, hier ein erster Patch. Könnte jemand, der CMake unter Windows nutzt, bitte ausprobieren, ob der VC++-Generator noch immer sinnvolle Ergebnisse liefert?

Ich habe übrigens gerade bemerkt, dass es zumindest ein Team gibt, das tatsächlich Assimp mit den D-Bindings benutzt – bei der derzeitigen Größe der D-Community fast schon ein Wunder. ;)
Zuletzt geändert von klickverbot am 15.02.2010, 15:23, insgesamt 1-mal geändert.
Benutzeravatar
jgl
Establishment
Beiträge: 109
Registriert: 08.04.2009, 08:58

Re: Assimp - Brainstorming zum Release

Beitrag von jgl »

@Assimp
Kann das auch Animationen "darstellen"?
Hat da jemand gute Links/Infos?

LG J...
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

@jgl:
Ganz generell:Bone-Animationen werden unterstützt. Die importierten Animationsdaten zu verwerten, bleibt natürlich dir selbst überlassen.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Zum `aiGetMaterialProperty`-Kriegsschauplatz: ich habe klickverbot eigentlich nur wenig hinzufügen. Linkerbug nahezu ausgeschlossen. Der einzige Unterschied zwischen besagter Funktion und der direkt darunter deklarierten aiGetMaterialFloatArray besteht in einem 'aiMaterialProperty*' als Parameter. Gut möglich dass es sich dabei um den Auslöser handelt. Leider sieht besagte Struktur auch nicht anders aus als jede andere in Assimp. Rumspielen an der Deklaration bringt auch nichts. Den Sprachstandard habe ich bereits nachgeschlagen - außer Konfusion über die exakte Bedeutung von 'extern C' hat er nur wenig beizusteuern. Das Ergebnis ist unter Linux/GCC wie Windows/MinGW wie Windows/MSVC absolut identisch. nm+grep zeigt dass scheinbar alle aiXX-Funktionen korrekt (Achtung!, Anglizismus) gemangled werden, von unserem Sorgenkind abgesehen.

Es ist in jedem Fall eine dämliche Kleinigkeit die von niemandem der Beteiligten wohl jemals wieder vergessen werden wird, sobald wir sie dann mal kennen :-)
aiMaterial.h:1190
Edit: Wieso befindet sich pstdint.h eigentlich in include/Compiler und nicht in code? Wenn ich nichts übersehen habe, wird die Datei ja nur intern gebraucht, in den öffentlichen Headern findet sich kein Verweis darauf.

Edit 3: Das Gleiche gilt auch für BoostWorkaround. Oder ist include gar nicht als »öffentliches« Include-Verzeichnis konzipiert?
Eigentlich schon als öffentliches Verzeichnis. Du hast Recht, sowohl stdint als auch boost-workaround gehören eigentlich nach ./code. Wenn niemand Einspruch erhebt, sorge ich für's Verschieben.
Edit 2: Was ist jetzt eigentlich die »offizielle« Schreibweise? »Assimp«? »ASSIMP« (wird in der Doxygen-Dokumentation verwendet)? Ist »AssetImporter« auch eine mögliche Form (ist derzeit der CMake-Projektname)? Meiner Meinung nach wäre es gerade vor dem ersten Release nett, sich auf eine »Marke« festzulegen, gerade auch im Hinblick auf Release-Verlautbarungen und deb/rpm/…-Pakete.
Ich bin für 'Assimp' als Produktkürzel, 'Open Asset Import Library' als voller Name und 'assimp' als Paketname für die alle linuxoiden Paketmanager. Sollten wir drüber abstimmen sofern mehrere Meinungen existieren.
Ich habe übrigens gerade bemerkt, dass es zumindest ein Team gibt, das tatsächlich Assimp mit den D-Bindings benutzt – bei der derzeitigen Größe der D-Community fast schon ein Wunder
Freut mich zu hören :-) Dann wird es zugleich aber immer dringender endlich mal ein Release herauszubringen das auch die D-Bindings enthält.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Krishty »

Ist es gewollt, dass aiGetMaterialProperty() mit aiTextureType type deklariert, aber mit unsigned int type definiert ist? Bei aiGetMaterialFloatArray() ist es jedenfalls nicht so.

Falls es das ist, waren das die drei produktivsten Minuten meines Tages.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Jepp, that's it. Unglaublich deprimierend - gut, dass du es gesehen hast. Ich schulde dir ein Bier, sollten wir uns mal über den Weg laufen.

Der Beweis:

Code: Alles auswählen

acg@acg-laptop:~/dev/assimp/trunk/bin/gcc$ nm libassimp.so | grep -E 'T ai\w+'
000000000009ef80 T aiApplyPostProcessing
00000000000a0790 T aiAttachLogStream
000000000009e330 T aiCreateQuaternionFromMatrix
000000000009faf0 T aiDecomposeMatrix
000000000009ecf0 T aiDetachAllLogStreams
000000000009e620 T aiDetachLogStream
000000000009e5f0 T aiEnableVerboseLogging
00000000000a1cb0 T aiGetCompileFlags
000000000009daf0 T aiGetErrorString
000000000009e580 T aiGetExtensionList
00000000000a1c80 T aiGetLegalString
000000000013de80 T aiGetMaterialColor
000000000013dae0 T aiGetMaterialFloatArray
000000000013e0e0 T aiGetMaterialIntegerArray
000000000013d010 T aiGetMaterialProperty
000000000013deb0 T aiGetMaterialString
000000000013e480 T aiGetMaterialTexture
000000000013cf80 T aiGetMaterialTextureCount
000000000009ef10 T aiGetMemoryRequirements
000000000009e6f0 T aiGetPredefinedLogStream
00000000000a1ca0 T aiGetVersionMajor
00000000000a1c90 T aiGetVersionMinor
00000000000a1cc0 T aiGetVersionRevision
000000000009e2c0 T aiIdentityMatrix3
000000000009e2f0 T aiIdentityMatrix4
00000000000a0460 T aiImportFile
00000000000a0140 T aiImportFileEx
00000000000a0470 T aiImportFileFromMemory
000000000009ed80 T aiIsExtensionSupported
000000000009e120 T aiMultiplyMatrix3
000000000009dc90 T aiMultiplyMatrix4
000000000009f040 T aiReleaseImport
000000000009f680 T aiSetImportPropertyFloat
000000000009f470 T aiSetImportPropertyInteger
000000000009f0f0 T aiSetImportPropertyString
000000000009db80 T aiTransformVecByMatrix3
000000000009dc00 T aiTransformVecByMatrix4
000000000009db00 T aiTransposeMatrix3
000000000009db30 T aiTransposeMatrix4

 
Ein einwandfreier C-Export :-) Mir fallen keine weiteren fehlenden Funktionen auf.
EDIT - Ist eingecheckt.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

@klickverbot:
Vielen Dank für den Patch, werde den unter Windows mal probieren.

Gruß Kimmi
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

Aramis hat geschrieben:Jepp, that's it. Unglaublich deprimierend […] Mir fallen keine weiteren fehlenden Funktionen auf.
In der Tat ist es etwas belustigend, dass auch ich den Fehler bisher einfach überlesen habe – naja, wenigstens ist das Problem jetzt behoben. Die neue Revision der D-Bindings, die ich gerade eingecheckt habe, sollte nun die C-API komplett abbilden, weitere fehlende Funktionen wären mir wahrscheinlich aufgefallen.

Bezüglich der Namensfragen: Auch in meinen Augen wirkt »Assimp«/»Open Asset Import Library«/»assimp« am schönsten. Allerdings glaube ich mich zu erinnern, ob nicht manche Distributionen (Debian?) einen »lib«-Präfix für Pakete von Bibliotheken fordern oder zumindest empfehlen – hier auf Arch Linux ist es jedenfalls nicht so. Im Lizenztext wird das »ASSIMP Development Team« stets in Großbuchstaben geschrieben – Absicht?

Da die D-Bindings jetzt komplett sind, steht einem Release von meiner Seite aus nur noch der fehlende CMake-Install-Support im Wege. Der Patch von oben scheint hier auch unter Windows problemlos zu funktionieren, aber mit dem Einchecken möchte ich noch warten, bis die Frage mit dem Include-Verzeichnis und der Namensgebung geklärt ist.
Zuletzt geändert von klickverbot am 15.02.2010, 17:16, insgesamt 1-mal geändert.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Unter Linux hat sich als Präfix lib in der Tat eingebürgert, das ist meines Wissens nach distributionsunabhängig. Von da aus könnte man das im Skript vorsehen. Das beinhaltet dann aber noch eine Änderung des GNU-Makefiles.
Und von so einem Fehler sollte man sich nicht deprimieren lassen. Viele dicke Hunde, die ich im Job gesehen habe, wurden durch so etwas ausgelöst.

Gruß Kimmi
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

kimmi hat geschrieben:Unter Linux hat sich als Präfix lib in der Tat eingebürgert, das ist meines Wissens nach distributionsunabhängig. Von da aus könnte man das im Skript vorsehen. Das beinhaltet dann aber noch eine Änderung des GNU-Makefiles.
Ich komme da nicht ganz mit, was man da am Makefile ändern müsste – das Paket zu benennen ist doch Sache der Packager. Ich habe gerade das Arch-Linux-Repository durchgeblättert, dort werden die Pakete immer nach dem Projektnamen benannt, ob dieser nun ein »lib« beinhaltet oder nicht. In Debian-artigen Distributionen scheint der Präfix hingegen üblich zu sein. Aber das sollte wie gesagt nicht jetzt nicht unser Problem sein, oder übersehe ich etwas?

Apropos Makefile: Aus welchem Grund werden die Header und Bibliotheken im »install«-Target von code/makefile standardmäßig nach /usr/bin/assimp/{lib,include} installiert? Nach FHS/LSB wäre /usr/local/{lib,include} das Standardverzeichnis der Wahl. Außerdem werden die »Compiler«-Includes nicht mitkopiert, die auch für die öffentlichen Header nötig sind.

Und wie schaut es mit dem Rest von workspaces/ aus? Sind die Dateien für SCons und XCode noch aktuell? Ich persönlich wäre übrigens dafür, alles außer CMake zu entfernen, oder zumindest eine Variante als »offiziell« zu deklarieren, das würde die Wartung wesentlich einfacher machen (allerdings weiß ich nicht, ob die von CMake generierten VC++-Projekte brauchbar sind).
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Präfix: ich bin bezüglich Packager unter Linux aufgrund langer Abstinenz nicht mehr auf der Höhe. Wenn die das selber machen: um so besser. Im Make von Ankon hatte er die meines Wissens bei der Benutzung von Automake mit so einem Präfix von Hand versehen.

Da ich den FHS/LSB nicht kenne, habe ich das an die falsche Ecke kopiert. Und was ist der FHS/LSB überhaupt? Ich hatte noch nie viel mit der Vorbereitung von Packages unter Linux zu tun und kenne mich da nicht besonders gut aus.
Und gut zu wissen, daß die Compiler-spezifischen Header da noch mit müssen. Daran hatte ich nicht gedacht. Da du dein Linux scheinbar öfter an hast als ich das meinige: kannst du bitte die Anpassungen vornehmen? Ich komme gerade nicht zu so besonders viel und wäre froh, wenn die Makes sauber ist. Danke schon mal im Voraus ;).
Der Scons-Build war der Linux-Make-Versuch vor CMake. Da CMake sich größerer Beliebtheit erfreut, würde ich Scons rausschmeißen. Der XCode-Kram kann meines Wissens ebenfalls per CMake erstellt werden. Wenn den keiner mehr benutzt, sollte der auch entfernt werden können.

Und Danke für die Hilfe!

Gruß Kimmi
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

Bei FHS handelt es sich um den Filesystem Hierachy Standard und bei LSB um die Linux Standard Base, sie legen unter anderem eine Standard-Verzeichnisstruktur fest. Mit der Vorbereitung von Packages unter Linux hatte ich leider bisher auch nicht gerade viel zu tun.

Ich bin mir nicht sicher, ob wir die Makefiles überhaupt behalten sollen, denn CMake kann die Aufgaben mindestens gleich gut erfüllen und ist mittlerweile schon so weit verbreitet, dass ohnehin niemand drum herumkommt, der ab und an mal ein Open-Source-Projekt selbst kompiliert. Wenn gewünscht, kann ich mich einmal dahinterklemmen und das CMake-Skript etwas aufhübschen (Boost-Erkennung, Single-Threaded-Builds, …), dann könnten wir die Makefiles ganz streichen – toll, oder? ;) (Ich konnte mich persönlich nie mit der Syntax anfreunden, ja…)
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Meine Meinung: CMake als offizielles Buildsystem - ja. Scons raus - ja. XCode - ist schon eine Notiz dabei dass es veraltet ist. Man muss aber anscheinend nur ein paar fehlende Units nachtragen, das sollte menschenmöglich sein. Bin dafür es im Repos zu lassen, aber für Releasepakete zu entfernen. Make raus - Nein. Es muss stets ein funktionstüchtiges makefile in code/ verbleiben (das kann aber gerne über andere Meta-Buildsystemen generiert werden). Zur Verbreitung von CMake kann ich nichts sagen, nur dass man es tatsächlich immer häufiger zu sehen kriegt. Ein ganz normales 'make && make install' ist aber imho noch eine Spur gängiger und auch idiomatischer ... Ebenfalls drin bleiben müssen vorgenerierte VC Workspaces. Unter Windows gibt es einfach nichts besseres.

Zum `install´-Ziel: Zustimmung zu klickverbot. Unbedingt der Konvention folgen.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Zum Install-Target: Bin ebenfalls voll für das Halten an die Standards.

Gruß Kimmi
Antworten