[cmake-developers] FindPackageCheckArchLinuxSymlinks branch on stage

[Alexander Neundorf]

On Thursday 24 January 2013, Alexander Neundorf wrote:
> On Thursday 24 January 2013, Brad King wrote:
> > On 01/24/2013 12:39 PM, Alexander Neundorf wrote:
> > > Also, it could have been installed into the symlink, but be found via
> > > the non- symlink path.
> > 
> > Right, it is not possible to handle installing into a symlink because we
> > cannot know that when computing paths ahead of time.
> > 
> > The two competing goals are:
> > 
> > * Relocatable package.  This is for binary tarball distributions and we
> > 
> >   can assume there will be no symlink mess because we control the
> >   tarball. If someone extracts it in a system prefix then they are on
> >   their own.
> > 
> > * Distro-maintained package.  This has a fixed install path and should
> > 
> >   simply use full paths.
> > 
> > I do not think we should try to handle cross-prefix symlinks at the same
> > time as relocatable packages.  The remaining issue is how to know which
> > one the current build wants.  Ideas?
> 
> Symlinks could appear in any prefix.
> But do we have to care about that, or is it good enough if we try to make
> the /lib[64]/ symlinks related to the ongoing /usr-move work ?
> 
> Gentoo just wants to symlink files, which would be ok for cmake:
> http://wiki.gentoo.org/wiki//usr_move
> 
> Fedora, ArchLinux, Mageia symlink the directories:
> https://fedoraproject.org/wiki/Features/UsrMove
> https://wiki.mageia.org/en/Feature:UsrMove
> https://wiki.archlinux.org/index.php/DeveloperWiki:UsrMove
> 
> The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its
> INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/ and
> use full paths in that case.
> 
> I'll play around a bit with the macro.

There is now the PackageConfigHelper_UsrMove branch on stage.

If the Config.cmake will be installed to /lib(64) or /usr/lib(64), it will use 
full absolute paths.
Building a package with this should help with the  /usr-move changes.

I haven't merged it yet.
If there are no objections or better ideas, I'll merge it tomorrow.

We should then try to convince /usr-move distributions to use this new version 
of cmake as soon as possible.


Alex