<div class="gmail_quote">On Mon, May 11, 2009 at 4:53 PM, Alexander Neundorf <span dir="ltr"><<a href="mailto:a.neundorf-work@gmx.net">a.neundorf-work@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Monday 11 May 2009, Bill Hoffman wrote:<br>
> Alexander Neundorf wrote:<br>
> > On Monday 11 May 2009, Bill Hoffman wrote:<br>
> >> So, CMake has done what it does now from the start. There was a short<br>
> >> period of time when it did not, and that was when a re-write was done,<br>
> >> and it quickly broke some existing projects. Here is the thread:<br>
> ><br>
> > Yes, I can imagine that.<br>
> > Still the current behaviour is not very intuitive, especially that<br>
> > set(CACHE) in the first cmake run overrides the "visible" variable, while<br>
> > the set(CACHE) in the second run basically does nothing, and so the value<br>
> > of the "visible" variable is different.<br>
> > I think for CMake 2.8 or 3.0 it would be a good idea to make this more<br>
> > consistent and easier to understand (especially since now more and more<br>
> > people are using cmake).<br>
> ><br>
> >> <a href="http://www.cmake.org/pipermail/cmake/2007-March/013204.html" target="_blank">http://www.cmake.org/pipermail/cmake/2007-March/013204.html</a><br>
> >><br>
> >> I think the rule should be if you want to change a variable you have to<br>
> >> have the set AFTER the variable, or use CACHE INTERNAL.<br>
> ><br>
> > What do you mean exactly with "have the set after the variable" ?<br>
> > Have the set(FOO <value>) after the set(FOO <value> CACHE), or something<br>
> > else ?<br>
><br>
> Yes,<br>
><br>
> This always has worked as expected:<br>
><br>
> set(FOO 2 CACHE)<br>
> set(FOO 1) # this is always the value<br>
><br>
> However, I think your change is OK. Basically if the set CACHE comes<br>
> after the set, it will always set the value. We do need a policy for<br>
> this, but it should be easy to detected. You will have to see if the<br>
> REMOVE is going to do anything. I wonder how many warnings that<br>
> policy will cause... I guess we could create the policy code, and try<br>
> it on VTK, Boost, SecondLife, and some other big projects to see what<br>
> happens...<br>
<br>
</div></div>Ok, I put it on my TODO, then we'll see what (would) happen.</blockquote><div><br>I'll be happy to test it out on our build system at work as well.<br><br>I never thought to do anything crazy like define a local variable before a cache variable until CMakePorts... so I don't think this is going to impact us at all and I suspect it probably won't affect others much either. Wrapping the cache and option declarations with if(DEFINED...) is no big deal.<br>
</div></div><br>-- <br>Philip Lowman<br>