[CMake] [PATCH] slightly modify cache variable behaviour, Was: Re: option() behavior
Bill Hoffman
bill.hoffman at kitware.com
Mon May 11 16:04:22 EDT 2009
Alexander Neundorf wrote:
> On Monday 11 May 2009, Bill Hoffman wrote:
>> So, CMake has done what it does now from the start. There was a short
>> period of time when it did not, and that was when a re-write was done,
>> and it quickly broke some existing projects. Here is the thread:
>
> Yes, I can imagine that.
> Still the current behaviour is not very intuitive, especially that set(CACHE)
> in the first cmake run overrides the "visible" variable, while the set(CACHE)
> in the second run basically does nothing, and so the value of the "visible"
> variable is different.
> I think for CMake 2.8 or 3.0 it would be a good idea to make this more
> consistent and easier to understand (especially since now more and more
> people are using cmake).
>
>> http://www.cmake.org/pipermail/cmake/2007-March/013204.html
>>
>> I think the rule should be if you want to change a variable you have to
>> have the set AFTER the variable, or use CACHE INTERNAL.
>
> What do you mean exactly with "have the set after the variable" ?
> Have the set(FOO <value>) after the set(FOO <value> CACHE), or something
> else ?
>
Yes,
This always has worked as expected:
set(FOO 2 CACHE)
set(FOO 1) # this is always the value
However, I think your change is OK. Basically if the set CACHE comes
after the set, it will always set the value. We do need a policy for
this, but it should be easy to detected. You will have to see if the
REMOVE is going to do anything. I wonder how many warnings that
policy will cause... I guess we could create the policy code, and try
it on VTK, Boost, SecondLife, and some other big projects to see what
happens...
-Bill
More information about the CMake
mailing list