<div class="gmail_quote">On Mon, May 11, 2009 at 4:53 PM, Alexander Neundorf <span dir="ltr">&lt;<a href="mailto:a.neundorf-work@gmx.net">a.neundorf-work@gmx.net</a>&gt;</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>
&gt; Alexander Neundorf wrote:<br>
&gt; &gt; On Monday 11 May 2009, Bill Hoffman wrote:<br>
&gt; &gt;&gt; So, CMake has done what it does now from the start.   There was a short<br>
&gt; &gt;&gt; period of time when it did not, and that was when a re-write was done,<br>
&gt; &gt;&gt; and it quickly broke some existing projects.  Here is the thread:<br>
&gt; &gt;<br>
&gt; &gt; Yes, I can imagine that.<br>
&gt; &gt; Still the current behaviour is not very intuitive, especially that<br>
&gt; &gt; set(CACHE) in the first cmake run overrides the &quot;visible&quot; variable, while<br>
&gt; &gt; the set(CACHE) in the second run basically does nothing, and so the value<br>
&gt; &gt; of the &quot;visible&quot; variable is different.<br>
&gt; &gt; I think for CMake 2.8 or 3.0 it would be a good idea to make this more<br>
&gt; &gt; consistent and easier to understand (especially since now more and more<br>
&gt; &gt; people are using cmake).<br>
&gt; &gt;<br>
&gt; &gt;&gt; <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>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I think the rule should be if you want to change a variable you have to<br>
&gt; &gt;&gt; have the set AFTER the variable, or use CACHE INTERNAL.<br>
&gt; &gt;<br>
&gt; &gt; What do you mean exactly with &quot;have the set after the variable&quot; ?<br>
&gt; &gt; Have the set(FOO &lt;value&gt;) after the set(FOO &lt;value&gt; CACHE), or something<br>
&gt; &gt; else ?<br>
&gt;<br>
&gt; Yes,<br>
&gt;<br>
&gt; This always has worked as expected:<br>
&gt;<br>
&gt; set(FOO 2 CACHE)<br>
&gt; set(FOO 1)  # this is always the value<br>
&gt;<br>
&gt; However, I think your change is OK.  Basically if the set CACHE comes<br>
&gt; after the set, it will always set the value.   We do need a policy for<br>
&gt; this, but it should be easy to detected.  You will have to see if the<br>
&gt; REMOVE is going to do anything.    I wonder how many warnings that<br>
&gt; policy will cause... I  guess we could create the policy code, and try<br>
&gt; it on VTK, Boost, SecondLife, and some other big projects to see what<br>
&gt; happens...<br>
<br>
</div></div>Ok, I put it on my TODO, then we&#39;ll see what (would) happen.</blockquote><div><br>I&#39;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&#39;t think this is going to impact us at all and I suspect it probably won&#39;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>