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

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.


================
Comment at: lldb/scripts/CMakeLists.txt:45-50
+  execute_process(
+    COMMAND ${PYTHON_EXECUTABLE}
+        -c "import distutils.sysconfig, sys; print(distutils.sysconfig.get_python_lib(True, False, sys.argv[1]))"
+        ${CMAKE_BINARY_DIR}
+    OUTPUT_VARIABLE SWIG_PYTHON_DIR
+    OUTPUT_STRIP_TRAILING_WHITESPACE)
----------------
mgorny wrote:
> 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.
> I suppose you mean having a variable specifying path relative to prefix/build dir, I presume?
Probably something like that, though I am still kind of hoping that there will be some way to detect this from cmake. However, that is looking less and less likely the more time I spend looking for a way to do it.

> 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.
That could work too, though I think the current version is an improvement in itself, and I agree we should do this slowly.


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

https://reviews.llvm.org/D67890