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

[Siva Chandra]

================
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'],
----------------
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]))

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:236
@@ -236,1 +235,3 @@
             build_type,
+            test_arch=None,
+            test_compilers=None,
----------------
Plural test_archs is probably more indicative of the fact that a sequence is expected.

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:246
@@ +245,3 @@
+    if test_arch is None:
+        test_arch={}
+    if test_compilers is None:
----------------
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 {}.

================
Comment at: zorg/buildbot/builders/LLDBBuilder.py:248
@@ -244,1 +247,3 @@
+    if test_compilers is None:
+        test_compilers={}
 
----------------
chying wrote:
> sivachandra wrote:
> > You should probably check for presence of clang, gcc or cc in that order and default a test compiler to that.
> Same as above. If no test_compilers were specified, lldb-test will be skipped
Same as my comment with test_arch.

================
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,
----------------
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?

http://reviews.llvm.org/D8335

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