KDE/kdebase/workspace

[Alexander Neundorf]

On Thursday 08 October 2009, Michael Jansen wrote:

> > > We at least should support installing kdelibs separate and should
> > > hardcode the requirement "install all into the same prefix" into the
> > > kdebase/*/CMakeLists.txt files.
> > 
> > I don't understand this sentence. Should we support installing kdelibs
> > into a seprate directory or should we hardcode that kdebase must be
> >  installed into the same directory as kdelibs ?
>
> I meant we should support installing kdelibs into it own prefix. 
> 
> We could require that all kdebase/* modules are installed  into the same 
> directory. If we do we should hardcode it into the CMakeLists files.

Ah, ok. I think this would be acceptable (just IMHO).

> > > We currently totally fail to separate the three kdebase modules and
> > > kdelibs. I think kdepimlibs is safe to install into a different prefix.
> > > But if we keep all kdebase modules in the same prefix and put kdelibs
> > > into it's own many third party apps fail because they use the KDE_XYZ
> > > cmake vars instead of the appropriate KDEWORKSPACE_ ... vars.
> >
> > If that's the case we need to work on it.
> > I think it's doable, one by one.
>
> THat was a simplification. We will find:
>
> 1. Modules that depend on runtime (like nepomuk-kde) We have to either
> provide the runtime cmake files i comiited and reverted the last days or
> move everything from runtime that is needed externally somwhere else. Then
> the module has to be changes
>
> 2. Module that depend on kdebase/apps. We would have to create a cmake file
> for it like KDERuntime.cmake and port everything.

On what in kdebase/apps/ do these programs (which ones ?) depend ?

> 3. Modules that do find_package(KDE4) but want
> find_package(KDE4(Workspace|Apps| Runtime?). find_package(KDE4) is really
> find_package(KDE4libs) if we install kdelibs separately from kdebase.

If this is inside trunk/KDE/, we can fix it, otherwise it's basically a bug in 
the cmake files of that project.

> Many of the modules in 1-3 will be out of our control. 3rd Party apps so we
> will be unable to fix them.

Yes, we can only fix what is in trunk/KDE/, for everything else it's up to the 
author to do it right.

Maybe you should bring this issue up on kde-core-devel ?

Alex