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

[Pavel Labath via lldb-commits]

On 26/04/2019 19:34, Jim Ingham wrote:
> 
> 
>> 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.

No that part doesn't seem too controversial. My point just was that if 
we're going to keep the SBHostOS method working for backwards compat, 
then we might as well have it be the only way of retrieving the python 
path for now.

OTOH, if you are actually getting to a point where you need to "select" 
a script interpreter, then doing this now sounds like a natural step (I 
know you want to make the python version selectable at runtime, but I 
have no idea how exactly do you intend to achieve that).


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

I suppose XCode could just launch two lldb binaries instead of one, and 
choose the process to host a debug session depending on the requested 
python version (?)

pl