On Friday 13 July 2012 Jul, Jaroslaw Staniek wrote: > On 13 July 2012 01:12, C. Boemann <c...@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
