Investigate viability of Swig replacing binding generation process

[rokups]

We should investigate viability of Swig replacing binding generation process. Swig is old and well maintained tool supporting multiple languages. Primary concern is c#, but it also opens doors for easy support of some other languages should they be considered in the future (python/java/go/etc).

I started experimenting with swig, my work can be viewed here: https://github.com/rokups/Urho3D/tree/feature/swig

Things to consider:

• Swig can not automatically wrap operators (for c# at least), they have to be handled manually.
• Swig does not handle multiple inheritance when wrapping to c#. Investigate possible workarounds.
• Engine containers and String/WString should be mapped to native c# containers and data types.
• Some math classes should not be wrapped, but mapped to types from System.Numerics.
• GetX/SetX need to be converted to properties in order to match current .NET API as closely as possible.
• Special care has to be taken of classes with virtual methods which are supposed to be overriden from c#. Docs

[mattbenic]

Lack of operator support isn't too big of an issue, given that math types should really just be mapped to C# equivalents with some efficient way of marshalling the underlying data. I can't imagine there would be too many other use cases.

Multiple inheritance and virtual methods would be a much bigger issue.

[Alan-FGR]

what about starting with something minimal to see if there's no important drawback or if there's a chance we'll get stuck behind a wall ahead (e.g. multiple inheritance). If I understand correctly, I don't think the virtual methods will be a problem, it's just a matter of adding them to a blacklist isn't it?
I can't even get something to actually load the unmanaged library here :P such a noob... should SWIG in theory provides us a managed lib that we should be able to just use outta the box? Should it handle binary loading and shit?

[rokups]

what about starting with something minimal to see if there's no important drawback or if there's a chance we'll get stuck behind a wall ahead (e.g. multiple inheritance).

Totally. There must be a workaround, though i did not look for it that hard.

If I understand correctly, I don't think the virtual methods will be a problem, it's just a matter of adding them to a blacklist isn't it?

More like whitelist. Basically just add extra line for classes that are supposed to be inherited and have virtual methods. This is non-issue, just something to keep in mind.

should SWIG in theory provides us a managed lib that we should be able to just use outta the box?

As i understand it should produce one managed lib and one native lib.

[rokups]

Yesterday i moved work forward a bit, integrating it into build system and wrapping some extra stuff. Ofc it does not build due to some errors. Not too many so that is good.