[lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

Zachary Turner via lldb-dev lldb-dev at lists.llvm.org
Thu Mar 7 12:55:03 PST 2019


Yes, Pavel pointed out one specific case where it is used, and that case
definitely needs to be supported.

We've talked in the past about fixing the layering in such a way that all
Python related code is in ScriptInterpreterPython, but there's definitely a
non-trivial amount of work needed to make that possible.  And I agree, if
that were the case today, then you could just turn it off trivially.

On Thu, Mar 7, 2019 at 12:48 PM Jim Ingham <jingham at apple.com> wrote:

>
>
> > On Mar 7, 2019, at 11:37 AM, Zachary Turner <zturner at google.com> wrote:
> >
> >
> >
> > On Thu, Mar 7, 2019 at 11:03 AM Jim Ingham via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > Even though you can just use debugserver/lldb-server and debug remotely,
> many people find it handy to be able to run a debugger directly on the
> device they are using.  But requiring that you port Python and bundle it
> with your embedded platform just to get a debugger there is a pretty big
> ask.  So it is still quite useful to be able to build lldb without Python.
> This option hasn't been broken all that frequently in our uses, but if it
> is being a problem, the better solution would be to set up a bot to build
> with this option, so we can make sure it keeps working.
> >
> > That's true, but there's a maintenance burden associated with this
> handiness, and if nobody uses it that much (or at all?), it's better IMO to
> optimize for low maintenance.  Every time I've tried this configuration it
> has been broken, which leads me to believe that in practice nobody is
> actually using it.  If that really is the case, I'd rather it be gone.  I
> don't think we should keep code around just in case, without specific
> evidence that it's providing value.
>
>
> It does get used, though we might be able to get away from that at some
> point.  But I still think requiring any new platform that might want to run
> a debugger to get Python up first is unfortunate, and we shouldn't lightly
> require it.
>
> But also, this isn't just about Python in particular.  Everything in lldb
> that touches the script interpreter should be going through the abstract
> ScriptInterpreter class.  The only place where the fact that the script
> interpreter happens to be Python should show up is in the
> ScriptInterpreterPython.  So building without Python should be as simple as
> not building the ScriptInterpreterPython and not initializing that plugin.
> The maintenance burden for this option should be trivial.  Something is
> broken that LLDB_DISABLE_PYTHON has gotten entangled deeper in lldb.  I'd
> much prefer we fix that.
>
> It would be really cool, for instance, if lldb could support a Python2 and
> a Python3 script interpreter to ease the transition for folks with lots of
> legacy Python 2 code (such folks exist).  lldb was designed to support that
> sort of thing.
>
> Or maybe at some point we should support some other new hotness language.
> I'm not sure it is good to bind ourselves inextricably to Python.
>
> Jim
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190307/e1e2ce19/attachment.html>


More information about the lldb-dev mailing list