[PATCH] [Zorg] Adding test-suite to CMake ClangBuilder

Renato Golin renato.golin at linaro.org
Mon Jun 15 04:02:43 PDT 2015


About splitting the code, there are some factors to consider:

1. The test-suite needs some internal knowledge of what was the last build (stage1/2) and what is the compiler used. I can refactor the compiler name out, but I'm not sure how to do the same about what stage directory to use without leaking internal information through (ie. install directory name).
2. This builder will do more than just test. The goal is to have it building with and without all variations of libraries and tools (libgcc vs. compiler-rt, libstdc++ vs. libc++, ld vs. lld, stage1 vs. stage2, etc), and separating them apart may create a lot of interdependency between them (see item 1 above).

So, unless we do a big refactoring to the code, I'm not sure any effort in splitting it would do justice, or make it simpler. Mostly because I'm not great at Python to do it right...

If someone could help with the refactoring, I'd be glad to follow the pattern, but I'm afraid I can't create the pattern myself... :(


Comment at: zorg/buildbot/builders/ClangBuilder.py:693-694
@@ +692,4 @@
+        # Get latest built Clang (stage1 or stage2)
+        cc=WithProperties('%(workdir)s/'+compiler_path+'/bin/'+cc)
+        cxx=WithProperties('%(workdir)s/'+compiler_path+'/bin/'+cxx)
+        # LNT Command line
rnk wrote:
> I think ultimately the test suite will want the path to the gcc-compatible clang driver and not clang-cl. If and when we port it to Windows, we can figure out how to get clang-cl if we need it then. I'd suggest sinking the cc and cxx assignments above into the `if useTwoStage:` block and just using clang and clang++ here.
So, this cc/cxx depends on which was the last stage (1 or 2), while the previous usage is constant on stage1 build.

If I sink this before runTestSuite, I'll have to sink the other set, and I'll still have to reassign it here for the stage2 if necessary, duplicating the "if useTwoStage" conditional.

I'm not sure how keeping them separate could hurt checking for the correct compiler more than it already was. Ie. I don't really understand what the problem is, and I don't want to try to fix a problem I myself don't understand. By keeping it similar, it would be simpler for someone that understands the problem better to fix in the future.



More information about the llvm-commits mailing list