> 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? 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. 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. 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. Best regards, Peter _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
