Setting paths which depend on CMAKE_INSTALL_PREFIX

Andreas Pakulat apaku at
Sat Jun 6 11:56:53 CEST 2009

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


You will live to see your grandchildren.

More information about the Kde-buildsystem mailing list