[Freeassociation-devel] Default value for ical_errors_are_fatal
Allen Winter
winter at kde.org
Mon Dec 15 06:41:32 PST 2008
On Monday 15 December 2008 6:01:41 am Suman Manjunath wrote:
> Hello,
>
> [This is my first post to this list.. apologies if I've missed
> following some etiquette :)]
>
> As a part of merging the GNOME libical fork changes upstream[1], I
> have bumped into an issue with the default setting of
> ical_errors_are_fatal.
>
> As of now, it is set to 1 (making libical crash on every call to
> icalerror_*), due to which:
>
> a) the Evolution guys have to set this variable to 0 in all related
> processes at runtime - Evolution, Evolution-Data-Server(EDS) and
> Evolution-Exchange
> b) any other application depending on the EDS libraries (libecal and
> libedata-cal) have to set it again to 0 as EDS itself might not be
> running
>
> This scales to any other application that does not want to go kaboom
> on calls to icalerror_*. ALL of them need to do the same thing - set
> ical_errors_are_fatal = 0
>
> Now, as mentioned in the configure.in of libical, the setting is for
> "test/regression.c (and maybe others) needs this defined". If it is
> required by test and regression suites, why force it on applications
> that depend on libical?
>
> It is quite simple to make this setting configurable (see attached
> patch). With the patch, ical_errors_are_fatal is set to 0 ONLY IF
> explicitly specified using the configure option. This makes life
> easier for the distros shipping libical (they can easily turn this
> off) and does not hurt the libical developers either (fatality enabled
> by default).
>
Except suppose another project (eg. KDE) want the opposite behavior?
Then a distro will have to choose who best to support. They won't
provide libical-barf and libical-nobarf packages.
All those asserts were a pain to deal with -- no doubt about it.
OTOH, we found real problems in our KDE code because of them.
So I'm more in favor of the applications dealing with it; either they
fix their code or they need to set the global variable appropriately.
More information about the libical-devel
mailing list