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

[Alexander Neundorf]

On Thursday 06 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
> > The package has been installed to /opt/foo/ and is found via
> > CMAKE_PREFIX_PATH in /opt/foo/lib/cmake/Foo/FooConfig.cmake.
> > Now when going up to the prefix, we will come across /opt/foo/lib/, which
> > is a symlink, but everything will be fine, since going up will take us to
> > /opt/foo/, from where we can correctly descend again.
> 
> But that works only if you don't search for anything in bin/ or share/,
> right (assuming there are not appropriately similiar(!) symlinks for those
> too)? 

Hmm, no ?

/opt/foo/lib/cmake/Foo/../../../share/ is /opt/foo/share/, which would be 
correct (when the package has been installed to /opt/foo/, as said above).

> Seems fragile to me.
> 
> This is exactly the original Arch problem, right? That means I don't think
> it is 'correctly descending', it just sometimes happened to work by chance.
> That's why I think it's fragile.
> 
> > If the package would have been found in
> > /usr/local/lib/cmake/Foo/FooConfig.cmake (e.g. because CMAKE_PREFIX_PATH
> > was not set), then we would get the problem
> 
> Are you missing a 'not' in this sentence?


No.
/usr/local/lib/cmake/Foo/../../../share/ is /usr/local/share/, which would be 
wrong.


> > , but here there would be no
> > symlink (other than if it would be possible to test whether a directory
> > is the destination of a symlink).
> > 
> > It's a problem if the symlinked location is not the location to which the
> > package has been installed, but for whatever reason the symlinked
> > location is found first.
> 
> Yes, exactly. If the symlinked location is found first, and the symlink
> reaches into the prefix (so that all relative paths which have to reach
> back though the prefix end up somewhere unexpected), then the relative

It doesn't matter whether the location which is found, has been found via the 
symlink or via a "normal" path. It matters whether the location where it has 
been found is in the correct prefix.

> paths will not work as expected. If the symlinked Config file is found
> first, then it appears that the installation was to a 'split prefix' -
> partly in /opt/foo/ and partly in /usr/local/, which is something the
> Config file will not expect.

Yes, I would even say that making a subdir in a prefix a symlink into a 
different prefix is generally bad (no matter whether it's from / into /usr/, 
or from /usr/local/ into /usr), because it destroys as we see the relative 
paths between the subdirs.

Alex