Setting paths which depend on CMAKE_INSTALL_PREFIX

[Maciej Mrozowski]

On Saturday 06 of June 2009 11:56:53 Andreas Pakulat wrote:
> On 06.06.09 11:15:11, Oswald Buddenhagen wrote:
> > On Sat, Jun 06, 2009 at 10:59:40AM +0200, Thiago Macieira wrote:
> > > Oswald Buddenhagen wrote:
> > > >that's a sign that the plugin system needs to be fixed, not that
> > > >the build system should be screwed up to compensate for it.
> > > >specifically, installing kde to another prefix than qt and still
> > > > having qt see kde plugins works just fine. copying that behavior
> > > > sounds like a fairly obvious and not particularly hard to implement
> > > > feature.
> > >
> > > The problem is when you ask an external process for information, like
> > > the database generated by kbuildsycoca4.
> >
> > i don't understand what you mean ... qt stores the kde plugin paths in
> > its config file, so things just work after initial auto-registration by
> > kdelibs. to make it even more deterministic, one could make the
> > registration step explicit at make install time.
>
> The problem is more with the .desktop files than the actual plugin libs.
> The .desktop files need to be read by kbuildsycoca4 and that one needs to
> know all prefixes in which it has to look for the desktop files. Obviously
> we could add our own install-macro for desktop files which stores the
> install prefix into a global kde config file which kbuildycoca2 would read.
>
> I'm not sure though that would help with the mandatory kbuildsycoca2 call
> before running an app thats been installed into a different prefix than
> kdelibs.

This problem is essentially what I've been dealing with recently to be able to 
set up multiple KDE installations aside (a few KDE4's along with KDE3) with 
3rd party KDE4 applications sitting in separate prefix.

Well, for general application icons (not services/kparts) .desktop files, 
setting XDG_DATA_DIRS is sufficient, plugins however need either to be 
installed in same prefix as KDE, or in KDEDIRS location or in kdeglobals/kderc 
(prefixes= in Directories group) .

At least on linux there's a code (kstandarddirs:1603)  that strips executable 
file name and one  directory component (supposedly "bin") from executable path 
read from /proc and adds it as additional prefix.

If that really works, then running applications from different prefix should 
not be a problem, provided standard directory layout is kept (and kdelibs 
prefix is added anyway - kstandarddirs.cpp:1598).

Either this or something else seems to not be the case anyway, as - in my case 
in Gentoo - when we keep 3rd party applications in /usr and - having KDE4 
installed in different prefix - I needed to explicitly instruct those 3rd 
party applications (via prefixes=/usr in ${KDEDIR}/share/config/kdeglobals) to 
look for their plugins there.

-- 
regards
MM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090606/cc17c22b/attachment.sig