[CMake] --debug-trycompile causes false positives from check_function_exists

[Jack Poulson]

On Fri, Feb 11, 2011 at 6:00 AM, David Cole <david.cole at kitware.com> wrote:

> To use "--debug-trycompile" effectively, you have to:
>
> - run *without* "--debug-trycompile" all the way through once to establish
> all the cache settings
> - remove/delete the *single* cache entry whose try_compile result you are
> trying to debug
> - run again with "--debug-trycompile"
>
> The reasons are:
> - try_compile operations generate a project and a project build tree, and
> then clean up after themselves (delete the generated project source and
> build tree)
> - only one try_compile operation may be executed at a time because they all
> share the same source and build trees
> - clean up must occur in between runs so that each one is correct and
> independent of all the other ones
> - --debug-trycompile *leaves* *the* try_compile project source and build
> tree on disk so that you can inspect them, and presumably "debug" the
> problem
>
> So..... given this view into the implementation details of try_compile, you
> cannot count on the results of --debug-trycompile to be accurate for more
> than one try_compile in a row. Leaving the build tree from a previous
> try_compile operation affects the results of subsequent try_compiler
> operations. Only one at a time may be "debugged".
>
>
Thank you for the detailed explanation.


> (I realize this belongs in the documentation somewhere, but my question to
> you is: where would you have looked first for such documentation? If you can
> answer that, or several people answer approximately the same way, then I
> could add documentation for this in such a spot. -- Thanks.)
>
>
The real answer is that I should have read the --debug-trycompile section of
the docs, and then I wouldn't have sent an email. As someone pointed out, it
does make it clear that subsequent try_compile calls are untrustworthy, and
I am aware that check_function_exists uses try_compile under the hood.
However, this is not in the documentation. I would suggest adding a list of
all of the routines that --debug-trycompile breaks in the --debug-trycompile
documentation section.

With that said, I think the appropriate place for your above discussion is
definitely in the --debug-trycompile section of the documentation. I
apologize for spamming the list with something that I could have read from
the reference.

Jack


> On Fri, Feb 11, 2011 at 2:57 AM, Jack Poulson <jack.poulson at gmail.com>wrote:
>
>> On Fri, Feb 11, 2011 at 1:47 AM, Michael Wild <themiwi at gmail.com> wrote:
>>
>>> On 02/11/2011 04:30 AM, Jack Poulson wrote:
>>> > This is occurring with CMake 2.8.3 on OSX for several different
>>> > check_function_exists calls. Is this expected behavior?
>>> >
>>> > Jack
>>>
>>> Seriously, we're going to need some more information than just "I get
>>> false positives"...
>>>
>>>
>> I did not give any more information because, well, it seems to _always_
>> give false positives with those settings. I don't really care if it's fixed
>> because I can easily work around it, but I thought I'd give you guys a heads
>> up.
>>
>> If it helps, this is the relevant snippet:
>>
>> include(CheckFunctionExists)
>> set(CMAKE_REQUIRED_LIBRARIES ${MATH_LIBS})
>> check_function_exists(vdSin MKL)
>> check_function_exists(vsin MASS)
>>
>> If I run without --debug-trycompile when I am not linking in the MKL or
>> MASS libraries, the routines vdSin and vsin are not found. When I run with
>> --debug-trycompile, they are found. That's all I have time to give. Use it
>> or not. I'm not asking for help.
>>
>> Jack
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110211/d144d8b7/attachment-0001.htm>