Tor,      Would delay loading the dependent DLLs work? <a href="http://msdn2.microsoft.com/en-us/library/151kt790(VS.80).aspx">http://msdn2.microsoft.com/en-us/library/151kt790(VS.80).aspx</a> Thanks, Jonathan <div>On 8/15/07, Tor Lillqvist <<a href="mailto:tml@iki.fi">tml@iki.fi</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 <a href="mailto:cairo@cairographics.org">cairo@cairographics.org</a> <a href="http://lists.cairographics.org/mailman/listinfo/cairo"> http://lists.cairographics.org/mailman/listinfo/cairo</a> </blockquote></div>