jing...@apple.com schreef op 2/18/2015 om 2:56 AM:
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.
So SWIG actually supports multiple languages on the same binding? I currently have my own C# bindings (http://pastie.org/9963898) for SWIG because I couldn't figure out how to reuse the python ones (My idea was to look into an open source VS debugger plugin that uses lldb and gets triggered from the existing llvm platform support)
-- Carlo Kok RemObjects Software _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
