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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
