Re: [Evolution-hackers] Front-end header files for E-D-S libraries

[Matthew Barnes <mbarnes redhat com>]

On Tue, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote:
> For 3.1, I would like to provide a top-level header file for each of the
> libraries in E-D-S and deprecate including individual header files.  The
> benefits should be clear by now: more flexibility to change or rearrange
> header files without breaking the public API.
> 
> Valid #include directives for E-D-S libraries will be:
> 
>    #include <libebackend/libebackend.h>
> 
>    #include <libedataserver/libedataserver.h>
> 
>    #include <libedataserverui/libedataserverui.h>
> 
>    #include <libebook/libebook.h>
> 
>    #include <libecal/libecal.h>
> 
> I'm not bothering with the backend libraries just yet.  They're less of
> an issue than the client-side libraries.
> 
> To enforce this we'll use the same mechanism as in GLib and GTK+, except
> for now we'll issue a #warning instead of an #error:
> 
>    #warning Including <libecal/e-cal.h> directly is deprecated.
>    #warning Please use #include <libecal/libecal.h> instead.
> 
> We could also test for an EDS_DISABLE_SINGLE_INCLUDES definition which
> would issue an #error instead of a #warning.
> 
> After maybe a year or two we'll crack down and issue #errors in some
> future 3.(odd).1 release.


Since I've already broken E-D-S APIs across the board for 3.5.3, I'm
following up on this as well.

Same plan as what I originally sketched out, except I'm skipping the
deprecation phase and moving straight to #error since there's no point
drawing this out, and I _am_ bothering with the backend libraries.  It
turns out to be nice for backends to just have one #include.

Matthew Barnes