<div dir="ltr">OK, thanks all for the discussion.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 7, 2019 at 12:55 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Yes, Pavel pointed out one specific case where it is used, and that case definitely needs to be supported.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 7, 2019 at 12:48 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Mar 7, 2019, at 11:37 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> <br>
> <br>
> <br>
> On Thu, Mar 7, 2019 at 11:03 AM Jim Ingham via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> 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.<br>
> <br>
> 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.<br>
<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Jim<br>
<br>
</blockquote></div>
</blockquote></div>