Hi Peter,
On 1/30/07, Peter Gebauer <[EMAIL PROTECTED]> wrote:
> We I think option 1 - the dynamic bindings would first need to be done
Considering that a lot of languages are not dynamic, would it not be best to
settle on one OSG-generic static way of doing this first?
There aren't that many languages out there of interest to graphics
developers, its bascially Python, Lua, Ruby, Tcl or JavaScript on the
dynamic side, and C# and Java on the static side.
In my work with SWIG I have found that it _could_ be very easy to generate
full bindings for any language by parsing the include files.
If we modify the include files to be more parse-friendly (or to comply more
fully with Swig or Boost) we would not have to maintain a secondary API via
osgIntrospection and we could (in theory) generate bindings for Python,
Ruby, C#, etc using one command on the prompt.
I found one could easily build 3rd party language wrappers once one
had written the interface files, but this is my no means a an easy
route to take. Swig adds oddities in the way it builds things too and
some things it just can't handle at all.
If one could generate bindings directly from the API headers that would be
the least maintenance, it would not reduce speed and it would not limit the
binding language to dynamic ones.
This is what osgIntrospection and genwrapper does. It doesn't need
any interface files.
It also seems like the least work to get working intially. Using the time to
dually maintain the API via osgIntrospection could be used to slightly
modify the headers.
I've completed around 20% of the base API using Swig without having to
modify any header file. So far, only nested structs and some constants have
been a problem, but I easily mended it by writing ifdef sections, sometimes
just adding some new typedef's at the end.
This is just a suggestion, whatever the community at large feel is the right
way to go is my way too. Better that we all focus on one effort.
My suggestion is to push to get osgPython up to speed on the dynamic
binding side. Once these work well enough you could either use them
as is, or use it as spring board to building static Python bindings.
Second up watch on wait to see how Mike Wittman gets on with
generating C# bindings from osgIntrospection wrappers. This may well
flesh out osgIntrospection more for the task of generating 3rd party
lanaguage bindings, and also serve as a template of how one might go
about other language bindings.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
