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: kna...@kolabsys.com t: +41 43 501 66 91 w: http://kolabsys.com pgp: CE81539E Sandro Knauß
signature.asc
Description: This is a digitally signed message part.
