Zitat von Michael Wild <them...@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?
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
