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.
[...]
May be CMake devel are busy :-)
Fair enough.
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.
Or the this bug only shows up now because in 2.4.* variables specified
in the command line ARE NOT added into the cache as UNINITIALIZED.
I reported this in my previous post.
I mean, look at it and tell me honestly why on earth would the cached
value of variable of type UNINITIALIZED take precedence over the value
indicated on SET, for whatever UNINITIALIZED could possibly mean other
than, say, UNMUTABLE or so, in which case variables passed untyped on
the command line should not be of that type if it meant unmutable.
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??
I would say that this deserve a bug report at least in order to add
some documentation about the current behavior.
Nevertheless CMake 2.6.2 documentation (cmake --help) says:
-D <var>:<type>=<value> = Create a cmake cache entry.
and cmake --help-command SET says:
If CACHE is present, then the <variable> is put in the cache.
<type> and <docstring> are then ***required***.
Notice that this speaks of the SET command.
The UNINITIALIZED comes form defining the variable in the command-line
without a type.
Does this mean that in order to have a proper CACHE entry one MUST
specify <type>.
>
In the SET command, sure. I do that of course, it's even a syntax error
not to specify the TYPE.
In the command line however my users DON'T indicate any type, and I
don't think they should be expected to do so. I don't think this has
ever been the intention since most examples of variables given in the
command line are typeless.
So, if it is matter of improving documentation then it would be in the
command-line specification of variables where it should say that types
are required... if that's indeed the case, which I hope not.
Or more generally what is the purpose of
UNINITIALIZED cache entry.
I'm not sure and it's not even documented.
Yet you can see it in the cache.
I'm afraid we'll have to wait peacefully for CMake
developper spare time in order to have technical answer for this :=)
I'm afraid so....
And not so peacefully in my case since I am pushing the deadline and I
still don't know if I should require my users to specify the type when
defining variables in the command line or not.. and when I said they
should, my earlier tester complained up front since they've never seen
this requirement before with cmake.
Best
Fernando
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
