As of r212785, we now have a working Python API on Windows. There are no python errors about termios when you start LLDB, there are no errors or warnings when you enter script mode, and you can create and manipulate objects in the embedded script interepreter. There are still some remaining issues, and the test suite doesn’t yet work, but we’re close.
Unfortunately, one of the steps necessary to get this working was to require developers who want to embed Python in their windows build to compile their own Python. And, as it turns out, Python 2.7 doesn’t even compile out-of-the-box with the newest version of MSVC, and requires you to edit a Python header file locally.
I’d like to streamline this a little bit, and remove as many of the manual steps as possible, so here are a list of possible options for how we could resolve this:
Check in python source code into LLDB, make the changes in our fork, have it build automatically as part of the LLDB build. From the user’s point of view this option has the least work involved, but it kind of sucks checking this much stuff into the repo. I have it on good authority that there is not a licensing issue involved with checking Python into LLDB.
Try to upstream changes to 2.7 that ease the pain of building Python manually on Windows with modern toolchains. Python community is generally resistant to accepting patches to 2.7, although I’ve spoken with someone on the committe and he says this has a decent chance of getting accepted. Would require people on windows to use Python 2.7.9 (which naturally doesn’t exist yet)
Move to Python 3.x. SWIG supports Python 3.x, but it would require us porting all the tests.
Build debug and release versions of python and check the binaries into LLDB’s tree along with matching headers, and just have the build use those.
Maybe there are other options I haven’t thought of. Thoughts?