[cmake-developers] CheckSymbolExists.cmake

[Christopher Sean Morrison]

On Jun 04, 2013, at 04:17 PM, Brad King <brad.king at kitware.com> wrote:

The discussion that led to that change was here:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2523/focus=2530
 
The predicating problem is curious.  If a pthreads library was no longer being detected, that would imply that CheckSymbolExists was failing, yes?  Getting optimized out of compilation would have resulted in the check *passing*...

That should only caused a problem where a header existed, but no library to link against and CheckSymbolExists erroneously passing.

CheckSymbolExists has always been intended to test decl+linkage except
in the case that the symbol is available as a preprocessor definition.
A success means "I can use this symbol".

CheckFunctionExists tests linkage only with no decl or preprocessor
definition possibility. Those limitations led to CheckSymbolExists.

> p.s. CHECK_PROTOTYPE_EXISTS is practically useless as written. I'd submit
> a patch to fix it, but the fix would look nearly identical to what
> CHECK_SYMBOL_EXISTS used to test. 

Perhaps that is the path forward for your need.
 
While I work on that patch, to summarize, the meaning of EXISTS for the three functions would be/become:

CHECK_FUNCTION_EXISTS: symbol links (defined)
CHECK_PROTOTYPE_EXISTS: symbol compiles (declared)
CHECK_SYMBOL_EXISTS: symbol available (declared and defined)

Those ambiguous overlapping names could use some TLC.. :)  I'd propose the trio be renamed:

CHECK_SYMBOL_EXISTS
CHECK_SYMBOL_DECLARED
CHECK_SYMBOL_WORKS

>>> We compile strict and the trick used results in a compile error when we
>>> test for the fileno symbol:
>>>
>>> error: ISO C forbids conversion of function pointer to object pointer type

This is a problem because we don't know the type of the symbol.
It could be data or it could be a function. That's why the old
approach used a "..." argument for it. Whatever flag you're using
for such strictness could perhaps be stripped for these checks.
 
We cannot strip the flag, we are specifically testing the availability and working condition of symbols under different strictness settings.

We need to know that "-std=c99 -pedantic" causes kill() to no longer be declared because it's a POSIX function, not a c99 function, but that it's also still available (or not) so we can choose to use it (or not).  There are lots of symbols we need to account for in that manner.

It possible to quell that conversion warning.  Perhaps something like this:  ((char *)(long)&SYMBOL)[argc] + 1

Cheers!
Sean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130605/336e9478/attachment.html>