On Thursday 06 December 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: > > Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/. > > The package has been installed to /opt/foo/ and is found via > > CMAKE_PREFIX_PATH in /opt/foo/lib/cmake/Foo/FooConfig.cmake. > > Now when going up to the prefix, we will come across /opt/foo/lib/, which > > is a symlink, but everything will be fine, since going up will take us to > > /opt/foo/, from where we can correctly descend again. > > But that works only if you don't search for anything in bin/ or share/, > right (assuming there are not appropriately similiar(!) symlinks for those > too)?
Hmm, no ? /opt/foo/lib/cmake/Foo/../../../share/ is /opt/foo/share/, which would be correct (when the package has been installed to /opt/foo/, as said above). > Seems fragile to me. > > This is exactly the original Arch problem, right? That means I don't think > it is 'correctly descending', it just sometimes happened to work by chance. > That's why I think it's fragile. > > > If the package would have been found in > > /usr/local/lib/cmake/Foo/FooConfig.cmake (e.g. because CMAKE_PREFIX_PATH > > was not set), then we would get the problem > > Are you missing a 'not' in this sentence? No. /usr/local/lib/cmake/Foo/../../../share/ is /usr/local/share/, which would be wrong. > > , but here there would be no > > symlink (other than if it would be possible to test whether a directory > > is the destination of a symlink). > > > > It's a problem if the symlinked location is not the location to which the > > package has been installed, but for whatever reason the symlinked > > location is found first. > > Yes, exactly. If the symlinked location is found first, and the symlink > reaches into the prefix (so that all relative paths which have to reach > back though the prefix end up somewhere unexpected), then the relative It doesn't matter whether the location which is found, has been found via the symlink or via a "normal" path. It matters whether the location where it has been found is in the correct prefix. > paths will not work as expected. If the symlinked Config file is found > first, then it appears that the installation was to a 'split prefix' - > partly in /opt/foo/ and partly in /usr/local/, which is something the > Config file will not expect. Yes, I would even say that making a subdir in a prefix a symlink into a different prefix is generally bad (no matter whether it's from / into /usr/, or from /usr/local/ into /usr), because it destroys as we see the relative paths between the subdirs. Alex -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
