[lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON
Adrian McCarthy via lldb-dev
lldb-dev at lists.llvm.org
Thu Mar 7 13:19:14 PST 2019
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev