Enable CMake policy 77. This alters the behavior of option. The old behavior would remove the value of the option from the cache and create a new one. The new behavior does not create the variable if it is defined already. This ensures that subsequent reconfigures will behave identically. This seems better than the setting of OLD - the desire is to ensure that it is set to OLD or NEW.
Diff Detail
- Repository
- rL LLVM
Event Timeline
Could you perform a configure before and after this change and confirm that your CMakeCache.txt is the same? If so, this LGTM.
I think people have learned to overcome the OLD behavior by including CACHE and type in set commands in cache files, but this makes it easier. However, if you want to rerun cmake and change existing values, you'll still need to include CACHE, type, and FORCE, is that right? At least that's how I've been handling it locally. Any advice would be appreciated.
@hintonda also, re-running the CMake command line and setting -D... is always a FORCE
This LGTM, but I do want to clarify that your explanation is not correct.
option(...) doesn't remove cached values. If it did, CMake re-generation when you change a build configuration wouldn't work. In the OLD behavior option was implemented roughly as set(${VAR} ${DEFAULT} CACHE BOOL ...). Which if you had a non-cached variable would override it and write it to the cache with the default value. In the NEW behavior if the variable is already set the default value gets replaced with the pre-set value.
The policy documentation explains all the behavior and edge cases pretty well:
https://cmake.org/cmake/help/latest/policy/CMP0077.html