Alexander Neundorf wrote:
> 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 ?
Maybe it would be better to build some awareness into CMake of which
platforms are symlinking like this, and what they are symlinking. That way,
if a Config file is found in /lib64/lib/cmake/FooConfig.cmake, cmake would
be able to 'switch' to use the non-symlink, which would make the relative
paths correct, as long as the actual install was all into non-symlinks.
Something like this in Linux.cmake (partly pseudocode):
if (ARCHLINUX OR FEDORA18)
set(PLATFORM_SYMLINK_PAIRS
"/lib64" "/usr/lib64"
"/bin" "/usr/bin" # For illustration only. Config files don't get found
below /bin, so this doesn't matter.
)
endif()
Would something like that work? It might not help in the case of someone
installing to /opt/foo and then putting *that* in their CMAKE_PREFIX_PATH,
but that's a bug the user is creating in their own environment anyway, not a
platform quirk for us to handle, so it doesn't matter.
>
>> > 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...
If that matters (I don't believe it does) you should add at least everything
else which is in GNUInstallDirs.cmake.
Thanks,
Steve.
--
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
