[CMake] Re: Re: FindQt4 in 2.4.8 bug

Hendrik Sattler post at hendrik-sattler.de
Fri Feb 1 12:00:30 EST 2008


Quoting Bill Hoffman <bill.hoffman at kitware.com>:

> Hendrik Sattler wrote:
>> Quoting Bill Hoffman <bill.hoffman at kitware.com>:
>>> 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".
>>
>> Let's say a library is optional. A current script cannot see the   
>> difference anymore between "library not found on earlier run" and   
>> "I did not search for it, yet". SET is well-documented about CACHE   
>> and FORCE behaviour. Don't break that as you can always use
>> if (NOT DEFINED VAR)
>>   set (VAR "foo" CACHE ...... FORCE)
>>
>
> But:
>
> find_library(FOO_VAR foo)
>
> This will set FOO_VAR (in the cache) if it is not set, or if the value
> has -NOTFOUND in it.
>
> However,
>
> set(FOO_VAR somevalue CACHE STRING "")
>
> Will only set FOO_VAR if it has no value at all.  Seems a bit inconsistent.

So you want to give NOTFOUND an even more special status than all the  
other negative variable values? This is not even close to being  
backwards-compatible. And you can always check for NOTFOUND and use  
FORCE. I don't see the problem that qualifies for changing SET in an  
incompatible way.

HS






More information about the CMake mailing list