The issue with the install dirs...
neundorf at kde.org
Tue Dec 13 20:23:52 UTC 2011
On Sunday 11 December 2011, David Faure wrote:
> 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
> > 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.
Well, the libraries you mention are not KDE-libraries, they don't form an
integrated environment, so they have to care for themselves.
Any KDE application with KDE4 had the feature that it was automatically
provided with reasonable install locations, provided by KDE (i.e. kdelibs).
If we don't need that, fine, than every application can take care for their
install dirs itself.
You know, it's perfectly fine to do
install(FILES foo.h bar.h DESTINATION include/mylib/ )
in your CMakeLists.txt. No variables are necessary at all. All we loose is
standard variable names and reasonable defaults (which is not a problem if the
maintainer of the library really maintains it, including its build system).
> > 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.
Yes, this is no problem.
> 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).
CMake cannot know what types of install paths your application may need (ok,
some). So that's why in kdelibs we provided the superset of all install paths
used in any KDE application, so it becomes less work for KDE developers, and
they have to care less.
It's not that it made something possible which wasn't possible before, it just
added convenience. By stating "I am a KDE application" (by doing
find_package(KDE4)), you got this set of install dirs.
Somewhat similar, do we still have the plan to provide like a wrapper
FindKF5.cmake/KF5Config.cmake, which will include all libraries making up KF5
If so, which library/package should install that ?
Who will install the file which contains the compiler flags we recommend to
use for KDE ?
Maybe the same as the one defining the install dirs ?
More information about the Kde-buildsystem