[cmake-developers] General Config.cmake file issue on ArchLinux

[Alexander Neundorf]

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