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 <ztur...@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 <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
