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 _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers