Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

The lldb_cmake GreenDragon bot is now failing, e.g.:

http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e

This looks related to Pavel's change:

r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines

Default to using in-tree clang for building test executables

Summary:
Using the in-tree clang should be the default test configuration as that
is the one compiler that we can be sure everyone has (better
reproducibility of test results). Also, it should hopefully reduce the
impact of pr35040.

This also reduces the number of settings which control the compiler
used. LLDB_TEST_C_COMPILER is used for C files and
LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
the in-tree clang.

Reviewers: zturner

Subscribers: mgorny, davide, lldb-commits

Differential Revision: https://reviews.llvm.org/D39215

The error is:

CMake Error at tools/lldb/CMakeLists.txt:78 (message):

  LLDB test compilers not specified. Tests will not run

Does the bot need to be reconfigured for these changes?

Jim

I hit the same problem last week. I ended up blowing away my build directory, and the problem went away.

Probably a cache issue, but I was unable to reproduce…

You probably just need to nuke the build folder.

The reason for that is that before the patch the LLDB_TEST_C_COMPILER
variable was used for a different purpose (and usually empty), where
as now it's set by default to the in-tree clang. However, cmake will
not overwrite the cached value by design. (I could have worked around
that in cmake, but I only noticed that issue after landing the
change.)

Erasing the build folder should let the new and correct default kick
in. If you run the check-lldb target then it will now use the in-tree
clang instead of the system compiler for using tests.

sorry about the trouble,
pl

NP, I'll find somebody who can initiate a clean rebuild.

Jim

We had the same problem internally on our bots. A clean build blew away the cmake caches and fixed the problem.

Ted

Good news. I got somebody to kick the llvm.org bots, so sounds like this should solve the problem.

Jim

In general, please try to structure changes so that CMake cache clobbers aren’t necessary. If you introduce changes that require clobbers by accident, consider adding some temporary CMake logic to help buildbots recover on their own. Some temporary CMake hacks can save a lot of time across all the folks that have to discover and debug this problem.

Yea, adding a FORCE for a day or two and then removing the FORCE several days later is a good way to handle this kind of thing.