On Thursday 06 December 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: > > On Thursday 06 December 2012, Stephen Kelly wrote: > >> Alexander Neundorf wrote: > >> > 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). > >> > >> Ok. Now I'm even more confused. > >> > >> I thought /opt/foo/share/ is incorrect. Correct would be > >> /usr/local/share. > > > > No. Above I wrote "has been installed to /opt/foo". > > Ah, this is indeed the crucial point that I missed. Thanks. > > So you're saying that the Config file is *deliberately* under a path that > contains /opt/foo and it has been found there. However, it could also be > found under /usr/local/ instead, and that is where it *actually* is. In > that case it would not work, so I still think it's fragile.
Yes, it's fragile. > I also think it's a very bad idea to install into a prefix where one of the > directories below it is a symlink to somewhere else. I think that also > deserves a warning. See below, you can get the same problem if you install into a prefix where there is no symlink, but the Config.cmake file can later be found via a different path using a symlink. > > I.e. into /opt/foo/lib/cmake/Foo/FooConfig.cmake and e.g. > > /opt/foo/share/foo/whatever.file > > > >> You are assuming that /opt/foo/share/ is a symlink to /usr/local/share, > >> right? > > > > No, I'm assuming that /opt/foo/lib/ is a symlink to /usr/local/lib/. > > So that when installing FooConfig.cmake to the prefix /opt/foo/, this > > file ends up in /opt/foo/lib/cmake/Foo/FooConfig.cmake (via the > > symlink), which is the same as /usr/local/lib/cmake/Foo/FooConfig.cmake > > (no symlink). The correct one to be found is the one in /opt/foo/, which > > contains the symlink. > > > >> That's why I wrote 'assuming there are not appropriately similiar(!) > >> symlinks for those too'. Isn't exactly that kind of assumption the > >> source of the original problem on Arch? They have a symlink for lib, > >> but not for bin. > >> > >> Are you confused too? Am I making sense? > > > > My confused mind thinks I'm not confused... ;-) > > Ok, I think we're on the same page now in terms of what we're talking > about. > > The difference is though that I think your scenario is also a bad idea and > deserving of a warning. I don't think we disagree. I agree that using symlinks like this is a bad idea. But issuing a warning in the example above would issue a warning in the case that the package has been successfully found, but no symlink-related warning if the package was not found successfully. I would hope that such symlink are rare, and maybe that the ArchLinux /lib64 -> /usr/lib symlink is one of the few instances, and that this very special case may justify some special treatment. It's no problem anymore if all subdirs would be linked this way consistently. 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
