I'm currently smoke testing Dan's webkit-composer branch before giving
him the go-ahead to merge it to master.

Immediately after the merge I'm going to consolidate Evolution's base
libraries into a single base utility library.  "libeutil" seems as good
a name as anything else I can think of, so I'm going to stick with that.

I'm also going to absorb libedataserverui back into Evolution, since
Evolution is now the only module using it (I've done my due diligence on
other modules that still show a dependency -- in most cases it was just
a historical artifact that could be dropped).  So all the non-deprecated
APIs in libedataserverui will become part of Evolution's new libeutil.

I plan to have this in for Evolution 3.7.3.

The new libeutil will include APIs that are currently scattered across:

   widgets/editor/libeeditor.so  (new in Dan's branch)
   libedataserverui/libedataserverui.so (from E-D-S)

At least, that's the list for starters.  I'd still like to keep things
like libemformat.so, libcomposer.so and libeshell.so separate.  I'm on
the fence about the smime libraries.

Additionally, since almost all the #include paths will need updating
anyway, I'm going to move libeutil to a single-include model like we've
done for Camel and E-D-S.  In addition to convenience, it helps shield
3rd party apps as well as our own extension packages from quite so much
API churn, even though we still make no guarantees about API stability
in Evolution libraries.

The new #include directive for libeutil will be

   #include <libeutil/libeutil.h>

which will bring in all headers in the library.

With all the base utility libraries under one header, maybe we can then
get serious about producing some good API documentation for this stuff.
My attempts thus far have been half-hearted at best.

Matthew Barnes

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to