One good thing about the SWIG approach is that it is easy to introduce all the niceties that make LLDB a good fit for the language that is wrapping it (like property accessors, iterators, object printing and the like.
Anyway, we designed LLDB so it could - in theory - be extended to support whatever languages SWIG supported. If you are going to do this job right, you would also need to extend the script interpreter from its current 1 language to many, and add ability to do breakpoint commands, etc, in the various languages. I'm on the fence about what to do with the .i files if we're going to start supporting other extension languages. They will get awfully cluttered if we actually start using them as intended for Python extras AND JS extras, AND... Maybe we will want to split out the "just copied over from the .h file" portion of the .i files, and then have multiple language support versions? Making C bindings so you can then turn around and wrap them in some other language seems a rather low-fidelity way of doing the same job. How do you then put back together all the classes you've taken apart to make a coherent API? I'm afraid you'd just get slowly dragged into reproducing the work that SWIG did. If somebody wants to do that, then it would be better to do something clever using say that nice C++ front-end we have lying around and generate bindings that way. Jim > On Feb 17, 2015, at 5:38 PM, Bruce Mitchener <bruce.mitche...@gmail.com> > wrote: > > On Wed, Feb 18, 2015 at 8:29 AM, Zachary Turner <ztur...@google.com> wrote: > Maybe we can add support for Python3 too. I know that moving off of Python 2 > is a non-starter because of legacy code, but if it's ever going to happen in > the future, then starting earlier is better than starting later, and this > would be a good starting point. > > For what it's worth, the python-based swig generation script has support for > other languages. There's a top level script which recurses into each > language-specific subdirectory and runs a script in that directory to shell > out to swig for the final creation. So that part should be extensible. > > That's what I do for my JS bindings already, although I am still using the > old shell script code in that tree. I did have to move the *.i files though > and modify them to only conditionally include some stuff that is Python > specific. > > But the SWIG approach is rather painful for some other languages, so I'd like > to hear if others might want a more straight forward (in terms of bindings) C > API. > > - Bruce > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
