[Lldb-commits] [PATCH] D59719: [ScriptInterpreter] Make sure that PYTHONHOME is right.

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Tue Mar 26 05:22:32 PDT 2019


labath added a comment.

In D59719#1442563 <https://reviews.llvm.org/D59719#1442563>, @davide wrote:

> In D59719#1441254 <https://reviews.llvm.org/D59719#1441254>, @labath wrote:
>
> > It sounds to me like you could achieve the same thing by generalizing the LLDB_PYTHON_HOME logic in LLDBConfig.cmake. This would have the advantage of centralizing the way we manage python-finding logic (instead of each OS doing it's own thing) and also enable those users, who know what they are doing, to override this logic and point lldb to a different python. (I don't know if there are any such users, but it does not sounds like an impossible scenario).
> >
> > I think all it would take is to do something like:
> >
> > - move LLDB_RELOCATABLE_PYTHON handling outside of `if(WINDOWS)`
> > - have the default value of `LLDB_RELOCATABLE_PYTHON` be `false` for darwin
> > - possibly tweak the python-finding logic so that it prefers the one in /System/Library/Frameworks/...
>
>
> Oh, this won't work with xcodebuild, I'm afraid.


Why not? The xcode build could hardcode the value for LLDB_PYTHON_HOME, just like you do here now. That could be done either in `lldb/Host/Config.h`, or by passing the appropriate `-D` flag to the compiler via the xcode project file. My preference would be to use lldb/Host/Config.h, and to also move the cmake build off of the explicit `-D`, and put this variable into Config.h.cmake as well.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D59719





More information about the lldb-commits mailing list