[CMake] Re: Re: Re: Re: FindQt4 in 2.4.8 bug
fernando.cacciola at gmail.com
Fri Feb 1 14:32:12 EST 2008
>> 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
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