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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
