[CMake] Re: Re: Re: FindQt4 in 2.4.8 bug

[Bill Hoffman]

Fernando Cacciola wrote:
> Hi Bill,
> 
>>> behaviour. Don't break that as you can always use
>>>  if (NOT DEFINED VAR)
>>>    set (VAR "foo" CACHE ...... FORCE)
>>>
>>
>> But:
>>
>> find_library(FOO_VAR foo)
>>
>> This will set FOO_VAR (in the cache) if it is not set
>>
>> or if the value has -NOTFOUND in it.
>>
> I just tried it and find_path (didn't try find_library but find_path) 
> will not set it if the cache has -NOTFOUND in it.
> Please try yourself because I think this one is unexpected, and 
> undocumented.
> 
> But let's say I did the test wrong (hopefully) and it is as you said.
> Even then this is much more important IMO:
> 
> set(FOO_VAR somevalue)
> 
> and
> 
> set(FOO_VAR somevalue CACHE TYPE "")
> 
> are inconsistent.
> 
> That's much harder to understand.
> 
> Also, the SET documention only mentions the critically important fact 
> that cached values are not overwritten by default when the FORCE option 
> is explained. IMO this is the wrong way to document such an odd 
> behaviour for a command named SET (I don't think I ever seen a language 
> with such a behaviour, and I've been in this business for a long long 
> time).
> At the very least that fact should be stated up front.
> 

I guess it is a hard thing to understand, but perhaps you can help 
explain it.  First, let me try and explain it to you...

If set(foo_var somvalue CACHE TYPE "") always did a set, then users 
could never modify the CMakeCache.txt file with ccmake, CMakeSetup, or 
emacs.  Because the script that set the initial value would just keep 
clobbering the new value.   How would you like that to read in the SET 
command?

-Bill