Some pythons are configured to set platlib somewhere outside of their
sys.prefix. It's important that we at least use some reasonable
default for LLDB_PYTHON_RELATIVE_PATH even in that case, because
even if the user overrides it on the cmake invocation, cmake will
still be called without the override in order to build tablegen.
Reviewed By: JDevlieghere, clayborg
Differential Revision: https://reviews.llvm.org/D114973
distutils is deprecated and will be removed, so we shouldn't be
using it.
We were using it to compute LLDB_PYTHON_RELATIVE_PATH.
Discussing a similar issue
[at python.org](https://bugs.python.org/issue41282), Filipe Laíns said:
If you are relying on the value of distutils.sysconfig.get_python_lib()
as you shown in your system, you probably don't want to. That
directory (dist-packages) should be for Debian provided packages
only, so moving to sysconfig.get_path() would be a good thing,
as it has the correct value for user installed packages on your
system.
So I propose using a relative path from `sys.prefix` to
`sysconfig.get_path("platlib")` instead.
On Mac and windows, this results in the same paths as we had before,
which are `lib/python3.9/site-packages` and `Lib\site-packages`,
respectively.
On ubuntu however, this will change the path from
`lib/python3/dist-packages` to `lib/python3.9/site-packages`.
This change seems to be correct, as Filipe said above, `dist-packages`
belongs to the distribution, not us.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D114106
see: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38387/console
```
Could not find a relative path to sys.executable under sys.prefix
tried: /usr/local/opt/python/bin/python3.7
tried: /usr/local/opt/python/bin/../Frameworks/Python.framework/Versions/3.7/bin/python3.7
sys.prefix: /usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7
```
It was unable to find LLDB_PYTHON_EXE_RELATIVE_PATH because it was not resolving
the real path of sys.prefix.
caused by: https://reviews.llvm.org/D113650
LLDB doesn't use only the python stable ABI, which means loading
it into an incompatible python can cause the process to crash.
_lldb.so should be named with the full EXT_SUFFIX from sysconfig
-- such as _lldb.cpython-39-darwin.so -- so this doesn't happen.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D112972
Apparently "{sys.prefix}/bin/python3" isn't where you find the
python interpreter on windows, so the test I wrote for
-print-script-interpreter-info is failing.
We can't rely on sys.executable at runtime, because that will point
to lldb.exe not python.exe.
We can't just record sys.executable from build time, because python
could have been moved to a different location.
But it should be OK to apply relative path from sys.prefix to sys.executable
from build-time to the sys.prefix at runtime.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D113650
Lawrence D'Anna