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

Fernando Cacciola fernando.cacciola at gmail.com
Fri Feb 1 14:32:12 EST 2008

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 

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.



More information about the CMake mailing list