Hi all,<br><br>I have a question about splitting/linking different instantiations of same module/application.<br>The question is about kxkb subproject but theoretically can apply to others as well.<br>So currently kxkb subproject produces next targets:
<br>- kcm config module (kcm_keyboard_layout lib)<br>- kdeinit app (kdeinit_kxkb lib + kxkb app)<br>- plasma applet (plasma_applet_kxkb lib)<br><br>Besides that, there's one "logical" target which (currently) is part of kdeinit_kxkb library:
<br>- the kxkb component (which is currently reused in runners' lockdlg).<br><br>So the split of the source files is like this (names are not real):<br>- 7 files are common for all targets<br>- kcm config module is made of ${common} + 1 kcm*.cpp file
<br>- runtime sources (indicator + switching logic) is ${common} + 2 files (*widget.cpp *core.cpp)<br>- kdeinit app is ${runtime} + 2 files (KApp.cpp + DBUS iface.cpp)<br>- component is ${runtime} + 1 component_iface.cpp<br>
- applet is ${runtime} + applet.cpp (potentially can include DBUS as well if we don't get rid of kxkb DBUS interface)<br><br>So I see 4 approaches on linking all of that:<br>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.
<br> advantage: simplicity of linking and having separate module for each type<br> disadvantages: pretty much all code is duplicated; all libs should be loaded separate<br>2. Create common lib to include ${common} and (possibly) ${runtime}; then for each target link the main lib + 1 or 2 extra files
<br> advantage: most of common code is merged<br> disadvantage: creating yet another library; and it has to be dynlinked for every module starting<br>3. Merge everything into one lib and point app and *.dekstop file for services to it.
<br> advantage: 1 lib + 1 app cover all cases: less space, less linking, faster startup...<br> 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.
<br>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.
<br><br>So the question is really which way is both possible and preferred with KDE4 architecture?<br><br>Thanks,<br>Andriy<br><br>