[CMake] Remove LLDB_TEST_USE_CUSTOM_C(XX)_COMPILER

[JDevlieghere]

Summary

Given that LLDB_TEST_USE_CUSTOM_C_COMPILER and LLDB_TEST_C_COMPILER are both set at configuration time, I don't really see the point of having them both. This patch simplifies things and uses the custom C/C++ compiler when the variable is set, and uses the default one when it's not set, or explicitly set to the empty string (so that you can choose to switch back to using the default compiler).

[labath]

I agree that the USE variables seem redundant. I remember thinking the same thing when they were introduced, but I was not objecting back then because there seemed to be a good reason for it. However, now I don't know what that reason was... Tagging @stella.stamenova in case she does (I know it had something to do with multi-config generators and visual studio).

That said, I'm not a fan of force-overwriting cache variables specified by the user, particularly when the same effect can be achieved by *deleting* the cache variable instead of setting it to an empty string. I think you should be able to reset the default value of LLDB_TEST_C_COMPILER (just like any other cmake variable) by running cmake -ULLDB_TEST_C_COMPILER. You can even delete both variables at once with -ULLDB_TEST_*_COMPILER.

[JDevlieghere]

In D66429#1636655, @labath wrote:

That said, I'm not a fan of force-overwriting cache variables specified by the user, particularly when the same effect can be achieved by *deleting* the cache variable instead of setting it to an empty string. I think you should be able to reset the default value of LLDB_TEST_C_COMPILER (just like any other cmake variable) by running cmake -ULLDB_TEST_C_COMPILER. You can even delete both variables at once with -ULLDB_TEST_*_COMPILER.

Sounds good to me, I'll update the patch. The only reason I did it this way is because I wasn't sure everyone knew about this functionality.

[stella.stamenova]

I think this is actually fine. The change that was needed for multi-configuration generators is how the two default paths for the compilers are set. The USE variables were to make it explicit when we will or we won't override the user-set compiler. As long as we are OK overriding it if they set it to an empty string (which is probably an error, anyway), this change is good.

lldb/trunk/CMakeLists.txt

 # TableGen
 add_subdirectory(utils/TableGen)
 
 add_subdirectory(source)
 add_subdirectory(tools)
 add_subdirectory(docs)
 
 option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests." ${LLVM_INCLUDE_TESTS})
-option(LLDB_TEST_USE_CUSTOM_C_COMPILER "Use the C compiler provided via LLDB_TEST_C_COMPILER for building test inferiors (instead of the just-built compiler). Defaults to OFF." OFF)
-option(LLDB_TEST_USE_CUSTOM_CXX_COMPILER "Use the C++ compiler provided via LLDB_TEST_CXX_COMPILER for building test inferiors (instead of the just-built compiler). Defaults to OFF." OFF)
 if(LLDB_INCLUDE_TESTS)
 
   # Set the path to the default lldb test executable.
   set(LLDB_DEFAULT_TEST_EXECUTABLE "${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb${CMAKE_EXECUTABLE_SUFFIX}")
 
   # Set the paths to default llvm tools.
   set(LLDB_DEFAULT_TEST_DSYMUTIL "${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/dsymutil${CMAKE_EXECUTABLE_SUFFIX}")
   set(LLDB_DEFAULT_TEST_FILECHECK "${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/FileCheck${CMAKE_EXECUTABLE_SUFFIX}")
 
-  if (NOT LLDB_TEST_USE_CUSTOM_C_COMPILER AND TARGET clang)
+  if (TARGET clang)
     set(LLDB_DEFAULT_TEST_C_COMPILER "${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang${CMAKE_EXECUTABLE_SUFFIX}")
-  else()
-    set(LLDB_DEFAULT_TEST_C_COMPILER "")
-  endif()
-
-  if (NOT LLDB_TEST_USE_CUSTOM_CXX_COMPILER AND TARGET clang)
     set(LLDB_DEFAULT_TEST_CXX_COMPILER "${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang++${CMAKE_EXECUTABLE_SUFFIX}")
   else()
