> 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
