Re: [Kolab-devel] [pkg-kolab] Bug#730600: libkolab(xml): New upstream version available

Sandro Knauß <[email protected]> Thu, 26 Jun 2014 15:36:27 +0200

Newsgroups	gmane.comp.kde.devel.kolab
Message-ID	<1788802.nHtkBjNj0R__35229.66015521$1403790008$gmane$org@tabin.local>

Hi,

> So, is libcalendaring actually a REAL fork? Or is it a partial extract
> of the kdepimlibs that should better be maintained inside kdepimlibs?

well actually it is code copy from kdepimlibs and strip out many dependencies. 
We only update it, when we need new featuers or wanna remove bugs. But we have 
no code that lives in libcalendering only. The concept is, that everthing goes 
upstream ( kdepimlibs) and than we port back the parts we need into 
libcalendering. We want to get rid of libcalendering, if kdepim will be ported 
to frameworks. But this will take at least one or two years till this will 
happen for kdepim [0].

> As a prerequisite for packaging it for Debian, libcalendaring and
> kdepimlibs need to be installable on the same machine. The
> libkolab(xml) configure scripts should support build switches
> (--with-kdepimlibs, --with-libcalendaring). I haven't looked closer,
> so far. Is the parallel installability already given? Is there such a
> build option for libkolab(xml)?

The build/cmake option is available and is called
-DUSE_LIBCALENDARING=TRUE

Both can be installed at the same machine. the libs from caledering are 
called:
calendaring-kcalcore
calendering-*
[...]
see cmake/modules/FindLibcalendaring.cmake

Regards,

sandro

[0] http://lists.kde.org/?l=kde-pim&m=140362611108561&w=2
-- 
Sandro Knauß
Software Developer

Kolab Systems AG
Zürich, Switzerland

e: [email protected]
t: +41 43 501 66 91
w: http://kolabsys.com

pgp: CE81539E Sandro Knauß

_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel

signature.asc (application/pgp-signature, 819 B)