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

Ying Chen chying at google.com
Mon Mar 16 12:36:36 PDT 2015

Comment at: buildbot/osuosl/master/config/builders.py:722
@@ -722,1 +721,3 @@
+                    test_arch=['x86_64', 'i386'],
+                    test_compilers=['clang', 'totclang', 'gcc4.8.2'],
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. 

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

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

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:
> 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.



More information about the llvm-commits mailing list