[CMake] option() behavior

[Eric Noulard]

2009/4/19 Philip Lowman <philip at yhbt.com>:
> On Sun, Apr 19, 2009 at 1:56 PM, Eric Noulard <eric.noulard at gmail.com>
>>
>>
>> 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)?

Good question, you may only want to make it a CACHE var without
changing the value?
If you want to do so you may using awkward

IF (DEFINED VAR)
    OPTION(VAR "blah" ${VAR})
ELSE (DEFINED VAR)
    OPTION(VAR "blah" OFF)
ENDIF (DEFINED VAR)

The default behaviour is not this one.
However, both behaviour looks fine to me, it's just a matter of design choice.

> 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?

I really don't know the use case. I even wonder if there is one.
Or may be you can imagine that you may "hand-craft" a CMakeCache.txt
without CMake and feeds a genuine CMakeLists.txt which uses non cache var
with it? kind of ugly though.

I think it is a  design choice:

- cached variables are "stronger" than non cached ones
- INTERNAL are "stronger" than cached
- cached var inherits their "CACHEness" from CMakeCache.txt
  or the first encountered SET(...CACHE) or OPTION()

My point of view is that CMake may eventually warns you that you are
"overwriting" a local
var but not more.

CMake developper certainly have their reason, they seems reasonable (to me :-).

-- 
Erk