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

[Stephen Kelly]

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.


However, for the IMPORTED_LOCATION property of an imported target, we 
probably can. 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).

Any thoughts on that?

Steve.