RFC: Separation of embedded Python from the rest of LLDB.

IMHO -

What needs to work in the end - and needs to be easy is this:

Inside the debugger - (gui driving the debugger) a user (customer) of LLDB - should be able to create a “mash-up” of two or more python prebuilt modules and accomplish things.

For example: script extract data in target memory and give to a pre-built Python image processing DLL - Other debuggers have this today (Example: Analog Devices DSP tools - can show a neat graphic, ARM DS5 tools can show analog wave forms of an array of data memory)

Other examples are SciPy, or Numpy, etc … You might want to halt & read physical memory and display hardware data structures (ie: Think of a clock distribution tree, or a signal processing tree - you could populate a block diagram (PNG image) with values from your system and make that image mouse-clickable

Mashups make tools powerful

That customer of LLDB is not a “build-wizard” for LLDB - she (or he) is your customer, and they are not a build-wizard for the other tool; and that other tool might be dll only no source.

Maybe the solution is (N) instances of LLDB, ie: LLDB_PY27.dll, and LLDB_PY35.dll for (N) different standard well known versions of python.

-Duane.