Global lldbinit file?

Subprojects LLDB
1

Ahh, I was conflating the issue of PYTHONHOME/PYTHONPATH with that of the global init file, but they solve different problems.

One thing I’m curious to see how your PYTHONHOME/PYTHONPATH patch addresses is that of number of CMake variables. I already have to set 3 CMake variables just for python. PYTHON_LIBRARY, PYTHON_EXECUTABLE, and PYTHON_INCLUDE_DIR. I’m not too crazy about having to set 2 more in addition to these. Unfortunately CMake’s FindPythonLibs package doesn’t work correctly on Windows, so there’s not a good workaround for having to set all these variables manually other than to just not use the package.

2

I don’t set any of those on my Windows builds. cmake 2.8.11.2 finds my python in c:\python27. I took a standard install and replaced the supplied binaries with the ones I built using VS 2013, and added the debug binaries for debug builds.

3

Yes, the problem is when you have multiple pythons. For example I have python on my system for doing actual python development unrelated to LLDB, and for that i want a regular release distribution, not the debug version i’ve compiled myself. FindPythonLibs finds the installed version though.

FindPythonLibs also doesn’t work correctly for 64-bit builds, because it only looks in the Wow64 registry key, so if you’ve installed x86 and x64 pythons, it will never find the x64 one.

We need to handle this case, because due to the requirement that you build your own python, it’s going to be very common that people will not want to use the same python they’re using for LLDB as other types of python development.

4

FWIW, this is partly why I had the idea for like an LLDB_PYTHON_HOME environment variable.

  1. CMake could look for it and (if found) skip the FindPythonLibs codepath entirely, setting the PYTHON_INCLUDE_DIR, PYTHON_LIBRARY, and PYTHON_EXECUTABLE appropriately to files / folders located under your %LLDB_PYTHON_HOME% path. So for people who compile LLDB themselves and then run, both the compile step and the run step would “just work” with no extra setup.
  2. It also works for running LLDB on a system other than the one it was compiled on, because you can point LLDB to any version of python on your system via a 1-time export.

Although long term, I like Greg’s idea of moving towards something bundle-like for Linux / Windows.