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

[Stephen Kelly]

Alexander Neundorf wrote:

>> I also think it's a very bad idea to install into a prefix where one of
>> the directories below it is a symlink to somewhere else. I think that
>> also deserves a warning.
> 
> See below, you can get the same problem if you install into a prefix where
> there is no symlink, but the Config.cmake file can later be found via a
> different path using a symlink.

<snip>

> I agree that using symlinks like this is a bad idea.
> But issuing a warning in the example above would issue a warning in the
> case that the package has been successfully found, 

It would also issue a warning at install time, if a location below 
${CMAKE_INSTALL_PREFIX} is a symlink.

> but no symlink-related
> warning if the package was not found successfully.

I don't fully follow (too much 'the example' etc :)), but I guess it's not 
too important. I think the two cases we're talking about are clear 

* Installing to a location where one or more locations below 
${CMAKE_INSTALL_PREFIX} are symlinks
* Installing to a location where locations below ${CMAKE_INSTALL_PREFIX} are 
not symlinks, but creating a symlink from outside the prefix to inside it.

> I would hope that such symlink are rare, and maybe that the ArchLinux
> /lib64 -> /usr/lib symlink is one of the few instances, and that this very
> special case may justify some special treatment.
> It's no problem anymore if all subdirs would be linked this way
> consistently.

For what definition of 'all' :) ? Just look at the amount of locations that 
GNUInstallDirs.cmake advertises as installing to. And that's only one 
'standard' - there are others. A distro can't predict what locations a 
package might install stuff to, particularly if installing to non-standard 
locations (Qt installs things to $prefix/qml $prefix/phrasebooks 
$prefix/mkspecs etc).
 
I don't think 'more symlinks' is the answer. I don't think adding symlinks 
can ever make a point where it's 'not a problem' can be reached.

Anyway, I think all the information needed to understand this issue is in 
the thread now.

Thanks,

Steve.