GNOME Bugzilla – Bug 575922
disabling subsystems cause API break
Last modified: 2009-03-23 14:23:51 UTC
running configure with e.g. --disable-dst-debug causes the debug system beeing compiled out. What I propose is to handle this more like we handle deprecated api. There we have DISABLE_DEPRECATED and REMOVE_DEPRECATED. The first hides it from the headers, so that people get compiler warnings, but existing binaries would run. The 2nd would cause the api break, which is not serious, if all software builds with with DISABLE_DEPRECATED. Now for the subsystems we could GST_DISABLE_GST_DEBUG could remove it from the header as it already does. In the .c file we could use: #ifndef GST_DISABLE_GST_DEBUG // normal api here #else /* !GST_DISABLE_GST_DEBUG */ #ifndef GST_REMOVE_DISABLED // dummy api here #endif /* GST_REMOVE_DISABLED */ #endif /* GST_DISABLE_GST_DEBUG */ This would require someone to build using make CFLAGS=-DGST_REMOVE_DISABLED to force the API break here. (this is in sync with: make CFLAGS=-DGST_REMOVE_DEPRECATED)
You mean disabling the debugging subsystem causes an *ABI* break, right? I think what you suggest makes sense in the sense that it's more consistent, but I'm not sure I see the use case for it. Who would want to disable the debugging system while still maintaining ABI compatibility?
I would allow to do a transition. Basically removing things from a library is anyway kind of dangerous. What I am proposing is 1) fix the api break that we cause currently 2) as its easy to add the #ifndef GST_REMOVE_DISABLED #endif provide a means for people to remove things with one flag If one needs to optimize the libarry size, the can do it in a bit safer fashion then: - phase 1 - build gstreamer with --disable-xxx - build other things that use gst, with -WError -DGST_DISABLE_DEPRECATED - phase 2 - build gstreamer with -DGST_REMOVE_DISABLED -DGST_REMOVE_DEPRECATED - rebuild all apps that use gst This only work in controlled environments. Not really feasible for distos (maybe except gentoo). It the approach is accepted (and I think we should to step 1), I will also write a page for the docs, about building gstreamer and explain there.
(In reply to comment #1) > You mean disabling the debugging subsystem causes an *ABI* break, right? > > I think what you suggest makes sense in the sense that it's more consistent, > but I'm not sure I see the use case for it. Who would want to disable the > debugging system while still maintaining ABI compatibility? The first use case that springs to mind is if you want to support binary plugin modules built by someone that might not care enough to ensure they build them against a GStreamer with the same stuff disabled as you have.
Hej, please reread. It is broken right now - if you use --disable-gst-xxx the resulting build has an api break - fact. I'd like to get an okay to first fix it like I described in first comment. I am waiting for two okays here. Then as it is not very intrusive, I would add #ifndef GST_REMOVE_DISABLED #endif to still provide a way to compile them out. If you are starting a new and closed platform, there is no risk in doing that. We have always alowed it.
Created attachment 131183 [details] [review] define stubs when disabling gst-debug subsystem
After minor correction from review with tim or irc. commit c04e3f9a0312656766833e8f614ee8bea01ee542 Author: Stefan Kost <ensonic@users.sf.net> Date: Mon Mar 23 15:18:21 2009 +0200 build: define stubs when disabling gst-debug subsystem. Fixes #575922 Running configure with e.g. --disable-dst-debug was compiling out the debug system (ABI break). Now stubs are added and only if one does e.g. make CFLAGS="-DGST_REMOVE_DISABLED" the symbols are ommitted.