Fernando Cacciola wrote:
Hi Bill,
Can you add a :
Better let me start over, I think I know what's going on now.
Maybe is the intended behaviour. If it is, I think is quite odd.
Consider the following simple script:
set ( var "whatever" CACHE PATH "" )
message ( STATUS "${var}" )
I would expect to see "whatever" as the value of var since it is being
explicitely set, but that's not neccesarily what happens: if the cache
*already* contains a value for var, say "xyz", then that value sticks
and var is just never set to "whatever" unless FORCE is added (as I
found out and reported eariler in this thread)
Is this the expected behaviour?
If it is, then it leads to a problem when SET is used for example like
this:
set ( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH "" )
because if at some earlier run qt4 was actually not found,
QT_INCLUDE_DIR gets set to NOTFOUND and once there it is never reset to
the include path even if qt4 is properly found later. The only way out
this tirany is to delete the cache and star over.
IMO the rule that says "do not override exisitng cache values unless
FORCE is specified" should be relaxed to have "null values" be always
overwritten.
Or at the very least there should be a FORCE_IF_NULL option, because it
makes no sense at all to keep a NOTFOUND value for an INCLUDE_DIR when
the right path is available.
Best
OK, I get it now... So, the FIND_* stuff will set a value if it is
NOTFOUND. However, the set command will not. I am thinking it should.
I am not sure what that will break, but it would be consistent with
FIND_*.
This should not be a problem if you start from a clean build tree for
FindQt4.cmake, as QT_INCLUDE_DIR will never get put in the cache as
NOTFOUND by the current FindQt4.cmake. So, I think this is something
we can fix in CMake 2.6. Feel free to create a feature request, "set
CACHE should set NOTFOUND variables".
Thanks for tracking this down.
-Bill
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
