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

[Jim Ingham via lldb-commits]

> On Apr 26, 2019, at 1:29 AM, Pavel Labath via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> labath added a comment.
> 
> In D61090#1479049 <https://reviews.llvm.org/D61090#1479049>, @jingham wrote:
> 
>> I really thought there was one at the SB layer, because in terms of design that is what makes sense.  I guess we never really needed it until now, so we didn't add it.  Once there's more than one hard-coded script interpreter, we will need to add some way to select & direct scripts at the various script interpreters so we will need SBScriptInterpreter at the SB layer.  So maybe now is the time to add it in preparation...
>> 
>> Also, the fact that at the lldb_private layer, the ScriptInterpreter is held onto by the CommandInterpreter is clearly wrong.  The CommandInterpreter should have a member that tells it the currently selected ScriptInterpreter, but the list of script interpreters should belong to the Debugger.  We should probably disentangle that at the same time.
> 
> 
> Yes, it sounds like we should have a SBScriptInterpreter at some point. Though, right now, it's not really clear to me what will it's exact role be, so I would tend to agree with Greg that we wait until we have a real use case for it (so we don't commit to a design we may want to change later).

At this point we could get away with adding is "SBDebugger::GetSelectedScriptInterpreter()" and "SBScriptInterpreter::GetLLDBScriptModulePath" - that would be sufficient to move the responsibility for finding this path to the correct place.  Those don't seem controversial to me.  I agree sketching in selecting interpreters and invoking scripts on the would not be a good choice till we have something more concrete to play with.  

> 
>> As an aside, IIUC, the current work to support either Python flavor only supports one interpreter at a time because Python doesn't support loading Python 2 & 3 into the same process?
> 
> I've heard someone say that, and I can believe that is the official party line of the python project, but I haven't investigated how "true" that statement is. E.g., I'm pretty sure we could get it to work by using some of the fancier flags of dlopen (RTLD_LOCAL, or the new namespace thingies present on linux), but that may take more effort than it's worth..
> 

Interesting.  If/when we get to supporting fairly different scripting languages, it will be important to be able to load them all to support "I got cool formatter in scripting language X from person A and another in language Y from person B and I need to use them in the same debugging session".  But for now it seems more likely you're either going to convert all your Python scripts from 2 -> 3 or leave them in 2, so this doesn't seem crucial for Python support.  The only use-case where this is slightly motivated is apps like Xcode that create many debug sessions in the same lldb binary.  This would force them to make a choice of 2 vrs. 3 for all sessions.

Jim


> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D61090/new/
> 
> https://reviews.llvm.org/D61090
> 
> 
>