ZFX + Developia

Matthias Gubisch hat geschrieben:Was meinst du mit harten Pfaden zu dependencies

Matthias Gubisch hat geschrieben: dass die Pfade zu 3rd-PartyLibs VisualStudio bekannt sein müssen ist ja wohl nicht das Problem der SLN...

Matthias Gubisch hat geschrieben: Pfadangaben innerhalb der Soulution sollten sich imho immer auf das Projekt beziehen und nich irgendwelche ThirdParty Libs an bestimmten Stellen voraussetzen
und imho ist das bei ASSIMP auch der Fall.

Grüße
Matthias

kimmi hat geschrieben:Ich denke, hier wird das Problem adressiert, daß man kein AutoConfig beim Visual Studio hat. Das macht CMake im übrigen auch implizit, wenn man die Makes entsprechend schreibt *rumpose*...

Gruß Kimmi

Thoran hat geschrieben:

Matthias Gubisch hat geschrieben: dass die Pfade zu 3rd-PartyLibs VisualStudio bekannt sein müssen ist ja wohl nicht das Problem der SLN...

DIe Pfade müssen in der *.sln bekannt sein, so daß die 3rd-Party Lib gefunden wird.

Entgegen meiner andauernden Bemühungen, neue interessante Boost-Libs zu finden, für die er dann eine einfache Emulation schreiben muss...

Schrompf hat geschrieben:

Thoran hat geschrieben:

Matthias Gubisch hat geschrieben: dass die Pfade zu 3rd-PartyLibs VisualStudio bekannt sein müssen ist ja wohl nicht das Problem der SLN...

DIe Pfade müssen in der *.sln bekannt sein, so daß die 3rd-Party Lib gefunden wird.

Nein, das ist der Knackpunkt. Bei Visual Studio erklärt man die Include- und Libpfade der IDE und nicht dem Projekt. Sprich: jeder Entwickler kann seine Libs rumliegen haben, wo er will, er muss nur VS die Pfade zu den jeweiligen Includes und Libs geben. Danach findet jedes Projekt die.

Mit Visual Studio 2010 hat sich das geändert, jetzt gibt es die nur noch als Projekteigenschaften. Was mich sehr betrübt, weil ich dort ja keine absoluten Pfade eingeben kann... die gelten ja nur für meinen Rechner. Allerdings kann ich da auch keine relativen Pfade eingeben, dann auch die stimmen nur auf meinem Rechner. Mit diesem Umbau wurde einfach ein gut funktionierendes System aufgegeben, ich hoffe aus triftigem Grund.

• In der README werden sowohl Leerzeichen als auch Tabulatoren zur Einrückung verwendet.
• Die Copyright-Texte (im Lizenz-Vorspann und in AssimpPCH.cpp) sollten wohl einheitlich die gleichen Jahreszahlen angeben (und 2009 einschließen).
• Für AssimpCmd fehlt noch eine README.
• Der Name »Assimp« wird in drei verschiedenen Groß-/Kleinschreibungs-Varianten verwendet.

Die Bindings testen dann auf eine gleiche Major-Version und eine mindestens so große Minor-Version um sicherzugehen, dass einem nicht unerwarteterweise alles um die Ohren fliegt.

Edith sagt, dass »aiGetMaterialProperty« noch immer nicht richtig in die dynamischen Bibliotheken exportiert wird – ich binde die Funktionen dynamisch (nach dem Namen), und »aiGetMaterialProperty« wird nicht gefunden…

Wobei ich auch nichts dagegen hätte, wenn die D-Bindings in das SVN Repo wandern, sobald sie stabil sind – mir ist beides gleichermaßen recht

Aramis hat geschrieben:wenigstens kennen wir jetzt das eigentliche Problem (es tritt sowohl mit gcc/ld unter Linux als auch mit MSVC auf). aiGetMaterialProperty wird schon exportiert, aber so wie's aussieht mit C++-Bindung und entsprechend langem Namen.

Aramis hat geschrieben:wenn du mir deinen SF.net-Accountnamen sagst, gebe ich dir gerne mal präventiv Schreibzugriff :-)

kimmi hat geschrieben:Verstehe ich das richtig, daß dann die Minor Releases ( also z.B. 1.1, 1.2 etc. ) Bugfix-Releases darstellen beziehungsweise nur marginal neue Funktionalitäten beisteuern?

Vielleicht finden sich so ein paar Tester

• Seitens des Users kann er zu einem bestimmten Flag besser die Flags finden und ordnen (bessere Übersicht für den Nutzer).
• Man kann es noch weiter treiben und sogar eine Funktion schreiben, die mittels bool-Parameter selbst die Flags packt (noch freundlicher).
• Für den Programmierer ist mehr Struktur vorhanden und dies beinflusst die Programmierung im positiven Sinne (spart Ärger und Arbeit).
• IntelliSense zeigt nun nicht einzig den Wert, wenn man den Namen schon kennt, sondern leitet einen gleich hin.
• Die Werte können in der lib besser miteinander kombiniert werden (sprich: Ein Konstantenregister für n Klassen allgemeingültig, oder man kann die Konstanten vererben).

Könnt ihr Definitionen und Konstanten nicht in einem Constants Namespace packen und diesem speziellen Bereich eine Klasse mit statischen Attributen? Das

Btw: Mir war auch so, dass es irgendwie ein define gab, mit dem man prüfen kann ob man C oder C++ Programmiert?

Wo ist eigentlich der angekündigte OpenGL-Viewer-Code

•Die Werte können in der lib besser miteinander kombiniert werden (sprich: Ein Konstantenregister für n Klassen allgemeingültig

Apropo "API bleibt, wie sie ist": finale Entscheidung zum Thema "Material-Indizes pro Mesh-Instanz"? Wenn das noch vor dem Release werden soll, müssten wir demnächst mal damit anfangen. Meine Stimme geht an "Ja".

Aramis hat geschrieben: Ich sehe keinen Ärger mit den Konstanten - wir benutzen unser AI_ prefix, via Intellisense sind unsere define's und enum's keinen Deut weniger zugänglich als Klassen oder Namespaces die nur Konstanten enthalten (ganz mal davon abgesehen dass Klassen, die nur dazu dienen ein paar Konstanten zu kapseln definitiv nichts mit OOP oder dem C++ way of life zu tun haben ...).

class foo {
  ...
  static const int Baa = 0;
};
int pos = foo::Baa;