Issue |
108729
|
Summary |
[lldb][rfc] rebuilding `_lldb`/`liblldb.so` for different Python versions quickly
|
Labels |
new issue
|
Assignees |
|
Reporter |
arcivanov
|
The LLDB's Python package is (generally) as follows:
```bash
$ pwd
/usr/lib64/python3.12/site-packages/lldb
$ tree -I __pycache__
.
├── embedded_interpreter.py
├── formatters
│ ├── attrib_fromdict.py
│ ├── cache.py
│ ├── cpp
│ │ ├── gnu_libstdcpp.py
│ │ ├── __init__.py
│ │ └── libcxx.py
│ ├── __init__.py
│ ├── Logger.py
│ ├── metrics.py
│ └── synth.py
├── __init__.py
├── lldb-argdumper -> ../../../../bin/lldb-argdumper
├── _lldb.cpython-312-x86_64-linux-gnu.so -> ../../../liblldb.so <**************
├── _lldb.so -> ../../../liblldb.so.18.1.8
├── plugins
│ ├── __init__.py
│ ├── operating_system.py
│ ├── scripted_platform.py
│ └── scripted_process.py
└── utils
├── in_call_stack.py
├── __init__.py
└── symbolication.py
5 directories, 21 files
```
Out of all, the `_lldb` is the only native extension and it is actually the `liblldb.so`.
Which Python is used is determined by setting `PYTHON_HOME` during the initial `cmake` run.
I'd like rebuild that extension, i.e. `liblldb.so`, quickly for different versions of Python, since if I just reconfigure `cmake` with a different version of Python it'll make me rebuild the whole clang and lldb too and it will take hours and even worse if I have a 2-stage build (then it'll take days).
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs