Page MenuHomePhabricator

[CMake] Remove LLDB_TEST_USE_CUSTOM_C(XX)_COMPILER
ClosedPublic

Authored by JDevlieghere on Mon, Aug 19, 10:29 AM.

Details

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

Diff Detail

Repository
rL LLVM

Event Timeline

JDevlieghere created this revision.Mon, Aug 19, 10:29 AM
Herald added a project: Restricted Project. · View Herald TranscriptMon, Aug 19, 10:29 AM

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.

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.

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.

This revision is now accepted and ready to land.Tue, Aug 20, 10:36 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptTue, Aug 20, 1:19 PM