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

Zachary Turner zturner at google.com
Wed Feb 25 10:35:01 PST 2015


Just to be clear, with solution #1 proposed in the original message, then
your option #3 is guaranteed to work.  (also, minor pedantic nit - it's VC
2008, not 2009).  You won't have to build python, it will literally just
work.  The reason for this is that I will have the CMake build
automatically compile the separate shared library with Microsoft's
toolchain whose sole purpose in life is to build python extension modules
<https://www.microsoft.com/en-us/download/details.aspx?id=44266> that
interoperate with the binary release of python 2.7

On Wed, Feb 25, 2015 at 10:19 AM Ted Woodward <ted.woodward at codeaurora.org>
wrote:

> I’m all for making it simpler. Believe me, coming up with my solution was
> a pain. But once I built Python, I was done with that part. We save off the
> binaries/modules, build against them, then copy them into the lib
> directory. I’ve got a patch that lets the builder set a default PYTHONHOME
> and PYTHONPATH in cmake, and if they don’t exist when LLDB is run it sets
> them in the environment based on the defaults.
>
>
>
> We need to build Python on Windows with VS2013 because the binaries from
> python.org are built with VS 2009, and will cause crashes in LLDB built
> with VS2013 because of incompatibilities between the 2009 C++ library and
> the 2012 C++ library. Our options seem to be:
>
> 1)      Build Python and save an artifact
>
> 2)      Require everyone build Python
>
> 3)      Separate the Python interface into its own shared library and
> hope that when it calls the 2009 C++RT it won’t crash
>
>
>
>
>
> I went for #1 for Hexagon LLDB because I couldn’t rely on the user having
> the correct Python installed, on Windows or Linux.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Zachary Turner [mailto:zturner at google.com]
> *Sent:* Wednesday, February 25, 2015 11:47 AM
> *To:* Ted Woodward; Reid Kleckner; Vince Harron
>
>
> *Cc:* lldb-dev at cs.uiuc.edu
> *Subject:* Re: [lldb-dev] RFC: Separation of embedded Python from the
> rest of LLDB.
>
>
>
>
>
> On Wed, Feb 25, 2015 at 9:39 AM Ted Woodward <ted.woodward at codeaurora.org>
> wrote:
>
>
>
> Saying you can’t build Python with VS2013 isn’t true. I did. I’m having
> issues with some of the bindings (specifically “print lldb.debugger” gives
> “No value”, even though it’s there), but for the most part it works.
>
> Well sure, I did too.  As it's the only way to run tests.  I think his
> point is just that it's a big barrier to entry.  I've got 3 guys who sit
> around me.  One works on the windows linker, and the other two are
> responsible for much of clang-cl.  None of them feel like going through
> these hoops to build LLDB, even though there's bugs in LLDB on Windows that
> their expertise would be a great asset in making some progress on.
>
>
>
> I mean yes I could do it for them, and yes they could ultimately do it
> themselves, but the point is that it shouldn't be this difficult.  What
> about people without the same amount of technical background, but who still
> want to hack around on the debugger?  I dont' want to discourage anyone
> from being able to work on the project.  Barriers close doors. I want the
> doors to be open.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150225/38759c97/attachment.html>


More information about the lldb-dev mailing list