On Thursday 29 November 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: > > On Saturday 17 November 2012, Alexander Neundorf wrote: > >> Hi, > >> > >> maybe I am missing something, but here we go: > >> > >> on 64bit ArchLinux installations, /lib64/ is a symlink to /usr/lib/. > >> /bin/ and /usr/bin/ are normal directories, no symlinks. > >> > >> Now if a Config.cmake files is installed into /usr/lib/foo/, and > >> references other files of its installations using relative paths from > >> its own location to e.g. /usr/bin/ (../../bin/ ), there is breakage. > >> > >> CMake finds FooConfig.cmake in /lib64/foo/FooConfig.cmake (which it > >> seems to search before /usr/lib). Then it goes ../../bin/, but doesn't > >> end up in /usr/bin/, where e.g. some executable is located, but instead > >> it goes to /lib64/foo/../../bin/, which is /bin/, but the expected > >> executable is not there, and so the FooConfig.cmake file fails. > >> > >> I'm not sure what the right way to deal with this is. > >> Is this only on ArchLinux ? > >> If so, maybe the best thing to do is to tell the ArchLinux developers to > >> set up their symlinks in a different way ? > >> Having e.g. /usr/lib64/ point to /usr/lib/ would make it work I think. > >> Or if /lib64/ points to /usr/lib/, then maybe /bin/ should also point to > >> /usr/bin/. > >> Other ideas ? > >> Or can CMake be tweaked to handle this ? > > > > How about this: cmake could check whether /lib64 is a symlink to > > /usr/lib, and if so, skip /lib64 ? > > This will break Config files installed to /lib64/cmake/, but I would > > assume Config.cmake files in /usr/lib/cmake/ are much more common than in > > /lib64/cmake/. > > I thought about whether it would be possible to throw an error in the case > that a relative path from a config file crosses a symlink. > > I don't think there is any way to do that for variables such as > Foo_qmake_EXECUTABLE. I don't think it would be practical as any variable > set in a Config file could be doing anything.
Not completely. All install variables which are at cmake time somewhere below CMAKE_INSTALL_PREFIX are treated as relative to CMAKE_INSTALL_PREFIX. This is what the @PAKCAGE_INIT@ macro together with the @PACKAGE_FOO_DIR@ variables does. > However, for the IMPORTED_LOCATION property of an imported target, we > probably can. How ? When /lib64/cmake/Foo/FooConfig.cmake is found, /lib64/ is a symlink to /usr/lib/. But just the same way it could happen the other way round, that /usr/lib/ is a symlink to /lib64/. In that case, if /lib64/cmake/Foo/FooConfig.cmake would be found, there wouldn't be a symlink involved, and still we would hit the same problem. So this would not be a generic solution, it would also just happen to solve the current ArchLinux issue (which could also be solved by an explicit check for this exact situation). > Similarly, we could probably throw an error in the case of > handling INCLUDE_DIRECTORIES property on imported targets. > > It doesn't solve the immediate ArchLinux error, but I think it would be a > good improvement for the future. Handling specifically /lib64 as a symlink > doesn't account for the future (But I can't think of a better idea). Well, if you have a symlink, you don't know whether the symlink is the correct location or the target of the symlink is the correct destination. 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
