[Lldb-commits] [PATCH] D61090: [SBHostOS} Remove getting the python script interpreter path

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Apr 25 10:27:12 PDT 2019

labath added a comment.

In D61090#1479004 <https://reviews.llvm.org/D61090#1479004>, @jingham wrote:

> I'm a bit confused.  If we get to the world where we can support multiple script interpreters, I would expect to add a static method on ScriptInterpreter that enumerates the available interpreters.  I would not expect that to be on SBHostOS since this is not a feature of the Host OS but of how lldb was configured.  An lldb running on macOS with the Python2 plugin available behaves - w.r.t. macOS  - exactly the same as one built with a Python3 plugin available, etc.
> So the "available languages" query for sure seems to me to belong as a static method on the ScriptInterpreter class.  But then once I've requested a particular script interpreter, asking it where it put the lldb module seems much more natural than going to the HostOS.  Under the covers, we will need to cooperate with the HostOS since that knows how lldb is packaged for a particular system.  But that doesn't seem like something we need to have users know.

That also sounds pretty reasonable, especially if we want to do other things with the enumerated script interpreters besides getting their "module paths". The only thing is that there isn't a *Script*Interpreter class at the SB level. There is a *Command*Interpreter (which is what this patch is using), but that does not sound completely right to me as there is more to scripting languages than just the "script" command (in fact, I think the main reason that python layering is so hard to get right is that it has a dual role -- python is both embedded into lldb, and it also can be used to drive lldb from the outside).



More information about the lldb-commits mailing list