[CMake] BUG in SET in 2.6.2 (and probably 2.6.*)

[Fernando Cacciola]

Hi people,

Consider the following:


# Forcibly set the value of a cache variable
set( VAR "Hello" CACHE STRING "bla bla" FORCE )

# Show in-memory value
message( STATUS "VAR=${VAR}" )

# Load cached value just in case the above SET
# overwrote only the in-memory value
set( VAR )

# Now show the cached value
message( STATUS "VAR=${VAR}" )


Now look at it closely and figure what do you expect it do do if CMake 
is invoked like this:

cmake -DVAR=Goodbye .

?


The very first line is supposed to *overwrite* the value given by the 
user becasue it says "FORCE" at the end.. right?

If you have 2.4.* around you can verify that this is indeed the case.

But if you have 2.6.2 (and possibly any 2.6) you'll be surprised to see 
it printing "Goodby" instead, and twice.

That is, under 2.6.2 the SET command has no effect at all in spite the 
FORCE option.

I found by trial and error that if you specify the type of the variable 
in the command line, then the overriding SET in the script does work:


   CMAKE -DVAR:STRING=Goodbye

Prints Hello twice, as expected and as in 2.4.*


This behaviour is not documented (and it's not even backwards 
compatible) so I think it is a bug.
I even guess it is related to the fact that in 2.6.2 variables given in 
the command line are stored in the cache with the type UNINITIALIZED 
(which is also undocumented), so I'm guessing the SET command is bailing 
out due to the type mismatch.


IMO this is a serious bug since now I need to tell my users to specify 
the type as well if they are passing variables in the command-line, 
which they are finding quite annoying. (annoying that without the type 
then the whole build just doesn't work).


FWIW, in the above simplified example the issue might seem unimportant, 
so here's the real use case:

# This *adds* 'this_and_that' to whatever the user defined in VAR,
# if any.
#
set( VAR ${VAR} this_and_that CACHE STRING "bla bla" FORCE )

The bug reported has the effect that 'this_and_that' is silently
not added at all, but only if the user passed -DVAR=whatever.
It works fine if the user doesn't pass any VAR or specifies
the type correctly as in: -DVAR:STRING=whatever


Shall I add this to the bug tracker?

Is there any workaround which doesn't require users to specify the type?

TIA

Fernando Cacciola