BulletSharpGen fails with Bullet release (2.86)
davilovick opened this issue · comments
First of all, thankts for this great project 👍
The latest bullet releases has been introduced some code changes that is not compatible with the BulletSharpGen.
It fails to parse correctly this property in btDbvtBroadphase.h file:
btAlignedObjectArray< btAlignedObjectArray<const btDbvtNode*> > m_rayTestStacks;
It throws a NotImplementedException in TypeRefDefinition.cs:228. Because the TypeKind is invalid for the btAlignedObjectArray type.
What is the latest version that BulletSharpPInvoke is compatible?
BulletSharpGen has been broken for a while now, because I haven't had much time to work on it. At some point it worked pretty well on some parts of Bullet, but failed badly on others. For you, it's probably not worth using anyway.
I have tried to generalize the generator a bit here:
https://github.com/AndresTraks/DotNetWrapperGen
but that version was built from the ground up and doesn't do much yet. Once it produces some usable code, then I'll delete BulletSharpGen from this repository.
It seems that CppSharp has recently developed into pretty much the same project. It might be worth checking out, though I doubt it can be customized for Bullet as well as BulletSharpGen. I haven't used it yet.
EDIT: Another problem with CppSharp is that the PInvoke interface is coupled to the memory layout and C++ symbol names of the native library, both of which are compiler-specific. That means you couldn't share the same BulletSharp.dll assembly between Linux and Windows or even between 32-bit and 64-bit versions.
This project also generates a C interface around the C++ library, making the interface universal and allowing only a single version of BulletSharp.dll to be used.
@AndresTraks you're sure CppSharp doesn't work well? You can use DllMappings for facing the mapping issue.
Yes, BulletSharpPInvoke uses dllmaps to select a native shared library (.dll / .so) that is suitable for the current platform. This only works with the Mono .NET runtime (not Microsoft's .NET runtime), but that is good enough.
The problem is that the function names that native shared C++ libraries expose are different depending on the C++ compiler (GCC, MSVC, etc.). With DLL mappings, you can select DLL names, but not funtion names. So you still need to create a C-style wrapper function around each C++ function. The wrapper function has a common name regardless of the compiler or platform and so it can be easily referenced from the managed library. As far as I can tell, CppSharp doesn't create the C interface and the tradeoff is that the managed library is platform-specific.
https://en.wikipedia.org/wiki/Name_mangling#How_different_compilers_mangle_the_same_functions
http://www.mono-project.com/docs/advanced/pinvoke/#invoking-unmanaged-code
@AndresTraks don't worry I've already worked on CppSharp that's why I was wondering here.
Of course if there isn't a C interface it's not easy with CppSharp. For the build from source it would be required to invoke cppsharp each time.
How bad is the state of the library for real @AndresTraks? I need to estimate whether it's still realistic and so worth to maintain it for my game engine.
How bad is the state of the library for real @AndresTraks?
Which library do you mean?