[Interest] Qt 5 Creator (Mac) Debugger should use the system python executable

[André Pönitz]

On Thu, Feb 05, 2015 at 10:33:09AM +0100, René J.V. Bertin wrote:
> On Thursday February 05 2015 08:22:09 Harri Pasanen wrote:
> 
> >> llbd script "run our script"
> >>
> >> but that doesn't strike me as very elegant either.
> >>
> >
> >If it is a long running script, it seems quite elegant to me, as I solves
> >the correct python selection as André mentioned.
> 
> Maybe "elegant" wasn't the best choice of words.  The context is of course a
> GUI interface that communicates with lldb through some kind of python
> interface. Depending on how exactly that communication is set up (and python
> started) it might not be straightforward to replace the python call with a
> call to lldb that then needs to be sent a command to start the python
> interpreter, which may not be prepared to handle a non-interactive terminal.
> I haven't had time to look at what exactly goes on in Creator's code.

...

> But for instance, I tried `lldb -o script` and on OS X that got me in a
> Python-prompt-printing dead loop which required me to killall -1 lldb. On
> Linux lldb reacts differently: I get into the Python interpreter after
> sending an EOF (^D), but then every Python expression I tried led to a core
> dump.

I would take that as an indication that this is not the approach taken.
 
> It does seem however that sys.executable points to the correct python
> executable (checked only on Linux).

Invoking sys.executable inside LLDB does not reliably produce a Python
executable usable with that LLDB. Not even on Linux.

> Which leads me to another thought I can't verify ATM because not on a Mac:
> does Qt Creator allow selection of the lldb executable to use?

Yes.

You don't need a Mac to verify. You can have use different executables on
all supported platforms.

> It's not at
> all uncommon to have different versions, and of course each will require the
> use of its own python executable.

The point of invoking LLDB first is to not have to care where its Python
support infrastructure lives.

Andre'