On 09/29/2011 09:22 AM, Hendrik Sattler wrote: > 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.
A concrete example: Several years ago, I worked with an X11 system which - besides TCP/IP - was aware of DECnet, and pretty nobody has taken into account that there might be a dependency of libX11.so on libdnet.so. Consequently, I had countless packages - also from highly respected projects - that needed to be configured with LDFLAGS=-ldnet. Usually, that's all there was to it, and I was perfectly okay with it, i.e. I wouldn't expect from a project's configuration to take DECnet into consideration just because the project is configured for X11. > 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. Absolutely. Moreover, there are trivial day-to-day situations where even the most sophisticated configuration can't succeed, e.g. if the project needs a package that's simply not installed. In such a case, administrative action must be taken anyway, either one installs the package by oneself or asks the admin to do so. Therefore, it is my personal opinion that one should expend a reasonable effort to fit a project for the common configurational pitfalls, but trying to do as much as possible in this regard will become counterproductive at a certain point, in particular if one could easily counteract with administrative means. There is no such thing as portable software, only software that has been ported. -- Unknown [Annotation to chapter 1 of the imake book] > What's next? Asking for a syntax check of found header files so that > the compiler doesn't complain on broken header files? Equipping FIND_PATH() with a check if the file for which the path is to be returned is a valid header, and equipping FIND_PROGRAM() with a check if the program to be returned is a valid executable - with the same justification as for library checks in FIND_LIBRARY(). Regards, Michael -- 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