/usr/bin/env is recommended as a cross-platform way to find python. But:
- we're only using lldb on darwin, where we know python (or at least,
the xcrun-style shortcut) is in /usr/bin/
- the python interpreter in LLDB comes from /S/L/F:
$ otool -L Contents/SharedFrameworks/LLDB.framework/LLDB | grep Python
/System/Library/Frameworks/Python.framework/Versions/2.7/Python
so when we use the lldb python module, it calls into the swig/python
support in the lldb framework, and if there's a mismatch between the
interpreter and the linked python, weird things occur.
In theory, I believe this should be done by:
- looking for the LLDB framework (llgdb.py does some of that)
- finding the binary inside the framework
- looking for the Python it was linked against (otool -L)
- finding the interpreter executable inside the Python.framework
But in practice, that's only different if we use a custom LLDB
framework/pythonpath when running these tests, and AFAIK nobody does
that right now, so the code would be dead anyway.
Don't pretend we can use any arbitrary python: just use the system one.
Differential Revision: https://reviews.llvm.org/D47967
llvm-svn: 334369
Summary:
Add cmake and lit files needed to run these tests as an
external project. Also, copy test_debuginfo.pl from llvm/utils since
it's only used here. The copy in llvm/utils must be maintained as
long as bots continue to include debuginfo-tests in clang/test.
This patch depends on clang patch https://reviews.llvm.org/D41055.
Reviewers: zturner, aprantl
Reviewed By: aprantl
Subscribers: mgorny, llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D40971
llvm-svn: 320495
Ahmed Bougacha