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