| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x, but for Python
3.x there are some important changes. Primarily, these are:
1) PyString doesn't exist in Python 3. Everything is a PyUnicode.
To account for this, PythonString now stores a PyBytes instead
of a PyString. In Python 2, this is equivalent to a PyUnicode,
and in Python 3, we do a conversion from PyUnicode to PyBytes
and store the PyBytes.
2) PyInt doesn't exist in Python 3. Everything is a PyLong. To
account for this, PythonInteger stores a PyLong instead of a
PyInt. In Python 2.x, this requires doing a conversion to
PyLong when creating a PythonInteger from a PyInt. In 3.x,
there is no PyInt anyway, so we can assume everything is a
PyLong.
3) PyFile_FromFile doesn't exist in Python 3. Instead there is a
PyFile_FromFd. This is not addressed in this patch because it
will require quite a large change to plumb fd's all the way
through the system into the ScriptInterpreter. This is the only
remaining piece of the puzzle to get LLDB supporting Python 3.x.
Being able to run the test suite is not addressed in this patch.
After the extension module can compile and you can enter an embedded
3.x interpreter, the test suite will be addressed in a followup.
llvm-svn: 249886
|
|
|
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.
This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.
Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.
Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton
llvm-svn: 243681
|
