[CMake] Re: Re: FindQt4 in 2.4.8 bug
Hendrik Sattler
post at hendrik-sattler.de
Fri Feb 1 12:00:36 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