Eric NOULARD wrote:
Le Tue, 11 Nov 2008 11:47:20 -0200,
Fernando Cacciola <[EMAIL PROTECTED]> a écrit :
Hi,
Since my last post about this got unnoticed I'm reposting it, this
time with additional information.
Sorry, I did see your post, and I am busy...
So, you also mentioned this case:
SET( VAR "321" CACHE STRING "" FORCE )
set(VAR )
message(${VAR}) -> prints out 321
So, this was intentional. set(var ) removes the value of var, and var
becomes "unset". This then re-exposes the cache variable VAR.
The culprint is in the following section of the cmake sources:
void cmMakefile::AddCacheDefinition(const char* name, const char*
value, const char* doc,
cmCacheManager::CacheEntryType
type) {
const char* val = value;
cmCacheManager::CacheIterator it =
this->GetCacheManager()->GetCacheIterator(name);
if(!it.IsAtEnd() && (it.GetType() ==
cmCacheManager::UNINITIALIZED) &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
it.Initialized())
{
val = it.GetValue();
^^^^^^^^^^^^^^^^^^^^
As you can see, when SET sees an UNINITIALIZED variable it just
ignores the value being passed on and just keeps the previous value.
After some CVS history browsing, the code is there at least since
CMake 2.4.4 (may be older).
IMO this is a bug, and I even wonder if that comparison didn't intend
to be != instead ??
The bug, if ever this is one should be elsewhere.
Fortunately, the variable is nevertheless overwritten into the cache,
with the old (wrong) value but the correct type, hence, the following
works around the bug:
SET( VAR "321" CACHE STRING "" FORCE )
SET( VAR "321" CACHE STRING "" FORCE )
MESSAGE( STATUS "VAR=${VAR}" )
That is, the first SET "fixes" the type, allowing the second SET to
do what it should.
Shall I add this to the tracker or is this behaviour on purpose??
So, I think this was intentional, sort of...
The issue is that we want the command line to be used. So, if you have:
cmake -DFOO=456
Then, FOO should be set in the cache to the value 456 and something like
this:
SET( VAR "123" CACHE STRING "" )
Should not set VAR to 123, but it should set the type to STRING. The
bug seems to be that if you have:
SET( VAR "123" CACHE STRING "" FORCE)
It should do a FORCE and override the command line.
If you can provide a patch that does that, I will apply it, as FORCE
should always force. We just need to be careful that we don't break the
non-force case that should only set the type.
-Bill
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake