[CMake] IMPORTANT!! SET CACHE FORCE not wortking with UNINITIALIZED variables

[Fernando Cacciola]

Eric NOULARD wrote:
> Le Tue, 11 Nov 2008 11:47:20 -0200,
> Fernando Cacciola <fernando.cacciola at gmail.com> a écrit :
>> Hi,
>>
>> Since my last post about this got unnoticed I'm reposting it, this
>> time with additional information.
>>
> 
> [...]
> May be CMake devel are busy :-)
> 
Fair enough.

>> The culprint is in the following section of the cmake sources:
>>
>>
>> void cmMakefile::AddCacheDefinition(const char* name, const char*
>> value, const char* doc,
>>                                      cmCacheManager::CacheEntryType
>> type) {
>>    const char* val = value;
>>    cmCacheManager::CacheIterator it =
>>      this->GetCacheManager()->GetCacheIterator(name);
>>    if(!it.IsAtEnd() && (it.GetType() ==
>> cmCacheManager::UNINITIALIZED) &&
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>       it.Initialized())
>>      {
>>
>>      val = it.GetValue();
>>      ^^^^^^^^^^^^^^^^^^^^
>>
>>
>> As you can see, when SET sees an UNINITIALIZED variable it just
>> ignores the value being passed on and just keeps the previous value.
> 
> After some CVS history browsing, the code is there at least since
> CMake 2.4.4 (may be older).
>  
>> IMO this is a bug, and I even wonder if that comparison didn't intend
>> to be != instead  ??
> 
> The bug, if ever this is one should be elsewhere.
> 
Or the this bug only shows up now because in 2.4.* variables specified 
in the command line ARE NOT added into the cache as UNINITIALIZED.

I reported this in my previous post.

I mean, look at it and tell me honestly why on earth would the cached 
value of variable of type UNINITIALIZED take precedence over the value 
indicated on SET, for whatever UNINITIALIZED could possibly mean other 
than, say, UNMUTABLE or so, in which case variables passed untyped on 
the command line should not be of that type if it meant unmutable.

>> Fortunately, the variable is nevertheless overwritten into the cache, 
>> with the old (wrong) value but the correct type, hence, the following 
>> works around the bug:
>>
>>
>> SET( VAR "321" CACHE STRING "" FORCE )
>> SET( VAR "321" CACHE STRING "" FORCE )
>> MESSAGE( STATUS "VAR=${VAR}" )
>>
>> That is, the first SET "fixes" the type, allowing the second SET to
>> do what it should.
>>  
>> Shall I add this to the tracker or is this behaviour on purpose??
> 
> I would say that this deserve a bug report at least in order to add
> some documentation about the current behavior.
> 
> Nevertheless CMake 2.6.2 documentation (cmake --help) says:
> 
> -D <var>:<type>=<value>     = Create a cmake cache entry.
> 
> and cmake --help-command SET says:
> 
> If CACHE is present, then the <variable> is put in the cache.
>   <type> and <docstring> are then ***required***.
> 
Notice that this speaks of the SET command.
The UNINITIALIZED comes form defining the variable in the command-line 
without a type.

> Does this mean that in order to have a proper CACHE entry one MUST
> specify <type>. 
 >
In the SET command, sure. I do that of course, it's even a syntax error 
not to specify the TYPE.

In the command line however my users DON'T indicate any type, and I 
don't think they should be expected to do so. I don't think this has 
ever been the intention since most examples of variables given in the 
command line are typeless.

So, if it is matter of improving documentation then it would be in the 
command-line specification of variables where it should say that types 
are required... if that's indeed the case, which I hope not.

> Or more generally what is the purpose of
> 
> UNINITIALIZED cache entry.
> 
I'm not sure and it's not even documented.
Yet you can see it in the cache.

> I'm afraid we'll have to wait peacefully for CMake 
> developper spare time in order to have technical answer for this :=)
> 
I'm afraid so....

And not so peacefully in my case since I am pushing the deadline and I 
still don't know if I should require my users to specify the type when 
defining variables in the command line or not.. and when I said they 
should, my earlier tester complained up front since they've never seen 
this requirement before with cmake.

Best

Fernando