[Lldb-commits] [lldb] r213158 - Add kalimba as a platform.
tfiala at google.com
Thu Jul 17 09:34:53 PDT 2014
I'm thrilled that you are trying to get a test Linux box up!
The easiest way to run that depends on whether you're using cmake/ninja or
configure/make. If you don't have a strong preference, going with
cmake/ninja is definitely the faster way to go.
In any event, you'll want to kick off the tests with either one of these,
after you've done a full build (i.e. 'ninja' in the build dir or 'make' in
the build dir):
Both those incantations will get you a test run that does the tests without
you needing to set up anything else (e.g. lldb/python paths, or
architecture settings for the test run). They'll also run the tests faster
if you have multiple cores on your dev box/VM.
Let me know if you hit any trouble with that. Particularly the cmake
configuration line - the basic cmake configuration line with minimal
options has never worked well for me on Linux, so I call it with a bunch of
flags to specify the llvm build type and a few other details.
On Wed, Jul 16, 2014 at 11:28 PM, Matthew Gardiner <mg11 at csr.com> wrote:
> Todd Fiala wrote:
>> Hi Matthew,
>> One thing you might want to consider doing is adding a test to verify
>> Kalimba ObjectFileELF parsing doesn't regress using this test here:
> Ok, I see what you mean. It should be pretty easy for me to get a kalimba
> binary in there, and I'll figure out TestImageListMultiArchitecture.py in
> a bit.
> Regarding testing in general, I wanted to pick your brains. Basically I'm
> trying (in addition to the rest of my day job!!!!) to get a box setup to
> run lldb test suite. I've started doing some research...
> First off, would I be correct in saying that the whole of test-suite is
> fired off by running test/dotest.py ?
> So when I try to run dotest.py I get:
> $ PATH=$PATH:~/src/main/build/Debug+Asserts/bin/ ./dotest.py -v .
> This script requires lldb.py to be in...
> I remember the "[lldb-dev] Where is lldb.py?" thread and read it,
> determining that I then should run a generate script
> (buildSwigWrapperClasses.py). But this just results in a lot more pain:
> Running from ~/src/main/llvm/tools/lldb/scripts
> $ ./buildSwigWrapperClasses.py --srcRoot=~/src/main/llvm/tools/lldb
> --targetDir=~/src/main/build/Debug+Asserts/lib --cfgBldDir=. -m -d
> ....lots of errors above...
> ./buildSwigWrapperClasses.py: line 109: syntax error near unexpected token
> ./buildSwigWrapperClasses.py: line 109: `def get_help_information():'
> and error 2 is returned to the shell.
> I think I'm missing something fundamental here. I *think* it has to do
> with swig not getting run or something. So I see that there is a sub-dir
> called Python with a buildSwigPython.py file, but the comment in main say
> this code should not be called directly. I have swig 2.0.11 and python
> 2.7.5 on the box (FC-20 x86_64).
> Can you see anything obvious I'm doing here? Or do you have a simpler
> recipe for building lldb.py?
> I appreciate you're probably off to bed now :-) but if you have any tips
> you could send me tomorrow I'd really appreciate it!
> Member of the CSR plc group of companies. CSR plc registered in England
> and Wales, registered number 4187346, registered office Churchill House,
> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Keep up to date with CSR on
> our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
> YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> New for 2014, you can now access the wide range of products powered by
> aptX at www.aptx.com.
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits