libecal: Move EDataCalCallStatus back to libedata-cal.
authorMatthew Barnes <mbarnes@redhat.com>
Sun, 16 Dec 2012 16:43:01 +0000 (11:43 -0500)
committerMatthew Barnes <mbarnes@redhat.com>
Tue, 18 Dec 2012 12:44:05 +0000 (07:44 -0500)
commita1d63235f2778f6432abf480114c57b021f6a05b
tree3009097800555a051e900a533351f3d08ae5391a
parent5b6bee9d3ac6679db8ba2c8a95125c010d192bd3
libecal: Move EDataCalCallStatus back to libedata-cal.

I'm encountering a build break in Evolution on an older environment.

It goes something like this...

   /* In X11/X.h */
   #define Success 0

   /* In libecal/e-cal-types.h */
   typedef enum { Success, ... } EDataCalCallStatus;

After pre-processing, the compiler gets

   typedef enum { 0, ... } EDataCalCallStatus;

which of course is a syntax error.

It's our own fault for violating our own namespace.  The enum definition
was moved from libedata-cal to libecal fairly recently (by me) to resolve
a circular dependency, but it appears libecal does not really require the
enum values.  Move the typedef back to libedata-cal as a quick Band-Aid.

The EDataCalCallStatus enum is redundant anyway and I plan to remove it.
Equivalent error values are provided by EClientError and ECalClientError,
and calendar backends should be using them directly.  There's no need for
separate but equal client and server-side error value definitions.

This is technically an API break, but I'm not going to bump the libecal
soname over this.  The enum definition is clearly intended for backends,
and because it was moved to libecal only recently, I'm fairly certain no
client applications are using it.
calendar/libecal/e-cal-types.h
calendar/libecal/e-cal.c
calendar/libedata-cal/e-data-cal.h
docs/reference/calendar/libecal/libecal-sections.txt
docs/reference/calendar/libedata-cal/libedata-cal-sections.txt