Andreas Pakulat apaku at gmx.de
Tue Oct 5 17:50:54 BST 2010

On 05.10.10 18:47:21, Gregory Schlomoff wrote:
> Hello Christoph,
> I'm building a trimmed-down version of kdelibs (more precisely,
> kdecore, kdeui, and kio) in order to make a version of kdepimlibs that
> is easily embeddable in a non-KDE (and usually, Windows) application.
> The rationale behind this is that there are lots of applications that
> could benefit from the kdepimlibs (for example, there are not many
> good modern, asynchronoous, open-source C++ IMAP parsers  out there),
> but integrating them in a non-KDE application is hard because you have
> to throw the full KDE stack in your application.
> So my goal is to build a trimmed-down, statically-linked version of
> the main dependencies of kdepimlibs, so that's it's easier for an
> application developper to use them.
> Most of the time, I do this by following WINCE-specific paths in the
> CMakeLists files, because they usually do a great job at cutting out
> features, and that's how I ended up building kdeui without
> KSvgRenderer, thus the linker error.
> I would normally keep those changes as private patches, but in this
> case, since there was a clear dependency of kicondialog.cpp on QtSvg,
> I figured out it wouldn't hurt if I fixed it in the trunk, even
> though, as you pointed out, this is not normally a problem as QtSvg
> usually gets linked to by KSvgRender.
> I apologize in advance if this was a wrong decision.

I think you should decide wether you want to include svg-support or not.
If you'd like those 'trimmed-down' kdelibs to have svg support, then
enable ksvgrenderer. If you want to disable-svg-support you should put
kicondialog into a wince-section as well and remove the linking to QtSvg


Next Friday will not be your lucky day.  As a matter of fact, you don't
have a lucky day this year.

More information about the kde-core-devel mailing list