> There are three routes I can see that one can take with using > osgIntrospection : > > 1) Dynamically binding to OSG objects at runtime using > osgIntrospection as osgLua > and osgPython do, > > 2) Use osgIntrospeciton to reflect the C++ API and generate the > approrpriate C++ to > 3rd party language bindings. > > 3) Use a combination of 1 & 2, basically use 1 for the bulk of the > API, but then > use option 2 when you need more highly optimized wrappers. > > For some languages like Java and C# option 1 is largely out of the > question as they aren't dynamic languages, so option 2 would be > natural route. > > Right now we have Marco Jez' genwrapper tool written in C++. To do > option 2 we'd need luawrapper, pythonwrppaer, javawrapper etc. These > extra tools could be written in any language that already has > integration with osgIntrospection - this would lead me to suggest > using something like osgLua or osgPython to extra the wrappers and > then parse them to generate the final 3rd party language wrappers. > > Since genwrapper and osgIntrospection are rather loosely coupled to > the OSG itself one can use it to parse other 3rd party C++ libraries. > > Now I'm no expert in genwrapper, osgIntrospection or languages beyond > C++, so alas I can't provide get wisdom or manpower in pushing such > suggests as above ahead, we'll need members of the community to pick > up the ball. I do feel that the above route would be the most > manageable long term, even if it does mean a bit more leg work right > now.
Hi Robert, Apologies for jumping into the middle of the discussion here, but hopefully I can provide some insight based on the work I've done so far towards creating C# bindings via option 2. It's pretty clear that osgIntrospection was designed to support option 1. I believe it can be used for option 2, but it needs some additional work to expose additional properties of the interfaces that are necessary to provide reasonably complete bindings for other languages. For example, it doesn't expose virtual/pure virtual state of functions which is necessary to properly support subclassing. It also does not distinguish between value, reference, and const reference types. I will need to address some of these deficiencies to create C# bindings. Also, it's not clear to me that supporting both usage models 1 and 2 from the same codebase is the best long-term solution. I believe Marco has said in the past that it would be valuable to separate the low-level C++ reflection support from the aspects supporting higher-level language (e.g. properties). I'm certainly running into issues where it's not immediately clear what will be the effect of a feature supporting usage model 2 on usage model 1. Separating the two is beyond what I can achieve in the time I have available though... I think your idea of creating scripting bindings for osgIntrospection is really the way to go. While doing analysis of the OSG classes and interfaces I've wished more than once that I had python or ruby bindings of osgIntrospection that I could interactively interrogate in a console. And writing a wrapper generator in a scripting language would be _so_ much more pleasant (and probably go much faster) than writing it in C++. -Mike _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
