[cairo] Entry points for nonexistent backends?

Jonathan Chambers joncham at gmail.com
Wed Aug 15 04:49:46 PDT 2007

     Would delay loading the dependent DLLs work?



On 8/15/07, Tor Lillqvist <tml at iki.fi> wrote:
> 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
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20070815/a7726f29/attachment.html 

More information about the cairo mailing list