[Lldb-commits] [PATCH] D67583: Fix swig python package path

Fri Sep 20 11:11:16 PDT 2019

hhb added a comment.

In D67583#1676531 <https://reviews.llvm.org/D67583#1676531>, @labath wrote:

> I could be off mark here, but I do recall some people trying to get this code to work in environments where python and lldb(llvm) are configured with different libdirs (so LLVM_LIBDIR_SUFFIX in llvm, and `configure --prefix=X` in python). Is that the case you're running into here?
>
> If that is something we want to support (personally, I would very much like to just declare that "unsupported", but maybe we don't have that luxury). Then we'll need to be super careful about distinguishing the _llvm_ libdir name (i.e. the place where liblldb and friends should go to) from the _python_ libdir (the destination for the site-packages stuff). I think the code already partially tries to do that, but I am not sure if it is really correct.
>
> Since I'm already complaining about python paths, I'll add that the way we currently compute the python path is wrong for cross-compilation. (Because it will pick up the path from the host python, not the target one.) If we're going to be changing something here, it would be nice to fix that too (which, I hope, will also allow us avoid needing to keep multiple places in sync).

I also realized that this is totally wrong for cross-compilation. We are doing cross compilation to windows with MinGW so I need to fix that.

Actually I don't know why we need get_python_lib(). From what I can see now, the 3 paths should match:

1. finishSwigPythonLLDB.py write necessary files to ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/distutils.sysconfig.get_python_lib()

2. lldb/scripts/CMakeLists.txt copies them to lib${LLVM_LIBDIR_SUFFIX} (if not xcode)

3. ScriptInterpreterPython.cpp adds the right path into PYTHONPATH.

As long as these 3 paths matches, we are good. Then why not simply put everything into ${liblldb path}/site-packages for all platforms?

(I'm gonna make a change to test that. But let me know if anything is obviously wrong.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67583/new/

https://reviews.llvm.org/D67583