the ways of reusing the code

[Andriy Rysin]

Hi all,

I have a question about splitting/linking different instantiations of same
module/application.
The question is about kxkb subproject but theoretically can apply to others
as well.
So currently kxkb subproject produces next targets:
- kcm config module (kcm_keyboard_layout lib)
- kdeinit app (kdeinit_kxkb lib + kxkb app)
- plasma applet (plasma_applet_kxkb lib)

Besides that, there's one "logical" target which (currently) is part of
kdeinit_kxkb library:
- the kxkb component (which is currently reused in runners' lockdlg).

So the split of the source files is like this (names are not real):
- 7 files are common for all targets
- kcm config module is made of ${common} + 1 kcm*.cpp file
- runtime sources (indicator + switching logic) is ${common} + 2 files (*
widget.cpp *core.cpp)
- kdeinit app is ${runtime} + 2 files (KApp.cpp + DBUS iface.cpp)
- component is ${runtime} + 1 component_iface.cpp
- applet is ${runtime} + applet.cpp (potentially can include DBUS as well if
we don't get rid of kxkb DBUS interface)

So I see 4 approaches on linking all of that:
1. (current) Define common source files and include them in all targets.
Currently the only exception is the component which is injected into
kdeinit_kxkb lib. This generates 3 libs (4 if component is made separate) +
1 app with a lot of code duplicated.
 advantage: simplicity of linking and having separate module for each type
 disadvantages: pretty much all code is duplicated; all libs should be
loaded separate
2. Create common lib to include ${common} and (possibly) ${runtime}; then
for each target link the main lib + 1 or 2 extra files
 advantage: most of common code is merged
 disadvantage: creating yet another library; and it has to be dynlinked for
every module starting
3. Merge everything into one lib and point app and *.dekstop file for
services to it.
 advantage: 1 lib + 1 app cover all cases: less space, less linking, faster
startup...
 disadvantages: lib names won't be following standard naming: kcm*, plasma_*
etc (not sure if it's possible to point services from *.dekstop in this
case); runtime modules will link libkio (for kcm) which they don't need is a
quite big; a bit larger than needed library for all cases but still it's
less linking and more sharing code so I think the performance and memory use
still will be better in this case.
4. generate 2 libs: 1 for kcm and 1 for all runtime - kinda compromise
between 1 and 3 - splitting config and runtime but otherwise trying to
compact as much as possible. It's still not perfect as (AFAIK) kcm is loaded
on startup anyway with kcminit and then starts kxkb app (if configured) so
both libs will have to load.

So the question is really which way is both possible and preferred with KDE4
architecture?

Thanks,
Andriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071017/2ca41941/attachment.htm>