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 <jing...@apple.com> wrote: > > > > On Mar 7, 2019, at 11:37 AM, Zachary Turner <ztur...@google.com> wrote: > > > > > > > > On Thu, Mar 7, 2019 at 11:03 AM Jim Ingham via lldb-dev < > lldb-dev@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 > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
