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

Ben Boeckel ben.boeckel at kitware.com
Thu Dec 10 09:37:45 EST 2015


On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote:
> 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.

The above commit has the same behavior as it does today: first configure
!= subsequent configure, so I don't see the confusion as being *less*
after the fix since any existing tree wouldn't say "2" either, but I
suppose it was something about dashboards doing clean builds.

> On 12/09/2015 05:35 PM, Ben Boeckel wrote:
> > 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.

Like with some of the more disruptive policies (e.g., CMP0054), it's a
clarification of some potentially^Wconfusing behavior which can bite you
in certain cases pretty hard (CI vs. developer builds).

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

Oops. Updated. Also reordered the branch so the feature is at the end of
the branch.

--Ben


More information about the cmake-developers mailing list