[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