GNOME Bugzilla – Bug 520756
different registry backend configurations cause build errors
Last modified: 2008-03-07 11:13:51 UTC
After some discussion on irc we concluded that instead of adding GST_USING_BINARY_REGISTRY, we clean the mess: a) Remove the _binary_{read|write}_cache declarations from gstregistry.h. They could not have been used as they we're relying on a define from config.h. keep the xml ones with a fixme for backwards compat. b) Add empty stubs for the gst_registry_xml versions of the functions when building the binary registry (in the end of gstbinraryregistry.c with a fixme) so that they're still available in the ABI, to avoid breaking any *existing* gst-python which might have been compiled to use them todo: * gst-python can provide stub wrappers * core can deprecate the xml_{read|write}_cache for next release
Created attachment 106686 [details] [review] implement the plan
In configure.ac there are two more GST_USING_BINARY_REGISTRY_DEFINE if I'm not mistaken (the undef in the else branch and the AC_SUBST), and the @GST_USING_BINARY_REGISTRY_DEFINE@ in gst/gstconfig.h.in should be removed again too, I think. Also, why are the xml bits are declared again in the #else branch in gst/gst_private.h?
Created attachment 106702 [details] [review] implementa the plan properly The xml bits in the #else branch are a comment to hint where they should be if we could move them out of registry.h.
Created attachment 106707 [details] [review] implement the plan properly Also remove from win32 file and gstconfig.h.in
Looks good to me now.
2008-03-07 Stefan Kost <ensonic@users.sf.net> * configure.ac: * gst/gst_private.h: * gst/gstconfig.h.in: * gst/gstregistry.h: * gst/gstregistrybinary.c: * win32/common/gstconfig.h: Move registry backend API to private headers where we can. Add fixme-0.11 comments for the others. Add stubs for the xml backend when using the binary to ensure they functions exists (they should not be used though). Fixes #520756.