[lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

[Adrian McCarthy via lldb-dev]

OK, thanks all for the discussion.

I'll try to fix the immediate problems (the build breakage and the Python
detection).  If I get more ambitious, I'll make another proposal.

On Thu, Mar 7, 2019 at 12:55 PM Zachary Turner <zturner at google.com> wrote:

> 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/30e68b28/attachment-0001.html>