[cairo] external backends

[Ross McFarland]

i apologize if this has been discussed or addressed previously. if it
has i didn't catch it.

in the past the thought had crossed my mind about an application
providing it's own custom cairo backend. this could be useful in some
situations, namely those which necessitate an output format that is not
part of core cairo and had not real useful outside of the particular
app. more than that cairo can't really be expected to consolidate every
possible backend that someone finds use for (at least i don't think it
would be worth the time and effort to try to do so.)

all of the recent license threads rekindled my thoughts on the subject
and lead me to another related thought. if a developer (group) wants to
use an unmodified cairo library in a situation that requires a
proprietary backend they probably should be able to do so. to do this
without modifying cairo in any way would require the ability to create
backends outside of core cairo. 

currently neither of these scenarios is workable. (so far as i can tell)
it is impossible to create backends outside of the cairo build process.
several things stand in the way. for starters cairoint.h (internals, not
int) and cairo_wideint.h are not installed, but are required by
backends. secondly the api requirements of a backend aren't met. part of
the missing api is hidden with preprocessor tricks and the other portion
aren't exported symbols. i would assume the reasons for this are to
prevent apps from having access to the protected api of cairo and i'm
completely behind that desire. however, perhaps a mechanism could be
employed to selectively expose the necessary api (something like #define
_CAIRO_BACKEND_API_) while still keeping it well hidden from apps.

currently the preprocessor tricks can be worked around with #undef
__GNUC__. but there are still several required functions (prefixed with
_) missing from the exported symbol tables. to test this concept i
pulled the png backend out and tried to get it to build. there are 8
undefined symbols (6 after the __GNUC__ hack.)

in the long run i would envision cairo's core becoming rather stable and
development on it slowing. i don't see this being the case as much for
backends. i would imagine there will always be new situations required
new backends or at least changes to existing backends. i don't see it
being efficient or really even a workable situation if everyone is
required to get their backends into core cairo or is required to
(legally and correctly) distribute a customized version (source and/or
binary) of cario with their own backend added. (this is even worse than
a forked cairo as they have no need or desire to modify it, just to add
another backend)

i don't think the changes required to enable eternal backends would be
substantial. mainly it would encompass something to prevent the
preprocessor magic and/or expose a bit more of the api. while this could
add a bit more to the list of required stable api, i don't think it
would be nearly as sensitive as application backends. and the same
amount of effort would be required if api changes are made and the
external backends were instead inside of core cairo. 

if after discussion it is decided that this should be addressed i'd be
willing to look into implementing the necessary infrastructure decided
upon.

thoughts appreciated,
-- 
-rm