Am Donnerstag, den 29.09.2011, 10:32 +0200 schrieb Hendrik Sattler: > 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. 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 -- 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