mgorny marked an inline comment as done.
mgorny 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)
----------------
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.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D67890/new/
https://reviews.llvm.org/D67890
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
