The issue with the install dirs...

[Alexander Neundorf]

On Friday 09 December 2011, David Faure wrote:
> On Thursday 08 December 2011 22:33:29 Alexander Neundorf wrote:
> > BIN_INSTALL_DIR  (default is prefix/bin)
> 
> Should we drop that one and use CMAKE_INSTALL_BINDIR?
> Wouldn't that make things more "standard"?
> I see what you're saying by "minimizing the porting effort", but that can
> be scripted easily, and on the other hand, it creates two worlds again,
> the "cmake-kde" world vs the rest of the world. So an app which starts
> without any "kde" dependency, will suddenly have to port all its install

I doubt that GNUInstallDirs.cmake is already widely used right now.

> dirs to the kde set, to avoid mixing both sets, if they need to use one of
> the kde features? That doesn't sound too appealing.

These are the variables provided by GNUInstallDirs.cmake:

CMAKE_INSTALL_BINDIR           - user executables (bin)
CMAKE_INSTALL_SBINDIR          - system admin executables (sbin)
CMAKE_INSTALL_LIBEXECDIR       - program executables (libexec)
CMAKE_INSTALL_SYSCONFDIR       - read-only single-machine data (etc)
CMAKE_INSTALL_SHAREDSTATEDIR - modifiable architecture-independent data (com)
CMAKE_INSTALL_LOCALSTATEDIR  - modifiable single-machine data (var)
CMAKE_INSTALL_LIBDIR         - object code libraries (lib or lib64)
CMAKE_INSTALL_INCLUDEDIR     - C header files (include)
CMAKE_INSTALL_OLDINCLUDEDIR  - C header files for non-gcc (/usr/include)
CMAKE_INSTALL_DATAROOTDIR    - RO architecture-independent data root (share)
CMAKE_INSTALL_DATADIR        - RO architecture-independent data (DATAROOTDIR)
CMAKE_INSTALL_INFODIR        - info documentation (DATAROOTDIR/info)
CMAKE_INSTALL_LOCALEDIR      - locale-dependent data (DATAROOTDIR/locale)
CMAKE_INSTALL_MANDIR         - man documentation (DATAROOTDIR/man)
CMAKE_INSTALL_DOCDIR         - documentation root 
(DATAROOTDIR/doc/PROJECT_NAME)

They are all put into the cache, so they are all user-modifyable, also from 
relative to absolute paths.

Do we want that ?
I know it makes some things harder.

If we want to install a Config.cmake file for each of our 
library/packages/frameworks, this is much easier if we know the install 
destinations are relative paths.
The Config.cmake file has to contain the information where e.g. the include 
dir is. In the example in kde-examples/buildsystem/ this is done like this:

set(BAR_INCLUDES "${rootDir}/@INCLUDE_INSTALL_DIR@")

This works, correct and simply, if the install destination is just a relative 
path.
In kdelibs we use the full path for all install destinations under UNIX.
This does not work under Windows, since there the user can decide at install 
time (of a binary package, which has been built on some completely different 
system), where to install the package to.
In that case, the full path configured into the Config.cmake file is just 
wrong.

That's why, when we can be sure the install destination e.g. for headers is a 
relative path, we can set it simply relative from the location of the 
installed Config.cmake file.


So, should we provide the option to modify all the install locations (via the 
cache) at all ?
It breaks in some cases, and it shouldn't be necessary at all in most cases. 
at least for most of the variables.
In Randa the present packagers agreed that e.g. there is not really a need to 
adjust the directory to which the headers will be installed, so 
INCLUDE_INSTALL_DIR would not have to be in the cache at all, and could simply 
be a normal cmake variable, if at all:
set(INCLUDE_INSTALL_DIR include )


In general, I would say every project should just put the definitions for the 
install destinations it needs somewhere in its toplevel CMakeLists.txt.

It depends on the project which ones it needs, it makes them as local as 
possible and they don't provide information about some other package.
But if done that way, there are no standard names for the install locations, 
which is something users (and packagers) want to have.
So what we need is basically one place where those variables are defined, so 
they have a common name in all projects.

This is already not the case anymore when those variables are spread over 
multiple files. GNUInstallDirs.cmake does not have the same set of variables 
as we have in FindKDE4Internal.cmake.

...
> > CONFIG_INSTALL_DIR
> > KCFG_INSTALL_DIR
> > KCONF_UPDATE_INSTALL_DIR
> 
> A thought: how about trying to make this modular too?
> E.g. you have no use in CONFIG_INSTALL_DIR, KCFG_INSTALL_DIR or
> KCONF_UPDATE_INSTALL_DIR if you're not using the kconfig library, so these
> vars could come from the kconfig library.

Kind of, but I'm not really sure.
What could/should come from the kconfig library, is a variable containing the 
information where kconfig has been installed to.
But this is (potentially) different from the destination where the current 
project wants to install its files to.
E.g. the directory where the installed kconfig expects stuff could be 
somewhere in /usr/local/, but the user wants to install something into its 
home, $HOME/mykf5stuff/.

So what the kconfig library would provide would be a variable which contains a 
standard relative directory for installing those files, and if the current 
CMAKE_INSTALL_PREFIX is the same as the CMAKE_INSTALL_PREFIX of the found 
kconfig library, then it will contain the relative install directory as has 
been used by kconfig.

It is kind of weird that the variable which decides something for the users 
project would come from a FindFoo.cmake file.


Another issue is that with modularization we can get completely new 
constellations. Right now, all of kdelibs is always installed into the same 
location, i.e. LIB_INSTALL_DIR is the same for all libraries in kdelibs.

How do we deal with that with a modularized kdelibs ?
kcore could be installed to /opt/kf5/lib, I want my own development version of 
kgui which is in $HOME/mykf5/lib/, and dbus could be in /usr/lib/.

From which of those do I want to pick up my LIB_INSTALL_DIR ?

With the monolithic kdelibs this is/was clear: anybody using kdelibs was a KDE 
application, and got the kdelibs install dirs.
But modularized ?

> > SERVICES_INSTALL_DIR
> > SERVICETYPES_INSTALL_DIR
> 
> These could be provided by the kservice library.
> 
> > MIME_INSTALL_DIR
> 
> You can remove that one, it was for kde3 desktop files.
> XDG_MIME_INSTALL_DIR below replaces it.
> 
> > LOCALE_INSTALL_DIR
> > MAN_INSTALL_DIR  (default prefix/man/)
> > PLUGIN_INSTALL_DIR  (default is ${LIB_INSTALL_DIR}/kde4)
> > IMPORTS_INSTALL_DIR
> > SOUND_INSTALL_DIR
> > TEMPLATES_INSTALL_DIR
> > WALLPAPER_INSTALL_DIR
> > AUTOSTART_INSTALL_DIR
> > SYSCONF_INSTALL_DIR  (default /etc)
> > 
> > XDG_APPS_INSTALL_DIR
> > XDG_DIRECTORY_INSTALL_DIR
> > XDG_MIME_INSTALL_DIR
> 
> XDG_*_DIR could be provided by cmake itself.
> 
> Not sure about some of the others though, a standard directory for sounds,
> file templates, and wallpapers don't really need shared code, one is just
> installing something for the desktop to pick up.
> 
> But OK, that's just a thought. It might make maintainance of the features
> you mention much harder, so feel free to disregard.
> 
> For feature 3, the main use case is compiling an app using libs from the
> distro, where some paths might have been adjusted. Can't this be solved
> with a single ConfigFoo-like file which sets the variables? 

No, see above. This is about the using project, a Config.cmake file provides 
information about the used project.

Alex