[PATCH] Add support of multiple test compilers and architecture for LLDB cmake builder

[Ying Chen]

================
Comment at: buildbot/osuosl/master/config/builders.py:722
@@ -722,1 +721,3 @@
                     build_type="Debug",
+                    test_arch=['x86_64', 'i386'],
+                    test_compilers=['clang', 'totclang', 'gcc4.8.2'],
----------------
sivachandra wrote:
> chying wrote:
> > sivachandra wrote:
> > > Can we have two archs on the same build slave??
> > Yes, it's one of the test branches to run i386 build on x86_64 machine.
> > The test result of i386 build running on x86_64 vs. i386 build running on 32 bit machine might be different, so next step would be to run i386 build on 32 bit machine. 
> > 
> OK. Since getLLDBUbuntuCMakeBuildFactory is a generic utility, you should check whether the architectures listed are compatible in getLLDBUbuntuCMakeBuildFactory. For example, using x86_64 lldb to debug x86_64 binaries on i386 is fine. But, using i386 LLDB is probably not OK for debugging x86_64 binaries. You could for now keep something very simple like and stick to x86_64 and i386 like this:
> 
>     if platform.machine() == 'x86_64':
>         compatible_archs = ['x86_64', 'i386']
>         assert(all([x in compatible_archs for x in test_archs]))
This code will run on buildbot master machine, so it will return the machine architecture of master host. And assert will also fail on master side if any unsupported arch is specified.
The only way to run code on slave side is by factory.addStep(...). 
We need to create some script on the fly and invoke script on slave machine to achieve this.
I suggest to keep the code as is for now, and come back to this when we have more time.

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:246
@@ +245,3 @@
+    if test_arch is None:
+        test_arch={}
+    if test_compilers is None:
----------------
sivachandra wrote:
> chying wrote:
> > sivachandra wrote:
> > > This should be initialized with the default system architecture.
> > The thought was that if no test arch or compilers is specified, then lldb-test will be skipped.
> In which case, this should be noted in a comment near the function header. Also, instead of making test_arch={}, the intent is more obvious if you have something like this after you add the compile step:
> 
>     if not test_arch:
>         return
> 
> Note: Even if you end up keeping code as is, initializing to an empty list [] is more meaningful than an empty dict {}.
yes, i changed to empty list in the next revision.

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:303
@@ +302,3 @@
+        for arch in test_arch:
+            f.addStep(LitTestCommand(name="test lldb (%s-%s)" % (compiler, arch),
+                                     command=['../%s/tools/lldb/test/dosep.py' % llvm_srcdir,
----------------
sivachandra wrote:
> chying wrote:
> > sivachandra wrote:
> > > You should probably have a step which cleans up the source tree and the build tree after each test step. Side effects from a previous test run could potentially affect a consequent test run.
> > Since build/test is running in a separate build folder, and I checked that there's no files added or changed to source tree after running test.
> > But as you suggested, I will create separate output folder for each test so there's no possible interference.
> OK about the source tree. How about the build tree? Does running tests create any side effects in the build tree apart from lldb-test-traces?
I take back the statement that "there's no files added or changed to source tree after running test".
Actually there're *.pyc and some output files left in the source tree. 
I did not found these cause they're ignored by default.
Added step to clean these files in the next revision.

And yes, lldb-test-traces is the only side effect happened in build tree.

http://reviews.llvm.org/D8335

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/