Where to put KDE Frameworks cmake stuff...

[David Faure]

On Saturday 21 April 2012 15:43:47 Alexander Neundorf wrote:
> If you say we don't need shared install locations (a KDE frameworks-using 
> package picks up the custom install locations from the KDE frameworks it is 
> built against if it is installed into the same prefix), then please first
> make sure that this feature is really not wanted - by frameworks
> developers, by kde-core developers, by KDE SC developers, by 3rd party KDE
> developers, by packagers, by users.
> I added this feature on request from somebody, may have been packagers.

Yes, this was initially Coolo's work on KStandardDirs in kde2 or kde3, for the 
benefit of SuSE or Debian packaging in particular. He made it work with 
autoconf/automake, so he requested that cmake does it too.

The goal is to make it possible for distros to configure standard paths (at 
kdelibs-configuration time), so that e.g. they can put config files in /etc/kde4 
instead of /usr/share/config.

> They  expected that if they installed kdelibs and set up their install
> locations in some way in kdelibs (e.g. for the .desktop files), that
> additional packages which were built against this package and installed to
> the same location would automatically use the same install dirs.

Yes, but this doesn't really make sense anymore.

Most of the important standard dirs now come from XDG_*_DIRS, which Qt itself 
(QStandardPaths) handles. So this has nothing to do with "kdelibs" (KDE 
Frameworks) configuration anymore. It applies to all Qt apps.

If a distro wants config files in /etc/kde-kf5, then have to export 
XDG_CONFIG_DIRS (as per the XDG spec) and.... ok, somehow tell the build 
system. So something has to be invented to make it possible to change cmake's 
install paths, yes, but this something has nothing to do with KF5 compilation 
itself. I guess this is "just" about setting parameters, in some cmake file, 
that ECM reads from.

This is different from KDE4, where the default paths were compiled into 
KStandardDirs, and where no env vars were necessary at runtime. But the goal 
is to use exclusively the XDG spec now, so setting an env var will be very 
much necessary [and it will not be possible anymore to tweak every single 
install dir, since most of them moved to be a subdir of XDG_DATA_DIRS now, but 
that was over-configurability anyway].
E.g. the "icons" resource was "share/icons but configurable", now it's "the 
icons subdir under XDG_DATA_DIRS", and making that subdir name configurable is 
totally useless, the location of the parent is already configurable (via export 
$XDG_DATA_DIRS).

In fact, if a distro sets XDG_CONFIG_DIRS, then they'll have to not only 
ensure KF5-based apps install into that config dir, but also every app that 
uses XDG (all Qt apps, probably all gnome apps, etc. etc.). This doesn't 
really seem doable, unless the magic is higher up (e.g. in a RPM macro).

I think this leads to the conclusion that the time for setting up per-distro 
custom install dirs for KDE is over.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5