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

[Alexander Neundorf]

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 ?


Hackish idea:

in the generated Config.cmake file, get the install prefix as it is done now 
by going up from its own location.
Then use get_filename_component(REALPATH) to resolve a potential symlink.
If it was a symlink, we have two candidate install prefixes afterwards.
If one of our two install prefix candidates matches exactly the original 
CMAKE_INSTALL_PREFIX, use that.
This should fix the problem described here for ArchLinux, and can be put into 
the configure_package_config_file() macro.

Still, it doesn't feel good.

Or, when not on Windows and not on OSX, simply use absolute paths ?
This would make the packages non-relocatable on Linux, BSD, Solaris.

Alex