The issue with the install dirs...

[Alexander Neundorf]

Hi,

in kdelibs4, every application using FindKDE4.cmake gets the following set of 
variables, which should be used as install destination with the install() 
command:

BIN_INSTALL_DIR  (default is prefix/bin)
BUNDLE_INSTALL_DIR  (default is /Applications/KDE4 )
SBIN_INSTALL_DIR (default is prefix/sbin)
LIB_INSTALL_DIR  (default is prefix/lib)
CONFIG_INSTALL_DIR
DATA_INSTALL_DIR
HTML_INSTALL_DIR
ICON_INSTALL_DIR  (default prefix/share/icons/)
INFO_INSTALL_DIR  (default prefix/info)
KCFG_INSTALL_DIR
LOCALE_INSTALL_DIR
MAN_INSTALL_DIR  (default prefix/man/)
MIME_INSTALL_DIR
PLUGIN_INSTALL_DIR  (default is ${LIB_INSTALL_DIR}/kde4)
IMPORTS_INSTALL_DIR
SERVICES_INSTALL_DIR
SERVICETYPES_INSTALL_DIR
SOUND_INSTALL_DIR
TEMPLATES_INSTALL_DIR  
WALLPAPER_INSTALL_DIR
AUTOSTART_INSTALL_DIR
DEMO_INSTALL_DIR
KCONF_UPDATE_INSTALL_DIR
SYSCONF_INSTALL_DIR  (default /etc)
XDG_APPS_INSTALL_DIR
XDG_DIRECTORY_INSTALL_DIR
XDG_MIME_INSTALL_DIR
DBUS_INTERFACES_INSTALL_DIR  (default is prefix/share/dbus-1/interfaces)
DBUS_SERVICES_INSTALL_DIR   (default is prefix/share/dbus-1/services )
DBUS_SYSTEM_SERVICES_INSTALL_DIR  (default  
${SHARE_INSTALL_PREFIX}/dbus-1/system-services)


These variable do not provide information about where something, e.g. xdg or 
dbus are installed on the system, they are the locations where the current 
application will install this kind of files to.

As opposed KDE4_LIB_INSTALL_DIR is the directory where kdelibs4 installed its 
libraries to (i.e. it provides information about something installed on the 
system).

I hope this makes the difference clear.

So this set of variables has 3 purposes:

1) it provides variables which can be adjusted by the user (the one who 
compiles the application) so it will install the stuff to where the user wants

2) it does that by offering a set of standard variables for that, so these 
variables have the same name in all kdelibs4-using projects.

3) additionally, as a special feature of KDE, defaults can be picked from what 
is already installed. This means if I install kfoo to the same 
CMAKE_INSTALL_PREFIX as kdelibs4, FindKDE4Internal.cmake notices that, and 
sets all the SOMETHING_INSTALL_DIR variables to the same value as they are for 
kdelibs4.
Example: I have installed kdelibs4 to /opt/kdelibs4, and LIB_INSTALL_DIR was 
set to /my/special/lib/dir/. If I now build an application kfoo with 
CMAKE_INSTALL_PREFIX=/opt/kdelibs4, cmake notices that this is the same as the 
kdelibs4 CMAKE_INSTALL_PREFIX, and initializes LIB_INSTALL_DIR to the value 
from kdelibs, i.e. /my/special/lib/dir/



For KF5 I'm quite sure we don't want to loose any of these three features.

1) could be achieved also without defining a set of variables in some commonly 
used file, but then 2) would be lost, which is an important feature. For 
autotools-projects there are well known command line switches for how to set 
the install destinations, with 2) we achieve a similar result for cmake.

2) means the variables are provided in one place, and nopt spread over 
different modules, e.g. the variable XDG_MIME_INSTALL_DIR is also defined in 
that central place (and thus has consistent naming and behaviour), and not 
e.g. in a FindXDG.cmake file.

By keeping feature 3), we add *some* common dependeny to all KF5 libraries. 
Not sure yet which dependency this will be.


Side note: since cmake 2.8.3 or so cmake ships with a file call 
GNUInstallDirs.cmake:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:GNUInstallDirs

This does something similar, it defines e.g. CMAKE_INSTALL_BINDIR, 
CMAKE_INSTALL_INCLUDEDIR, etc.

(I do not really like it, for one because it introduces a different set of 
names than what we have defined in KDE. I missed the point when it was added.)


So, first question: do we want to keep the names as we have them with 
kdelibs4, i.e. <FOO>_INSTALL_DIR, or do we want to switch to 
CMAKE_INSTALL_<FOO>DIR, so there are not two competing sets of "standard" 
names ?
(actually I'd like to prefer to stay with our names, I guess they are already 
mroe wide-spread).


And an idea how we could keep feature 3) (initializing install dirs depending 
on something which is already installed), without adding major dependencies, 
and while making it even more generally useful:

Assume we move our code which defines the install dirs into a file 
ECMInstallDirs.cmake, or we decide to use (and extend) GNUInstallDirs.cmake. 
Until we have decided this, I'll just call it OurInstallDirs.cmake:

Right now we would do
include(OurInstallDirs)
and this would create a set of (cache) variables for the install destination. 
But those would not yet have feature 3).

Now, we could e.g. add a cmake variable, which tells OurInstallDirs.cmake from 
which project it should initialize itself, when installed to the same prefix:

set(OUR_INSTALL_DIRS_USE_DEFAULTS KF5)
include(OurInstallDirs)

Then OurInstallDirs.cmake would, if OUR_INSTALL_DIRS_USE_DEFAULTS is set, 
check in some defined location, e.g. something like prefix/lib/cmake/KF5/, or 
prefix/lib/cmake/OurInstallDirs/ for a file like KF5InstallDirs.cmake.
If this is found, this means KF5 has been installed to the same prefix.
And, this file will contain the install directories as used by KF5, and those 
values would be used to initialize the install dir variables of the 
application kfoo.

This could also be used by other projects. Maybe we can make it work so that 
e.g. DBUS_INTERFACES_INSTALL_DIR could be initialized from the existing DBUS 
installation if it is in the same directory.

OTOH... if an application uses DBUS, it will have used FindDBUS.cmake.
If the install destination would be set there, in FindDBUS.cmake, it could 
easily be initialized to the location where DBUS has been found, if is in the 
same CMAKE_INSTALL_PREFIX.

So maybe an ECMInstallDirs.cmake should just provide a set of basic install 
destination (i.e. not xdg and dbus), and a macro, which can be used to add 
another install destination with the special behaviour.
Then e.g. FindDBUS.cmake could do:

ecm_install_dirs_add_install_dir(DBUS_SERVICES_INSTALL_DIR DEFAULT_FROM DBus)

ecm_install_dirs_add_install_dir() would be somewhat similar to the 
_set_fancy() we have currently in FindKDE4Internal.cmake.

This would also mean that every module which wants to do that depends on that 
OurInstallDirs.cmake file, i.e. either on e-c-m, or on GNUInstallDirs.cmake.
I think the chances for adding a competing *InstallDirs.cmake to cmake are 
relatively low...


So, this was not a proposal, more a braindump...
Comments, ideas, etc. ?

Alex