Modular building of kde modules
reavertm at poczta.fm
Thu Mar 19 22:47:56 GMT 2009
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.
Program tylko dla graczy komputerowych!
Ogladaj >>> http://link.interia.pl/f207f
More information about the kde-core-devel