Perform a forum search with "Generate" there are some binder generator scripts posted before.
i have started such project. Serious hurdles are:
- Can not determine object type. Is it a Value, NOCOUNT, Refcounted or Garbage collected
- Parameter type, &in &out &inout . Easy way out is enable unsafe refs.
- Inheritance, not enough to scan a single .h file. Allow casting or not?
- How about primitive typedefs
- Heap corruption errors, Yeah, they happen a lot. you can't spot these until functions are used in script. So, lots of test cases ?
my solution is to put preprocessor directives before some risky declarations.
I am getting tired, just too many cases to handle.
Manually registering them is way easier.
I use doxygen as the backend for my script generator. A lot of the required information is specified in the comments. For example, if a function has a comment /* @param outTriangleCount [out] Receives the number of triangles generated. */, then the presence of the string '[out]' tells the generator to use '&out' for the binding. The bindings are generated at a global project scope, not by scanning a single .h file, so the generator has knowledge of which types the script engine understands, and it automatically leaves out those signatures that contain symbols that aren't understood. Inheritance, #defines and typedefs are detectable, since doxygen knows about those, and the generator can be guided with special comments inside doxygen tags like [noscript] or [valuetype], etc. Whether the types have custom ctor/dtor/assignment/copyctor is known, and function default parameters can also be detected.
So far the generator is very primitive, and only used to expose MathGeoLib value types. What I'm looking for currently is whether I am duplicating my effort here and if it's sensible to write this at all, or whether someone else has solved this already.
I am still a beginner to Angelscript, so your insights on what exactly are the "not-automatically-detectable-by-introspection" kind of cases are very valuable to me. If you can give some pointers on what kind of "external" decisions a developer makes when building interop, that will be very helpful.