IANAL, but I floated this idea once and people weren't super thrilled about the idea of checking in binaries or headers.  That reminds me though that I should ask again.  <br><br>It also doesn't solve the problem for users of lldb on windows who need support for using other extension modules in their scripts.  While not me, I believe there are some people who care about that and would like to make that happen.<br><div class="gmail_quote">On Wed, Feb 25, 2015 at 5:58 AM Vince Harron <<a href="mailto:vharron@google.com">vharron@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This seems like a lot of work to support Windows users who might want to use pre-compiled python modules.</div><div><br></div><div>I think we should distribute a VS2015 based version of Python 2.7 binaries and call it a day.<br></div><div><br></div><div>We can worry about 2020 problems in 2020.  =)</div><div><br></div><div>Reasonable people may disagree.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 24, 2015 at 11:56 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">A little background: The single biggest painpoint for working with LLDB on Windows currently is Python.  There is a <a href="https://mail.python.org/pipermail/distutils-sig/2013-February/020006.html" target="_blank">long</a> <a href="https://docs.python.org/2/extending/windows.html" target="_blank">documented</a> history of the problems with python extension modules on Windows.  <a href="https://msdn.microsoft.com/en-us/library/ms235460.aspx" target="_blank">Part</a> of it is <a href="https://msdn.microsoft.com/en-us/library/bb531344.aspx" target="_blank">Microsoft's</a> fault, part of it is Python's fault (<a href="https://www.python.org/dev/peps/pep-0384/" target="_blank">PEP 384</a> attempts to solve this, but it appears stalled), but the end result is that it's really terrible and there's nothing anyone can do about it.  <div><br></div><div>The implications of this for LLDB on Windows are the following:</div><div>1) Anyone building LLDB on Windows needs to compile Python from source</div><div>2) Even after doing so, configuring the LLDB build is difficult and requires a lot of manual steps</div><div>3) You can't use any other extension modules in your custom built version of python, including any of the over 50,000 from PyPI, unless you also build them from source, which isn't even always possible.</div><div><br></div><div>If you want to be compatible with the binary release of Python and interoperate with the version of Python that probably 99% of Windows people have on their machine, you <b>must</b> compile your extension module with a very old version of the compiler.  So old, in fact, that it's almost end-of-lifed.  If it weren't for Python actually, it would have been end-of-lifed already, and Microsoft ships a <a href="http://www.microsoft.com/en-us/download/details.aspx?id=44266" target="_blank">free version</a> of this toolchain for the express purpose of compiling python extension modules.</div><div><br></div><div>I've been thinking about this for many months, and I believe I finally have a solution (2 solutions actually, although I think we should do both.  I'll get to that later).  Both will probably be painful, but in the end for the better on all platforms.</div><div><br></div><div><b>Solution 1:</b> <b>Decouple embedded python code from LLDB</b></div><div><b>Rationale:</b> Currently calls to embedded python code live in a few different places.  Primarily in source/Interpreter (e.g. ScriptInterpreterPython) and the generated SWIG code, but there's a few utility headers scattered around.</div><div><br></div><div>I'm proposing moving all of this code to a single shared library with nothing else and creating some heavy restrictions on what kind of code can go into this library, primarily to satisfy the requirement that it be compilable with the old version of the compiler in question.  These restrictions would be:</div><div>1) Can't use fancy C++.  It's hard to say exactly what subset of C++ we could use here, but a good rough approximation is to say C++98.</div><div>2) Can't depend on any LLVM headers or even other LLDB libraries.  Other LLDB projects could depend on it, but it has to stand alone to guarantee that it doesn't pick up C++ that won't compile under the old MSVC compiler.</div><div><br></div><div>I understand that the first restriction is very annoying, but it would only be imposed upon a very small amount of source code.  About 2 or 3 source files.  </div><div><br></div><div>The second restriction, and the decoupling as a whole will probably cause some pain and breakage for out-of-tree code, but I believe it's a positive in the long run.  In particular, it opens the door to replacing the embedded interpreter with that of a different language.  By separating the code in this fashion, all one has to do is write a new module for their own language and initialize it instead of ScriptInterpreterPython.  I've already seen people asking on the list about generating bindings for other languages and replacing the interpreter, and i believe a separation of this kind is a pre-requisite anyway.</div><div><br></div><div><b>Solution 2:</b> <b>Upgrade to Python 3.5</b></div><div><b>Rationale:</b> Hopefully I didn't send you running for the hills.  This is going to have to happen someday anyway.  Python 2.7 end of life is set to <a href="https://hg.python.org/peps/rev/76d43e52d978" target="_blank">2020</a>.  Seems like a long time, but it'll be here before we know it, and if we aren't prepared, it's going to be a world of hurt.</div><div><br></div><div>Why does this help us on Windows?  Visual Studio 2015, which releases sometime this year, is <a href="http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx" target="_blank">finally set to have a stable ABI</a> for it's CRT.  This means that any application compiled against VS2015 or later will be forward compatible with future versions of the CRT <a href="https://mail.python.org/pipermail/python-dev/2014-June/134888.html" target="_blank">forever</a>.  Python 3.5 is not yet released, but the <a href="https://mail.python.org/pipermail/python-dev/2014-June/134866.html" target="_blank">current proposal is for Python 3.5</a> to ship its binary release compiled with VC++ 2015, effectively killing this problem.</div><div><br></div><div>I understand that there is a lot of out-of-tree code that is written against Python 2.7.  I would encourage the people who own this code to begin thinking about migrating to Python 3 soon.  In the meantime, I believe we can begin to address this in-tree in 3 main phases.</div><div><br></div><div>1) Port the test suite to Python 3.5, using a subset of Python 3.5 that is also compatible with 2.7.  This ensures no out of tree code is broken.</div><div>2) Upgrading ScriptInterpreterPython with preprocessor flags to select whether you want to link against Python 2.7 and 3.5, and expose these options from CMake and Xcode so you can choose what you link against.</div><div>3) Making multiple buildbots with different configurations and different versions of Python to get better code coverage to ensure that tests work under both language versions.</div><div><br></div><div>I realize that the impact of both of these changes is high, but we have a very strong desire to solve this problem on Windows and so we need to push some kind of solution forward.  I think both solutions actually contribute to the long term benefit of LLDB as a whole, and so I think it's worth seriously considering both of these and trying to come up with a path forward.</div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div></div><div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><br><table cellspacing="0" cellpadding="0" style="font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Vince Harron |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Technical Lead Manager |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 858-442-0868</td></tr></tbody></table><br></div></div>
</div></blockquote></div>