<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><blockquote type="cite"><div>On Jul 10, 2014, at 5:13 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">As of r<span style="font-family:arial,sans-serif;font-size:13px">212785, 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.</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div></div></blockquote><div><br></div><div>That’s wonderful! Congratulations!</div><br><blockquote type="cite"><div><div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div></div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>For a while, we had a build system where we checked out a known revision of LLVM and applied patches on top of it.</div><div>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.</div><br><blockquote type="cite"><div><div dir="ltr">
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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)</span></div></div></div></blockquote><div><br></div><div>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.</div><div>If that turned out to be hard, one could go back to the known-revision + patches build machinery</div><br><blockquote type="cite"><div><div dir="ltr">
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">3) Move to Python 3.x. SWIG supports Python 3.x, but it would require us porting all the tests. </span></div></div></div></blockquote><div><br></div><div>That, and every usage of the Python C API if there are changes between 2.x and 3.x in that realm.</div><div>Plus, I don’t think OS X ships with Python 3 at all. That could be inconvenient.</div><br><blockquote type="cite"><div><div dir="ltr">
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div></div></div></blockquote><div><br></div><div>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)?</div><br><blockquote type="cite"><div><div dir="ltr">
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Maybe there are other options I haven't thought of. Thoughts?</span><br></div></div></div></blockquote><div><br></div><div>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.</div><div>Just my two cents though. And, again, awesome work!!</div><br><blockquote type="cite"><div><div dir="ltr"><div>
</div></div>
_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev<br></div></blockquote></div><br></body></html>