[calligra] /: Move core parts of KexiDB lib to libcalligradb

[Boudewijn Rempt]

On Friday 13 July 2012 Jul, Jaroslaw Staniek wrote:
> On 13 July 2012 01:12, C. Boemann <cbo at boemann.dk> wrote:
> 
> > No, it's a hard dependency for Words/kotext, but for CREATIVEONLY I have no
> > objection, though it will mean that there will be no textshape either (well I
> > guess it can be ifdef'ed)
> 
> True. So is the Biblio feature really so tied to kotext?
> If our aim is to provide ODF handling libs, Calligra Engine(s), maybe
> we could add config option to switch it off for fine grained control
> (like Qt does when you can switch off even 'fundamental' features,
> e.g. tooltips -QT_NO_TOOLTIP- or cursors) -- for those who really know
> what they're doing.
> 
> Then we could craft what happens when SHOULD_BUILD_CALLIGRADB if FALSE
> (disables the Biblio, Words, limits kotext (not sure, if you agree
> here?), disables Kexi, disables any data handling plugin in other apps
> such (in the future) a Sheets' data connectivity plugin, or future
> Mailmerge feature in Words.
> 
> Flexibility is a +1, but one -1 (besides adding further complexity to
> cmake files) is that these build profiles should only be used for
> custom builds. We don't want stripped-down Word in the popular
> distros, for example, not being able to handle the Biblio feature.
> 
> 

Doing this through cmake is the wrong approach. Heavy dependencies like this have to be plugins, so applications other than Words can blacklist them. I already get enough flak for what apt-get install krita drags in on *buntu.

Distributions will always package nearly everything, but might be smart enough to not make every words plugin's dependencies 
required for every other calligra app.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl