The issue with the install dirs...

[Alexander Neundorf]

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


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 ?


Alex