I have a standard source layout:
llvm
- src
- tools
- clang
- lldb
- build
- …
llvm/build$ ninja check-lldb
This script requires lldb.py to be in either llvm/src/tools/lldb/build/Debug/LLDB.framework/Resources/Python, llvm/src/tools/lldb/build/Release/LLDB.framework/Resources/Python, or llvm/src/tools/lldb/build/BuildAndIntegration/LLDB.framework/Resources/Python. Some tests might fail."
What do these 3 directories have to do with anything when my build directory is llvm/build, not llvm/src/tools/lldb/build ? & is this a manual step I’m meant to undertake? (could we automate it?)
(& the check-lldb target doesn’t have dependencies on all the tools required to run the tests either - which isn’t quite right (compared to check-llvm, check-clang, etc))
I really need to fix this error message, it hit Rafael last time too. Basically ignore it, the message is totally wrong. What does lldb -P say?
I really need to fix this error message, it hit Rafael last time too.
Well it did seem to be part of a longer error message, but perhaps they
were unrelated:
This script requires lldb.py to be in either
/mnt/fast/dev/llvm/src/tools/lldb/build/Debug/LLDB.framework/Resources/Python,
/mnt/fast/dev/llvm/src/tools/lldb/build/Release/LLDB.framework/Resources/Python,
or /mnt/fast/dev/llvm/src/tools/l
ldb/build/BuildAndIntegration/LLDB.framework/Resources/Python. Some tests
might fail.
Traceback (most recent call last):
File "/mnt/fast/dev/llvm/src/tools/lldb/test/dotest.py", line 1322, in
<module>
os.path.walk(testdir, visit, 'Test')
File "/usr/lib/python2.7/posixpath.py", line 238, in walk
func(arg, top, names)
File "/mnt/fast/dev/llvm/src/tools/lldb/test/dotest.py", line 1219, in
visit
suite.addTests(unittest2.defaultTestLoader.loadTestsFromName(base))
File "/mnt/fast/dev/llvm/src/tools/lldb/test/unittest2/loader.py", line
111, in loadTestsFromName
module = __import__('.'.join(parts_copy))
File
"/mnt/fast/dev/llvm/src/tools/lldb/test/lang/objc/objc++/TestObjCXX.py",
line 7, in <module>
import lldb
ImportError: No module named lldb
Basically ignore it, the message is totally wrong. What does lldb -P say?
$ ~/dev/llvm/build/clang/debug/split/notypes/nostandalone/bin/lldb -P
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/local/buildtools/current/sitecustomize/sitecustomize.py", line
181, in SetupPathsAndImport
return real_import(name, globals, locals, fromlist, level)
ImportError: No module named lldb.embedded_interpreter
/mnt/fast/dev/llvm/build/clang/debug/split/notypes/nostandalone/bin/../lib/python2.7/site-packages
I can probably help better in person. But this means it can’t load the lldb python extension module. Usually it’s in build/lib/site-packages/lldb and it should be a symlink to build/bin/liblldb.so. If that looks ok, I vaguely recall something about the lib suffix for 64 bit builds, but it’s not coming to me right now. Chandler probably remembers.
I can probably help better in person. But this means it can't load the
lldb python extension module. Usually it's in build/lib/site-packages/lldb
Don't have this directory - no mention of it in the build.ninja file -
though perhaps I haven't built some necessary target...
and it should be a symlink to build/bin/liblldb.so. If that looks ok, I
vaguely recall something about the lib suffix for 64 bit builds, but it's
not coming to me right now. Chandler probably remembers.
no worries - might have a play around with it tomorrow, then.
Just to be clear, it won’t be called “build”. “build” is the folder that your build.ninja is in. So I guess in your case, llvm/build/lib/site-packages/lldb. Assuming you already figured that out, then the last thing to check would be whether you got an error message at the very end of the build about finishSwigWrapperClasses.py. (Also something I need to fix, I should add this and the error message to my todo list). In your build.ninja, look for finishSwigWrapperClasses.py and run the command line it says there and see what it tells you. If you get an error, and part of the command line is cmakeBuildConfiguration=., then either manually change the . to Debug, or regenerate your cmake and explicitly specify -DCMAKE_BUILD_TYPE=Debug. (I’m not sure why it’s not detecting this automatically with some versions of CMake)