[cairo] Entry points for nonexistent backends?

[Tor Lillqvist]

One thing related to cairo bindings especially for non-interpretd
languages, is this: How should such bindings handle backend-specific
cairo functions?

I guess this is not a problem on Linux because presumably distros tend
to build cairo with all possible backends, as the dependencies
required by them are all present anyway on typical installations, and
if not, handled sensibly by package management anyway.

But on Windows it is a real problem. There is no package
management. In general one should try to minimize the number of
dependencies a 3rd-party library has.

For instance the cairo DLL I distribute for use with GTK+ doesn't have
the FreeType font backend included, because there is no need for that
with GTK+. Including it would mean introducing a run-time dependency
on freetype and fontconfig.

(Note that dependent DLLs *have* to be present at run-time on
Windows. As far as I recall, this is unlike ELF-based systems, where
they need only be present if symbols from them are actually referenced
at run-time.)

I also build and distribute another cairo DLL that doesn't include
even the SVG, PDF and PS backends. I still use the same DLL name
(i.e. "soname" in ELF terminology) for it, because in other respects
it is binary compatible. (I.e. an app that uses only the Win32 backend
functions is able to run as well against a cairo DLL that also include
other backends.)

I don't know how much this win32-only cairo DLL actually gets used.
(IIRC I started building it on explicit request from somebody.)  For
some app that wants to use from cairo just the Win32 surface and font
backends, it should be enough. (GTK+ needs the PDF stuff because of
its printing support.)

So what has this got to do with bindings? Well, a binding can't know
what backends happen to be compiled in to the cairo shared object
present on a certain end-user system. I think the cairomm bindings,
for instance, *require* that the FreeType font backends are
present. Thus people who want to use cairomm on Windows can't use my
build of cairo.

For interpreted languages I guess this is not necessarily a problem as
the binding can check at run-time whether a specific function is
present or not. But for compiled language bindings like cairomm it can
be a problem.

I thus suggest that the public functions from the optional backends
should be always present in the cairo binary, but in such a form that
if the corresponding backend is not compiled in the functions would
always return NULL, -1, or whatever appropriate kind of error
indication. The CAIRO_HAS_* feature test macros in the corresponding
cairo-features.h header should still correspond to reality.

I'll submit a patch later (unless you convince me this is not a good
idea after all).

--tml