Re: [cmake-developers] RFC: standard (and not so standard) install dirs
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
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: standard (and not so standard) install dirs
On Wednesday 11 January 2012, Brad King wrote: ... 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: Depends on the definition of too ;-) I'll see whether I can come up with some macro or helper file to make it easier. 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. Yes, that's basically what I do here too: https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem/HowToInstallALibrary 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. Thanks for taking your time to read and respond to this :-) Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] RFC: standard (and not so standard) install dirs
Hi,
here comes a quite lengthy mail on issues I see in KDE but also in general
with install dirs and CMake.
in KDE we define a set of variables which hold the install destinations for
several different file types:
EXEC_INSTALL_PREFIX(${CMAKE_INSTALL_PREFIX})
SHARE_INSTALL_PREFIX (share)
BIN_INSTALL_DIR(${EXEC_INSTALL_PREFIX}/bin)
SBIN_INSTALL_DIR (${EXEC_INSTALL_PREFIX}/sbin)
LIB_INSTALL_DIR(${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX})
LIBEXEC_INSTALL_DIR(${LIB_INSTALL_DIR}/kde4/libexec)
INCLUDE_INSTALL_DIR(include)
PLUGIN_INSTALL_DIR (${LIB_INSTALL_DIR}/kde4)
IMPORTS_INSTALL_DIR(${PLUGIN_INSTALL_DIR}/imports)
CONFIG_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/config)
DATA_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/apps)
HTML_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/doc/HTML)
ICON_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/icons)
KCFG_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/config.kcfg)
LOCALE_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/locale)
MIME_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/mimelnk)
SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/kde4/services)
SERVICETYPES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/kde4/servicetypes)
SOUND_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/sounds)
TEMPLATES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/templates)
WALLPAPER_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/wallpapers)
DEMO_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/demos)
KCONF_UPDATE_INSTALL_DIR (${DATA_INSTALL_DIR}/kconf_update)
AUTOSTART_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/autostart)
XDG_APPS_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/applications/kde4)
XDG_DIRECTORY_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/desktop-directories)
XDG_MIME_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/mime/packages)
SYSCONF_INSTALL_DIR(${CMAKE_INSTALL_PREFIX}/etc)
MAN_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/man)
INFO_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/info)
DBUS_INTERFACES_INSTALL_DIR(${SHARE_INSTALL_PREFIX}/dbus-1/interfaces)
DBUS_SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/dbus-1/services)
DBUS_SYSTEM_SERVICES_INSTALL_DIR (${SHARE_INSTALL_PREFIX}/dbus-1/system-
services)
As you can see, some of them are very generic, and make sense for about any
package, like LIB_INSTALL_DIR and BIN_INSTALL_DIR, some are quite KDE-
specific, like SERVICETYPES_INSTALL_DIR and KCONF_UPDATE_INSTALL_DIR, some are
related to other packages, like e.g. XDG_DIRECTORY_INSTALL_DIR and
DBUS_SERVICES_INSTALL_DIR.
These variables are defined in FindKDE4Internal.cmake, so any package doing
find_package(KDE4)
can make use of these variables for installing its stuff.
Which features/advantages does this bring:
1) all these variables can be adjusted via the cache, so users/packagers can
tweak where stuff is installed to
2) the variables which can be tweaked have standard names, so it's the same
for all KDE4-packages
3) and a special extra feature: if a project which uses kdelibs is installed
to the same CMAKE_INSTALL_PREFIX as kdelibs, all these variables are
initialized to the values from kdelibs.
E.g. if kdelibs is installed in /opt/kde, and SYSCONF_INSTALL_DIR was set to
/etc for kdelibs, for any application which does find_package(KDE4) and
where CMAKE_INSTALL_PREFIX is also set to /opt/kde, SYSCONF_INSTALL_DIR will
be set to the value from kdelibs, i.e. /etc.
So far, so good.
With the ongoing modularization of kdelibs we'd like to standardize this a bit
more and using a more generic, non KDE-specific solution.
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.
It provides the following install destinations:
CMAKE_INSTALL_BINDIR (bin)
CMAKE_INSTALL_SBINDIR (sbin)
CMAKE_INSTALL_LIBEXECDIR (libexec)
CMAKE_INSTALL_SYSCONFDIR (etc)
CMAKE_INSTALL_SHAREDSTATEDIR (com)
CMAKE_INSTALL_LOCALSTATEDIR(var)
CMAKE_INSTALL_LIBDIR (lib or lib64)
CMAKE_INSTALL_INCLUDEDIR (include)
CMAKE_INSTALL_OLDINCLUDEDIR(/usr/include)
CMAKE_INSTALL_DATAROOTDIR (share)
CMAKE_INSTALL_DATADIR (DATAROOTDIR)
CMAKE_INSTALL_INFODIR (DATAROOTDIR/info)
CMAKE_INSTALL_LOCALEDIR(DATAROOTDIR/locale)
CMAKE_INSTALL_MANDIR (DATAROOTDIR/man)
CMAKE_INSTALL_DOCDIR (DATAROOTDIR/doc/PROJECT_NAME)
This is mostly a subset of the variables defined by KDE.
There are some additional variables (CMAKE_INSTALL_OLDINCLUDEDIR,
CMAKE_INSTALL_SHAREDSTATEDIR, CMAKE_INSTALL_LOCALSTATEDIR) which do not
