<div class="gmail_quote">On Sun, Apr 19, 2009 at 1:56 PM, Eric Noulard <span dir="ltr"><<a href="mailto:eric.noulard@gmail.com" target="_blank">eric.noulard@gmail.com</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;">
2009/4/19 Philip Lowman <<a href="mailto:philip@yhbt.com" target="_blank">philip@yhbt.com</a>>:<br>
<div>> I encountered this the other day. Is this a bug?<br>
<br>
</div>I don't think so.<br>
More comment inside code:<br>
<div><br>
> project(Foo)<br>
> cmake_minimum_required(VERSION 2.6)<br>
> set(WTFO ON)<br>
<br>
</div>You define the WTFO which is not cached.<br>
<div><br>
> message("WTFO is ${WTFO}")<br>
<br>
<br>
> option(WTFO "wtfo" OFF)<br>
<br>
</div>Now you define an option with the same name which is a variable but CACHED.<br>
<div><br>
> message("WTFO is ${WTFO}")<br>
><br>
> Here's the output...<br>
><br>
> (first run)<br>
> WTFO is ON<br>
> WTFO is OFF<br>
<br>
</div>First run shows you the var value.<br>
<br>
Then the option overwrite the uncached var with its default value, i.e. OFF.<br>
<div><br>
> (second run)<br>
> WTFO is ON<br>
<br>
</div>You set the cached variable to ON, thus the value is "ON" but now it<br>
reached the cache.<br>
<br>
> WTFO is ON<br>
<br>
Your option retrieve it's value from the cache.<br>
<br>
<br>
I think the "bug" is that you may define an option which overwrite an<br>
uncached var.</blockquote><div><br>This is exactly what I wanted to do though. In this case I don't care what options are being exposed to the cache, I just want to overwrite what someone is doing "downstream". I know of at least 2 fixes to the problem I ran into, but I'm just trying to integrate my knowledge of CMake to understand things better.<br>
<br>I guess my question is why is it when you call SET(...CACHE) or OPTION(), pre-existing local variables of the same name are removed (or in the case of a boolean, redefined)? See both implementations of cmMakefile::AddCacheDefinition(). If you have a pre-existing local variable defined it's going to be defined on the next run so you're just delaying the inevitable by one configure. What use case justifies the removal of the local variable that I'm not seeing?<br>
<br></div></div>-- <br>Philip Lowman<br>