[CMake] How to installing cmake Config.cmake files under Debian multiarch ?

[Alexander Neundorf]

On Wednesday 03 August 2011, Brad King wrote:
> On 8/3/2011 11:41 AM, Alexander Neundorf wrote:
> > On Tuesday 02 August 2011, Hendrik Sattler wrote:
> >> If you use cmake 2.8.5, you can use GNUInstalldirs.cmake and let the
> >> user specify the multiarch directory to install in (or solve it once in
> >> that cmake module).
> > 
> > You mean having the user adjust the lib install dir correctly manually ?
> > Hmm, I think it is not realistic to expect that users will know about
> > that. There must be a way to do this so that it is works automatically,
> > at least so that a cmake on the same system will find what was
> > installed.
> 
> See discussion here on why we can't transform the install() DESTINATION
> options magically:
> 
>    http://www.cmake.org/Bug/view.php?id=11964#c25884
> 
> The conclusion was that user code that intends to support such cases
> must reference a variable in its install destinations.  

Yes, that's fine.
Is there already a variable which contains the multiarch triplet, so I can do 
something like lib/${CMAKE_MULTIARCH_TRIPLET}/... ?

Slightly different question: if a Config.cmake file is installed on a 
multiarch debian system, will it also be found if installed in lib/ or lib64/ 
(i.e. without the multiarch triplet) ?

> The GNUInstallDirs module provides a good variable to reference:
> 
>   
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/GNUInstallDirs.cmake;
> hb=v2.8.5#l71
> 
>    install(... DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/Foo)


That's mostly fine, but I see an issue with this, again for the Config.cmake 
files.
We discussed this in Randa with packagers from SUSE, Debian and FreeBSD. They 
agreed that they don't see any reason to have the include in a different 
prefix than the libdir.
So we decided to recommend _not_ to put LIBDIR and INCLUDEDIR in the cache 
(this is still done with kdelibs4, but I think this was a bad decision back 
then).

Reason: when I install a FooConfig.cmake file, I expect it not only to set 
FOO_LIBRARY, but also FOO_INCLUDE_DIR.
How can lib/cmake/Foo/FooConfig.cmake know where the include dir is ?

If the include install dir was a relative path at build time, and if the lib 
install dir was a relative path at build time, then the FooConfig.cmake can 
know how to get from its own location to the installed include dir.
That's the good case.

Now, if the include and/or lib install directories are in the cache, the user 
can set them to absolute locations.
Under Windows this can also be under different drive letters.
What we are doing with kdelibs4 is to put the complete absolute path in the 
FooConfig.cmake file. This is fine for Linux, but sucks for Windows.
Because there, the user wants to decide at install time (of a binary package), 
where and on which drive he installs the package.
Let's say he decides for d:/mystuff/, but the incdir was set to the absolute 
path c:/include and the libdir to the absolute path c:/lib, how can the 
FooConfig.cmake which will be in d:/mystuff/lib/cmake/Foo/ figure out that the 
include dir is now d:/mystuff/include instead of c:/include ?

We didn't see a way how to do this, so we decided those directories should not 
be in the cache, so we can be sure they are never absolute.

What is in the cache is a suffix for the lib install dir.

Alex