[cmake-developers] set(CACHE) and the local scope

Brad King brad.king at kitware.com
Thu Dec 10 08:50:10 EST 2015


On 12/09/2015 05:35 PM, Ben Boeckel wrote:
> So some behavior I was unaware of until today came up:
> 
>     set(var ON)
>     option(var "description" OFF)
>     message("var: ${var}")
> 
> outputs "OFF" for the first configure and "ON" for subsequent
> configures. This is because set(var CACHE) does unset(var) *if* the
> cache was touched. This is not done on the second time around since it
> is already in the cache.

That is a long-standing subtlety introduced without discussion, review,
or tests here:

 BUG: change in how set cache overrides local definitions. Should mainly be a NOP change for most cases
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2

IIRC there was confusion at the time in the case of

 set(var 1)
 set(var 2 CACHE STRING ...)
 message("${var}") # prints "1" before the above change.

> I think a policy to remove the unset(var) behavior should be added since
> the current behavior means that clean builds can be wildly different
> than incremental builds.

One reason a policy has not been introduced for this before is that
producing a warning for the policy may be very verbose unless it is
delayed until variable dereference, but the latter would be a huge
performance hit to check.  Still, I think things would be better off
in the long run with some policy for it.

> Related, I have a branch on the stage (update-variable-docs) which
> attempts to clarify some darker corners of the set() command and the
> *VARIABLES directory properties.

The "LOCAL_VARIABLES" change uses "SCOPE_VARIABLES" in some places.
The release note should only cover the new feature.

-Brad



More information about the cmake-developers mailing list