[cmake-developers] RFC: standard (and not so standard) install dirs

[Brad King]

On 1/10/2012 4:16 PM, Alexander Neundorf wrote:
 > These variables are defined in FindKDE4Internal.cmake, so any package doing
 > find_package(KDE4)
 > can make use of these variables for installing its stuff.

If I understand correctly there will no longer be a single base package that
every KDE project can find to get these things.  On the other hand, you want
to have a standard set of install variables without duplicating code.  These
goals are at odds.  Why not have a single base package just for CMake files:

   find_package(KDE4CMake)

?  It would be a very lightweight module but could totally solve this problem
and provide a central place for common KDE CMake macros/functions and such.
Otherwise even if we solve the problem at hand I expect you'll run into more
trouble looking for places to put common pieces.

That said, here are my comments assuming you don't go with the above.

> With the ongoing modularization of kdelibs we'd like to standardize this a bit
> more and using a more generic, non KDE-specific solution.

I'm not sure how it can be non-KDE because it uses the set of variables
that KDE needs.  Sure, there is some overlap with similar needs for other
projects (GNU), but that does not mean KDE can use a non-KDE set.  That's
why the case of the DBUS and other custom variables kept coming up in your
original post.

> Now since a few releases CMake has GNUInstallDirs.cmake.
> This module serves a similar purpose. Unfortunately it introduced different
> names for these variables, but ok.

That's why we included "GNU" in the name of the module.  It's the set
that GNU defines, which is not necessarily the set that KDE uses.

> Where should the missing variables be added ?
> Should they simply all be added to GNUInstallDirs.cmake ?
> Does it make sense to gather all kinds of install dir variables in one place ?

Just like GNU defines a standard set of variables for their projects, KDE
appears to do so as well.  We included the GNUInstallDirs module to make
it easy to convert projects following the GNU layout to CMake.  I see no
reason we couldn't do the same thing for projects following the KDE layout.

Why not create a KDEInstallDirs.cmake that comes with CMake?  It wouldn't
actually contain any KDE-specific code, just a documented layout standard
that could be used by KDE project or outside projects that like the KDE
install layout.  OTOH, if it needs to initialize paths like lib/kde4/libexec
then that is very specific to KDE and would not belong in a generic interface.

> Example: let's say we (KDE) switch to using GNUInstallDirs.cmake, and every
> KDE application should set CMAKE_INSTALL_LIBEXECDIR to
> ${LIB_INSTALL_DIR}/kde4/libexec/ instead of libexec/.
> This would be necessary to make those projects work, so it would be very
> desirable that some base package would install some file into some install
> prefix which sets CMAKE_INSTALL_LIBEXECDIR accordingly, and so the using
> project would get its install dir variable initialized correctly
> automatically.

Why can't the base package be responsible for defining the install locations
in the first place, as I propose at the top of this response?

> And there is one additional question I have:
> Is it actually necessary to make all those install dir variable editable for
> the user ?

The GNUInstallDirs is intended to follow the GNU layout rules to help projects
coming from autotools to CMake use the same layout.  It is intended that the
destinations be changeable by packagers looking to conform to their distro
layout.

> It comes with a cost, especially when we want people to start installing
> FooConfig.cmake files.
[snip]
> To support the fully flexible version, the developer must calculate the
> relative path from the configured CONFIG_INSTALL_DIR (where the Config.cmake
> file goes) to the configured INCLUDE_INSTALL_DIR.

It's not too hard.  See ITK for example:

   http://itk.org/gitweb?p=ITK.git;a=blob;f=CMakeLists.txt;hb=v4.0.0#l558

 > do you have suggestions how to make the code needed in the
 > Config.cmake files easier ?

I've done this for a few projects that allow such destinations to be changed.
If one destination is a full path then it can just be used as-is.  If it is
a relative path then I start by computing the installation prefix based on
the installation depth of the Config.cmake file using get_filename_component.
Then I add on the other relative destination.

I don't think the case that the Config.cmake install destination is absolute
and the others are relative to an installation prefix is important.  I see
no real-world use case to do things that way.

-Brad