On Thursday 19 March 2009, Maciej Mrozowski wrote: > On Thursday 19 of March 2009 22:49:13 Alexander Neundorf wrote: > > On Thursday 19 March 2009, Lubos Lunak wrote: > > > On Wednesday 18 of March 2009, Parker Coates wrote: > > > > For example, my app Killbots is quite happy to be built as part of > > > > the KDEGames module. But to build it as a standalone app would > > > > require adding some setup and dependency checks to the CMake file. > > > > These are normally performed by the module level CMake file, so > > > > blindly including them in my app would lead to double checks the > > > > majority of the time. > > > > > > I am not a cmake expert, but I thought results of checks were cached, > > > so repeating them shouldn't matter? > > > > That's correct. But it leads to more cmake script code in our > > repositories (i.e. it would look more crowded/complicated). > > Besides it's not possible to really build everything separately (for now) > due to following reasons: > > - some modules rely on relative include paths or just assume that whole > toplevel directory (like kdebase/workspace) is present and available. This > is due to fact, that some library include files reused by many modules are > not installed. The notable example is libkdepim - it's added to includedirs > in toplevel CMakeLists.txt, so it just needs to be present while building > any other kdepim module, even when libkdepim is actually installed in > system. There are some other examples like recently added > screenpreviewwidget to libs/kworkspace (reused by kwin, but > screenpreviewwidget.h is not installed along libkworkspace), some files > from libkonq needed by dolphin and konqueror to be build > (konq_copytomenu.h, konq_popupmenuinformation.h) and many more (I could > provide a list if anyone is interested).
Yes, applications which use libs from the own module need more work. > - some modules need to compile sth from the other modules (like some I think now we are getting in trouble with terminology. You mean "directories" inside the modules, not "modules", right ? > - some modules possibly would have circular build dependencies if built > really separately (again kdepim: kresources<->akonadi) I didn't check, but that shouldn't be the case. If it was, I think we would have a problem already right now ? > - some modules just for now cannot be built separately, as they all are > part of one export unit (KDE4Workspace). Actually they can be built Two issues here: -finding the right "granularity" for these files (I'd like to make kdelibs at least partially separately installable) -do we really want to support installing each library separately, e.g. from kdebase/workspace ? (I don't think so) Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
