[lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

[Zachary Turner via lldb-dev]

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>