Am 12.11.2011 10:40, schrieb Ralf Habacker:
Am 11.11.2011 17:01, schrieb Alexander Neundorf:
On Friday 11 November 2011, Ralf Habacker wrote:
Hi,
in the past the KDE on Windows port has been faced with install path
related issues caused by the fact that in opposite to unix/linx the end
user install location differs from the build time install location.
While several issue has been solved in the past, others may be still
present.
Patrick von Reth for example reported shortly ago that there are
problems with dbus service files generated by the build system. The
generated install location points to the build install location, which
will not work on end users workstation.
A few days ago Alexander Neundorf, the maintainer of the KDE
buildsystem, asked me if there are still such problems, so if anyone
know about open install location related problems, please report.
- On the kdepim meeting this year in osnabrück Andre Heinecke and I
recognized a home dir problem between independent KDE installations on
windows like kdepim setup installer and community distribution.
Currently independent installations depends on the same home dir,
which may produce unwanted interferences and/or conflicts
- in ksyscoca database (affects system settings modules)
- application settings
- There is a kde-runtime windows platform config module, which sets
install root depending registry keys
https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/show/platforms/win/config
- There is a kde-runtime system context menu module, which sets
insstall root depending registry keys
https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/show/platforms/win/contextmenu.
Currently people can use environment variables to define a different
home dir, but this do not help gui orientated os like windows. A
solution will be to have a kind of use-install-root-related-home-dir.
This would be extremly helpfull with usb-stick installations, where
the home dir(s) are also on the usb stick.
Please not only about the places where they are still open, but also
those
places where it has been already fixed/worked around/hacked to make
it work
somehow.
From my memory these are:
- dbus daemon determines the location of config files from the
location of the dbus executable
http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-win.c#n3182
- dbus provides an install root limited session bus
http://dbus.freedesktop.org/doc/dbus-specification.html#meta-transports-autolaunch
- dbus is going to determine the location of executables in dbus
service files from the location of the dbus-daemon executable (use
BIN_INSTALL_DIR as service executable path, dbus patch required)
- qt determines several dirs base from a dedicated qt.conf relative
to the install root
https://projects.kde.org/projects/kdesupport/emerge/repository/revisions/master
/entry/portage/libs/qt/qt.conf
- kde4-config determine the install root by the location of the
kdecore shared library -
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kdecore/kernel/kkernel_win.cpp#L97
I'm not sure if this is all.
I remember that there were also issues with build time related pathes in
cmake generated and installed dependency files like
KDELibsDependencies.cmake
Ralf
_______________________________________________
Kde-windows mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-windows
