The issue with the install dirs...
Alexander Neundorf
neundorf at kde.org
Thu Dec 8 21:33:29 UTC 2011
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
More information about the Kde-frameworks-devel
mailing list