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).
- Group Reviewers
- rG8509b0a7788a: [CMake] Remove LLDB_TEST_USE_CUSTOM_C(XX)_COMPILER
rLLDB369435: [CMake] Remove LLDB_TEST_USE_CUSTOM_C(XX)_COMPILER
rL369435: [CMake] Remove LLDB_TEST_USE_CUSTOM_C(XX)_COMPILER
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.
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.