+    set(LLDB_DEFAULT_TEST_C_COMPILER "")
     set(LLDB_DEFAULT_TEST_CXX_COMPILER "")
   endif()
 
   set(LLDB_TEST_EXECUTABLE "${LLDB_DEFAULT_TEST_EXECUTABLE}" CACHE PATH "lldb executable used for testing")
   set(LLDB_TEST_C_COMPILER "${LLDB_DEFAULT_TEST_C_COMPILER}" CACHE PATH "C Compiler to use for building LLDB test inferiors")
   set(LLDB_TEST_CXX_COMPILER "${LLDB_DEFAULT_TEST_CXX_COMPILER}" CACHE PATH "C++ Compiler to use for building LLDB test inferiors")
   set(LLDB_TEST_DSYMUTIL "${LLDB_DEFAULT_TEST_DSYMUTIL}" CACHE PATH "dsymutil used for generating dSYM bundles")
   set(LLDB_TEST_FILECHECK "${LLDB_DEFAULT_TEST_FILECHECK}" CACHE PATH "FileCheck used for testing purposes")
 
   if (("${LLDB_TEST_C_COMPILER}" STREQUAL "") OR
       ("${LLDB_TEST_CXX_COMPILER}" STREQUAL ""))
-    message(FATAL_ERROR "LLDB test compilers not specified.  Tests will not run")
+    message(FATAL_ERROR "LLDB test compilers not specified. Tests will not run.")
   endif()
 
   set(LLDB_TEST_DEPS lldb)
 
   # darwin-debug is an hard dependency for the testsuite.
   if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
     list(APPEND LLDB_TEST_DEPS darwin-debug)
   endif()

lldb/trunk/docs/resources/build.rst

 If you want to run the test suite, you will need a compiler to build the test
 programs. If you have Clang checked out, that will be used by default.
 Alternatively, you can specify a C and C++ compiler to be used by the test
 suite.
 
 ::
 
   > cmake -G Ninja \
-      -DLLDB_TEST_USE_CUSTOM_C_COMPILER=On \
-      -DLLDB_TEST_USE_CUSTOM_CXX_COMPILER=On \
       -DLLDB_TEST_C_COMPILER=<path to C compiler> \
       -DLLDB_TEST_CXX_COMPILER=<path to C++ compiler> \
       <path to root of llvm source tree>
 
 It is strongly recommend to use a release build for the compiler to speed up
 test execution.
 
 Windows

 
 Sample command line:
 
 ::
 
   > cmake -G Ninja^
       -DLLDB_TEST_DEBUG_TEST_CRASHES=1^
       -DPYTHON_HOME=C:\Python35^
-      -DLLDB_TEST_USE_CUSTOM_C_COMPILER=ON^
       -DLLDB_TEST_C_COMPILER=d:\src\llvmbuild\ninja_release\bin\clang.exe^
       <path to root of llvm source tree>
 
 
 Building with ninja is both faster and simpler than building with Visual Studio,
 but chances are you still want to debug LLDB with an IDE. One solution is to run
 cmake twice and generate the output into two different folders. One for
 compiling (the ninja folder), and one for editing, browsing and debugging.

lldb/trunk/docs/resources/test.rst

 ---------------------------
 
 The easiest way to run the LLDB test suite is to use the ``check-lldb`` build
 target.
 
 By default, the ``check-lldb`` target builds the test programs with the same
 compiler that was used to build LLDB. To build the tests with a different
 compiler, you can set the ``LLDB_TEST_C_COMPILER`` or the
-``LLDB_TEST_CXX_COMPILER`` CMake variables. These variables are ignored unless
-the respective ``LLDB_TEST_USE_CUSTOM_C_COMPILER`` and
-``LLDB_TEST_USE_CUSTOM_CXX_COMPILER`` are set to ``ON``.
+``LLDB_TEST_CXX_COMPILER`` CMake variables.
 
 It is possible to customize the architecture of the test binaries and compiler
 used by appending ``-A`` and ``-C`` options respectively to the CMake variable
 ``LLDB_TEST_USER_ARGS``. For example, to test LLDB against 32-bit binaries
 built with a custom version of clang, do:
 
 ::