[CMake] Does find_library check that a found library does in fact link?

[Micha Renner]

Am Donnerstag, den 29.09.2011, 10:32 +0200 schrieb Hendrik Sattler:
> Zitat von Micha Renner <Micha.Renner at t-online.de>:
> 
> > Am Donnerstag, den 29.09.2011, 09:22 +0200 schrieb Hendrik Sattler:
> >> Zitat von Michael Wild <themiwi at gmail.com>:
> >> > Just a few of my thoughts on this:
> >>
> >> Same for me.
> >>
> >> > - There are several ways to handle dead symlinks:
> >> >   1. Don't check, let the linker complain (status quo)
> >> >   2. Check whether the found library is a symlink, and if not valid,
> >> >      remove it silently from the list of candidates. Can be very
> >> >      surprising and will likely result in quite a few bug reports
> >> >      about CMake not finding a certain library that is "clearly" there.
> >> >   3. Like 2, but warn about the issue. Possibly very annoying.
> >> > I don't know which option to prefer (perhaps somebody finds another one
> >> > that is better?). IMHO bogus symlinks to shared libraries constitute a
> >> > real problem of the library installation, so CMake shouldn't just paper
> >> > over it by silently skipping the dead link, proceeding to the next
> >> > candidate which rules out option 2 for me. Also, option 3 can be
> >> > troublesome in automated setups where no user actually reads the CMake
> >> > output.
> >>
> >> People tend to misunderstand the purpose of build systems like CMake
> >> and autotools. They try to make the detection bullet-proof and most
> >> likely fail. You can see that this is wrong by looking at those auto*
> >> setups that take ages to detect all possible header files and use an
> >> ifdef hell to handle that in the code, run lots of link and
> >> symbol-finding tests, and still fail on conditions that the author
> >> simple didn't consider or know.
> >>
> >> I prefer option 1. It's not CMake's duty to detect or paper over
> >> messed-up systems. That's the administrator's job!
> >> BTW: running "ldconfig -v" on Linux likely tells you about the
> >> dangling symlink.
> >>
> >> What's next? Asking for a syntax check of found header files so that
> >> the compiler doesn't complain on broken header files?
> >
> > This is exactly what CHECK_INCLUDE_FILES does (via TRY_COMPLIE).
> > It works good as long as the header file has no predecessor. In that
> > case CHECK_INCLUDE_FILES reports FILE-NOT-FOUND. It would save a lot of
> > time, if there would be notice that CHECK_INCLUDE_FILES tests the header
> > file.
> > "Check if the files can be included" is not enough.
> 
> And what does it gain you to do this check except wasting time during  
> build configuration? Do you really check that any add_definitions()  
> does not alter the result? After all, you only get the real result  
> during project compilation.
That is not my point. 
I only say that CHECK_INCLUDE_FILES already tests header files and
CHECK_INCLUDE_FILES reports FILE-NOT_FOUND if the tested header file
needs a predecessor header file.
I bet, that in this case many users rack their brains why
CHECK_INCLUDE_FILES does not find the header file, despite they can see
it in the directory and this should be documented.

The rest is a decision of the maintainers, which I do not comment.

Greetings
Micha

> 
> HS
> 
> 
> --
> 
> 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