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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
