On Tuesday 22 January 2013, Stephen Kelly wrote: > Alexander Neundorf wrote: > > Hi, > > > > I pushed the FindPackageCheckArchLinuxSymlinks branch to stage, haven't > > merged it yet. > > Hi, > > A conversation a few weeks ago on IRC hinted that gentoo are doing the same > thing now/soon. > > I just searched and found http://wiki.gentoo.org/wiki//usr_move which also > links to http://fedoraproject.org/wiki/Features/UsrMove which is talking > about symlinking the root directories into /usr, including the lib64 > directory. > > Given that, at least your method naming could be made more generic (ie > CheckArchLinuxSymlinks is not a good name). > > You wrote a comment 'the 64/ directories are searched before the other > directories'. Is that a cmake feature? Can those directories which are > symlinks be excepted from that priority? Does that make any sense? Will we > get problems arising from the non-64 directories? Is CMake searching in > /lib* before /usr/lib/* ? Should that be changed?
AFAIK the lib64 dirs are searched first, then the versions without "64" appended. Which has the effect that /lib64/ is searched before /usr/lib/. OTOH if somebody installs a package to /, the config file will be in /lib/cmake/foo/FooConfig.cmake, and the include dir may be /usr/include/foo/. But this config file will then be found as /usr/lib/cmake/foo/FooConfig.cmake, and it will reference the include dir as /usr/usr/include/foo/ I think. So I think changing the search order does not help. If searching one way, one case fails, if searching the other way, the other case fails. If lib/ (or lib64/) is a symlink from one prefix into another prefix, and not all subdirs are symlinked, it will fail. I think this is all a mess for cmake's config files, as long as they try to be relocatable. Should we just forget about relocatable Config.cmake files on UNIX (excluding OSX) systems ? > > It makes cmake warn if /lib64/ is a symbolic link to /usr/lib/ and a > > Config.cmake file has been found in one of both (since any relative > > directory references may be wrong then), see the "General Config.cmake > > file issue on ArchLinux" thread here from November. > > Given that Andrea Scarpino said that the /include dir does not exist, I > don't see why you check for it in your patch. Maybe somebody adds it in the future... Mostly to make visible what should be there so that it works. > Checking whether /usr/lib is a symlink to /lib64 was one of the ideas we > came up with, but I still think I prefer a more generic symlink check > somehow, but I'm not about to dig into that at the moment. I'm not sure more generic is necessary. Also I don't see a way how to fix it actually. 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
