[lldb-dev] RFC: Separation of embedded Python from the rest of LLDB.

[Zachary Turner]

I agree with you for the most part, including that the code separation has
the lowest impact.  But it's worth mentioning that here, EOL for VC++ 2008
is 2018
<https://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Visual+Studio+2008&Filter=FilterNO&wa=wsignin1.0>.
So while technically moving to 3.x is not anyone else's problem until 2020,
the fact that it's going our problem 2 years earlier means we will have to
do something about it by then.  And at that point, 3.5 is going to be the
only option on the table.  We don't need to take action now, but we should
start thinking about it.  Luckily the part we care about isn't much.
 there's 4 or 5 python scripts to port and maintain in compatibility mode.
And I suspect (hope) that by that time the people with the out of tree 2.7
code will be starting to do something about it.

In any case, I'm mostly taking issue with your statement that "Reducing the
number of obscure ways that non-Windows developers can break the Windows
build is good".  We shouldn't be thinking of Python 3.5 in this context as
"the windows build".  It's probably going to be "the build" eventually.

On Wed, Feb 25, 2015 at 8:58 AM Reid Kleckner <rnk at google.com> wrote:

> On Wed, Feb 25, 2015 at 5:58 AM, Vince Harron <vharron at google.com> wrote:
>
>> This seems like a lot of work to support Windows users who might want to
>> use pre-compiled python modules.
>>
>
> To me, the primary benefit is that you can build LLDB with Python support
> without building Python from source. More onerous, once you build Python
> from source, you have to maintain two separate environments: your normal
> development environment with normal Python on PATH, and one with LLDB's
> version of Python on PATH and PYTHONPATH.
>
>
>> I think we should distribute a VS2015 based version of Python 2.7
>> binaries and call it a day.
>>
>> We can worry about 2020 problems in 2020.  =)
>>
>> Reasonable people may disagree.
>>
>
> I disagree. I guess that makes me reasonable. ;)
>
> The main thing for me is that once we put together a pre-built Python, the
> instructions to rebuild it will immediately rot. In a matter of months,
> some user will arrive needing LLDB and Python to be built with a different
> VS version, and I give it 50/50 odds that the instructions will work.
>
> Personally, I think the lowest impact change for everyone not affected by
> this is to split the Python API code out into a shared library. LLDB has
> more Python source than C++ source interacting with Python. Maintaining
> Python source compat with 2.7 and 3.5 will be fragile and will require
> testing more configurations. Reducing the number of obscure ways that
> non-Windows developers can break the Windows build is good.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150225/72e59b95/attachment.html>