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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
