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.woodw...@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:ztur...@google.com] > *Sent:* Wednesday, February 25, 2015 11:47 AM > *To:* Ted Woodward; Reid Kleckner; Vince Harron > > > *Cc:* lldb-dev@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.woodw...@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. >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
