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

[Ted Woodward]

The icon for pcbuild.sln has a 9 in it; I assumed that meant VS 2009. Silly me :)

 

I’m not confident that a DLL built with VS 2008 that has any C++ code will not crash when loaded into a program built with VS2013, because of the incompatible C++ library issue.

 

How do we get around the debug-vs-release issue that makes us have python27_d.dll on a debug build right now?

 

--

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 12:35 PM
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.

 

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 <mailto: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 <http://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 <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 <mailto: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 <mailto: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/be89ce5d/attachment.html>