Restoring build with LLDB_DISABLE_PYTHON

I wanted to try out a Python-less lldb, and found one build error. Is
it fine to just remove the ePathTypePythonDir case in GetLLDBPath for
LLDB_DISABLE_PYTHON, as below?

Incidentally, I'm curious about how widely used LLDB_DISABLE_PYTHON
is. For FreeBSD we'd eventually like to bring lldb into the base
system, so having it be usable without Python is very interesting to
us.

diff --git a/source/Host/common/Host.cpp b/source/Host/common/Host.cpp
index bbe87ba..ba8367b 100644
--- a/source/Host/common/Host.cpp
+++ b/source/Host/common/Host.cpp
@@ -1011,6 +1011,7 @@ Host::GetLLDBPath (PathType path_type, FileSpec
&file_spec)
         }
         break;

+#ifndef LLDB_DISABLE_PYTHON
     case ePathTypePythonDir:
         {
             static ConstString g_lldb_python_dir;
@@ -1053,7 +1054,8 @@ Host::GetLLDBPath (PathType path_type, FileSpec
&file_spec)
             return file_spec.GetDirectory();
         }
         break;

I wanted to try out a Python-less lldb, and found one build error. Is
it fine to just remove the ePathTypePythonDir case in GetLLDBPath for
LLDB_DISABLE_PYTHON, as below?

Yes, your solution is correct below.

Incidentally, I'm curious about how widely used LLDB_DISABLE_PYTHON
is. For FreeBSD we'd eventually like to bring lldb into the base
system, so having it be usable without Python is very interesting to
us.

We use this at Apple on a regular basis.

As Greg said, we are actively using the Python-less build of lldb in one configuration at Apple so it should build and work fine, I'm a little surprised that the build failure you hit didn't affect our build.

One thing to think about is that lldb users typically adopt the python scripting interfaces and build up collections of custom commands/formatters. For new lldb users, lack of Python is not important - but once people have grown familiar with its capabilities, the lack of Python will be a real drag for them.

There's also a bit of refactoring needed for some of lldb's built in type summaries/synthesizers for the C++ standard libraries - there is no real dependance on Python in this code but they are intermixed with the Python-interface code so much that LLDB_DISABLE_PYTHON builds will be missing most of them. This is a known problem that need to be fixed.

I agree, but this is only for our base system; in the worst case the
user can just install (a second copy of) lldb from a package or the
ports tree, and it will bring along Python. Ideally though I'd like
to be able to build with Python support but have it handle a missing
python .so at runtime, so that the user can later install Python and
have it "just work."