Zitat von Micha Renner <micha.ren...@t-online.de>:
Am Donnerstag, den 29.09.2011, 09:22 +0200 schrieb Hendrik Sattler:
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?
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.
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
