[CMake] option() behavior

[Philip Lowman]

On Sun, Apr 19, 2009 at 1:56 PM, Eric Noulard <eric.noulard at gmail.com>wrote:

> 2009/4/19 Philip Lowman <philip at yhbt.com>:
> > I encountered this the other day.  Is this a bug?
>
> I don't think so.
> More comment inside code:
>
> > project(Foo)
> > cmake_minimum_required(VERSION 2.6)
> > set(WTFO ON)
>
> You define the WTFO which is not cached.
>
> > message("WTFO is ${WTFO}")
>
>
> > option(WTFO "wtfo" OFF)
>
> Now you define an option with the same name which is a variable but CACHED.
>
> > message("WTFO is ${WTFO}")
> >
> > Here's the output...
> >
> > (first run)
> > WTFO is ON
> > WTFO is OFF
>
> First run shows you the var value.
>
> Then the option overwrite the uncached var with its default value, i.e.
> OFF.
>
> > (second run)
> > WTFO is ON
>
> You set the cached variable to ON, thus the value is "ON" but now it
> reached the cache.
>
> > WTFO is ON
>
> Your option retrieve it's value from the cache.
>
>
> I think the "bug" is that you may define an option which overwrite an
> uncached var.


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.

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?

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090419/4278fe7d/attachment-0001.htm>