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

[Fernando Cacciola]

Hi Bill,

>> 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?
>

Actually I would not like that read in the SET command.

First, users *can* modify the cache (but you said they could not). A better 
why to put it would be that "users could not make sure modified cached 
entries are not overriden".

Second, as I said in another thread, SET could override NOTFOUND (but not 
other values) as I can't imagine why someone would ever won't that value to 
stick.


IMO this whole thing is upside down. SET should override unless explicitely 
forbidden (for example by adding a READONLY qualifier, or so), not the other 
way around.
That's how it should have been to begin with, if only because it is like 
this in most-if not all-programming languages.

Too late for that? Maybe.. though never forget that programming languages 
crash in the end when they can't turn the wheel on time due to inertia.

Best

Fernando