Modular building of kde modules

[Maciej Mrozowski]

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).

- some modules need to compile sth from the other modules (like some dialogs, 
they need to moc them, hence just extracting them doesn't work - observed in 
libkdepim as well, another example is generating dbus interfaces - as well 
"issue" of kdepim)

- some modules possibly would have circular build dependencies if built really 
separately (again kdepim: kresources<->akonadi)

- some modules just for now cannot be built separately, as they all are part 
of one export unit (KDE4Workspace). Actually they can be built separately, but 
their export file (KDE4WorkspaceLibraryTargets.cmake in this example) is not 
useful in such case (it's incomplete as only contains export for actually 
built module) cannot be used. So separating build process for modules in such 
organizational unit would require major rework of this mechanism. So far it's 
static export (doesn't support/detect dependencies and it would be necessary 
if for example KDE4Workspace was about to be built split) but provides out-of-
the box and reliable pkg-config sort of replacement.

-- 
regards
MM




----------------------------------------------------------------------
Program tylko dla graczy komputerowych! 
Ogladaj >>> http://link.interia.pl/f207f