<div dir="ltr">Hello all,<div><br></div><div>I have partial  JavaScript bindings for the SB* API. I've generated them via SWIG and when using a current version of SWIG (3.03 or later, I think), they generate something that can work for Node.JS, io.js and other environments.  I've just been using these for some proof of concept work, so they aren't complete yet.</div><div><br>It is probably possible to work on upstreaming these changes into LLDB. It requires moving the *.i files into a directory where they aren't entirely specific to Python.</div><div><br></div><div>This does bring up the point that if that were to happen, it would be a good time to more clearly mark what is good practice in the SB* API and what shouldn't be wrapped in new bindings. (There's no old code for JS or other languages to worry about breaking, so they can ignore deprecated APIs.)</div><div><br></div><div>The above path is kind of tricky and annoying at times though, so I've thought about manually writing a C wrapper around the C++ SB* API and using that for bindings instead. This would be more readily accessible in more languages (that often interoperate with C better than they do C++).</div><div><br></div><div>Is there interest in generalizing the SWIG bindings generation and including other languages than Python?</div><div><br></div><div>Is there interest in a C wrapper for the SB* API?</div><div><br></div><div>Is there a preference as to which approach might be more welcome? Lately, I've been leaning towards the C wrapper being more useful to me across a couple of projects, including one where I'd be writing code using the LLDB API in Dylan (<a href="http://opendylan.org/">http://opendylan.org/</a>) where we have an excellent C FFI but not a C++ FFI.</div><div><br></div><div> - Bruce</div><div><br></div></div>