[Lldb-commits] [PATCH] D67890: [lldb] [cmake] Fix installing Python modules on systems using /usr/lib

Michał Górny via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Sep 23 06:27:46 PDT 2019

mgorny marked an inline comment as done.
mgorny added inline comments.

Comment at: lldb/scripts/CMakeLists.txt:45-50
+  execute_process(
+        -c "import distutils.sysconfig, sys; print(distutils.sysconfig.get_python_lib(True, False, sys.argv[1]))"
+        ${CMAKE_BINARY_DIR}
labath wrote:
> mgorny wrote:
> > labath wrote:
> > > For my own education, is it possible that the result of the `get_python_lib` call will fundamentally differ depending on the value of the third argument. I.e., is there any case where `${SWIG_PYTHON_DIR}` will be different from `${CMAKE_BINARY_DIR}/${SWIG_INSTALL_DIR}` ?
> > The former will be an absolute path while the latter is just the relative path. But if you mean whether they could have a different tail: I don't think so, at least with CPython. PyPy had some nasty logic, so I'd have to check if we ever decided to support that.
> Right now that doesn't matter, but I am thinking ahead about the cross-compilation case. If we turn out to need a cache variable for this, it would be nice if it would be a single variable that the user could set (instead of two of them). For that to work, we'd need to be able to compute the result of one of these calls using the value of the other one.
I suppose you mean having a variable specifying path relative to prefix/build dir, I presume? I suppose we could build the whole thing around a cache var defaulting to the sysconfig call as proposed here for `SWIG_INSTALL_DIR` (note it's passing empty prefix to `get_python_lib()` in order to get relative path).

Thinking about it, maybe it'd indeed be better for me to prepare a more complete patch built around that, and focus on testing that instead. I was mostly worried/confused by Linux-specific code hanging around.



More information about the lldb-commits mailing list