The issue with the install dirs...

David Faure faure at
Sun Dec 11 20:21:56 UTC 2011

On Sunday 11 December 2011 18:16:08 Alexander Neundorf wrote:
> So what the kconfig library would provide would be a variable which contains
> a  standard relative directory for installing those files

Yes, this is what I meant. Not an absolute path, of course.

> 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.

Right. Or maybe in all cases, even in different prefixes?
E.g. SYSCONFDIR set to etc/kde5 gives /etc/kde5 and $HOME/myprefix/etc/kde5.

> 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/.

How is this different from today's world, with Qt in /opt/qt5/lib, soprano in 
/opt/soprano/lib and qjson-git in $HOME/qjson/lib ?
We are not inventing anything new here.

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

Neither, I would say. You install into $CMAKE_INSTALL_PREFIX/$LIB_INSTALL_DIR
where LIB_INSTALL_DIR is set by cmake (e.g. GNUInstallDirs.cmake if that does 
the job).

If e.g. openSUSE wants to install everything into lib64, then it has to 
configure cmake to do so. I.e. cmake should install a file that contains the 
relative paths to use (that's what I meant by a ConfigFoo-like file, but ok, 
it's about relative paths only).

David Faure, faure at,
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

More information about the Kde-buildsystem mailing list