[CMake] [PATCH] slightly modify cache variable behaviour, Was: Re: option() behavior

[Alexander Neundorf]

On Sunday 19 April 2009, Eric Noulard wrote:
> 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
> :-).


The attached patch (against current cvs HEAD) changes the behaviour of set( 
CACHE) and option() slightly.

Until now it behaves like this:
if a variable FOO is set to a value, and then set FOO to a value in the CACHE, 
and FOO was not yet in the cache, then afterwards the visible value of FOO is 
the one specified in the set( CACHE) command.

Now assume the same, but FOO is already in the cache. In this case after the 
set() and the set(CACHE) the value in the cache won't have changed (which is 
good), but also the value from the cache will not be visible, but instead FOO 
will have the value from the set(), i.e. the value in the cache doesn't 
matter at all, even although the set(CACHE) was after the set().


You can test this with the following CMakeLists.txt:

set(FOO foo)
message(STATUS "FOO 1: ${FOO}")
set(FOO bar CACHE STRING "fofofofof")
message(STATUS "FOO 2: ${FOO}")

set(OPT abc)
message(STATUS "OPT 1: ${OPT}")
option(OPT "daf df df sdf " ON)
message(STATUS "OPT 2: ${OPT}")

Current cvs HEAD gives:

$ cmake .
-- FOO 1: foo
-- FOO 2: bar
-- OPT 1: abc
-- OPT 2: ON
$ cmake .
-- FOO 1: foo
-- FOO 2: foo
-- OPT 1: abc
-- OPT 2: abc

With the patch you get:
$ cmake .
-- FOO 1: foo
-- FOO 2: bar
-- OPT 1: abc
-- OPT 2: ON
$ cmake .
-- FOO 1: foo
-- FOO 2: bar
-- OPT 1: abc
-- OPT 2: ON

If I change FOO via make edit_cache, this now also has an effect, that value 
will be visible.

What do you think ?

A problem is that this patch changes previous behaviour. A policy warning 
could be introduced, I think the condition when the behaviour changes can be 
detected.


Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cache_variable_behaviour.patch
Type: text/x-diff
Size: 1133 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090510/8fa1735c/attachment-0001.patch>