[SyncEvolution] Build fails with libical 2.0.0

[Patrick Ohly]

On Tue, 2016-01-19 at 11:25 +0100, Milan Crha wrote:
> 	Hello,
> I just realized that the syncevolution fails to build against
> libical 2.0.0. The problem is synevolution's extract of
> icaltz-util.c/.h, referencing extern const char *ical_tzid_prefix;
> This variable had been made private and there is no way to get to it
> from the outside of libical (the added icaltimezone_tzid_prefix() is
> not exported in the libical library).
> 
> I do not know the rationale with the icaltz-util extract in the
> syncevolution, but I'd say it's time to get rid of it when new-enough
> libical is used for the build. What do you think?

Does the libical 2.0 return "simple" VTIMEZONE definitions again, i.e.
ones with RRULEs for summer and winter time?

The reason for icaltz-util.c is this:

commit 9d13210d0bc5eba1e280fde7742a198e5631974f
Author: Patrick Ohly <patrick.ohly at intel.com>
Date:   Wed Mar 19 13:13:50 2014 +0100

    ical: workaround for libical 1.0 builtin timezone change
    
    libical 1.0 started to return VTIMEZONE definitions with multiple
    absolute transition times instead of RRULEs. This causes problems when
    exchanging data with peers (see
    https://sourceforge.net/p/freeassociation/bugs/95/).
    
    In SyncEvolution, this affected sending an event using New Zealand
    time in vCalendar 1.0 format to a phone, because the internal,
    out-dated definition of the time zone in libsynthesis was used as
    fallback when loading RRULE-based timezone definitions from libical
    failed (see "[SyncEvolution] Some events showing wrong time on
    phone"). It might also affect exchanging data with CalDAV peers (not
    tested).
    
    The workaround is to include the original code from libical from
    before the change in SyncEvolution and override
    icaltimezone_get_component() with a version that uses the original
    timezone loading code. This does not fix cases where other code causes
    libical itself to load a timezone, but for libsynthesis it is good
    enough because it does the loading early when no other code should
    have used libical.
[...]

I don't remember whether ical_tzid_prefix absolutely has to be the one
from libical or whether it can also be something else. I've not tested
with libical 2.0 yet.

I started testing, but ran out of time and patience. This whole "let's
break the ABI, people will recompile anyway" is making it harder and
harder to provide pre-compiled SyncEvolution binaries.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.