I'm with Enrico on this. Either #2 which would be of the widest benefit, or an svn revision and patch file seem the simplest way to go.
Note that moving to Python 3.0 has to be carefully considered since it affects all the clients of the Python API. The kernel folks are the biggest client we know of with some 10000+ lines of Python2.7 + SB API code that they use to aid kernel & kext debugging. There are probably other folks who have built formatters & tools as well that we just don't know about. So if we ever decide to do this we need to give a decent lead time and a heads up... Jim > On Jul 10, 2014, at 5:26 PM, Enrico Granata <[email protected]> wrote: > > >> On Jul 10, 2014, at 5:13 PM, Zachary Turner <[email protected]> wrote: >> >> 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. >> > > That’s wonderful! Congratulations! > >> 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: >> >> 1) 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. > > This sounds kind of scary to have python be part of our source tree checked > out every time for everyone (even those of us on *nix systems that have > working linkable Pythons out-of-the-box). > > For a while, we had a build system where we checked out a known revision of > LLVM and applied patches on top of it. > You could setup a similar system for Windows builds, look in the source tree > for a python codebase, if not found, checkout the magic revision you need, > and apply a set of patch files against it. > >> >> 2) 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) > > It seems like this would be a good idea. And the requirement of 2.7.9 could > clearly be documented as part of the requirements for Windows folks. > If that turned out to be hard, one could go back to the known-revision + > patches build machinery > >> >> 3) Move to Python 3.x. SWIG supports Python 3.x, but it would require us >> porting all the tests. > > That, and every usage of the Python C API if there are changes between 2.x > and 3.x in that realm. > Plus, I don’t think OS X ships with Python 3 at all. That could be > inconvenient. > >> >> 4) 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. > > I would definitely -1 to having built Pythons for Windows in the source tree. > Source code version control systems are quite bad at handling binary data, > plus again you’d have some Windows-only tool be part of every checkout, > needed or not (and I am assuming there would be 4 of those, debug32, debug64, > release32, release64)? > >> >> Maybe there are other options I haven't thought of. Thoughts? > > My first favorite would be getting 2.7 to build on Windows, either via > getting official Python patched for recent Windows toolchains, or having a > known revision + local patches be part of a Windows build. > Just my two cents though. And, again, awesome work!! > >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
