[cmake-developers] FindPackageCheckArchLinuxSymlinks branch on stage

Alexander Neundorf neundorf at kde.org
Tue Jan 22 15:02:29 EST 2013


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



More information about the cmake-developers mailing list