On Sunday 19 April 2009, Eric Noulard wrote:
> 2009/4/19 Philip Lowman <phi...@yhbt.com>:
> > On Sun, Apr 19, 2009 at 1:56 PM, Eric Noulard <eric.noul...@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
Index: cmSetCommand.cxx
===================================================================
RCS file: /cvsroot/CMake/CMake/Source/cmSetCommand.cxx,v
retrieving revision 1.35
diff -b -u -p -r1.35 cmSetCommand.cxx
--- cmSetCommand.cxx 10 May 2009 20:07:34 -0000 1.35
+++ cmSetCommand.cxx 10 May 2009 20:55:15 -0000
@@ -160,6 +160,7 @@ bool cmSetCommand
// or the makefile
if(cache && type != cmCacheManager::INTERNAL && !force)
{
+ this->Makefile->RemoveDefinition(variable);
return true;
}
}
Index: cmOptionCommand.cxx
===================================================================
RCS file: /cvsroot/CMake/CMake/Source/cmOptionCommand.cxx,v
retrieving revision 1.23
diff -b -u -p -r1.23 cmOptionCommand.cxx
--- cmOptionCommand.cxx 23 Jan 2008 15:27:59 -0000 1.23
+++ cmOptionCommand.cxx 10 May 2009 20:55:15 -0000
@@ -58,6 +58,7 @@ bool cmOptionCommand
if ( it.GetType() != cmCacheManager::UNINITIALIZED )
{
it.SetProperty("HELPSTRING", args[1].c_str());
+ this->Makefile->RemoveDefinition(args[0].c_str());
return true;
}
if ( it.GetValue() )
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
