GNOME Bugzilla – Bug 662374
Deprecate StaticMutex, StaticRecMutex, StaticRwLock and StaticPrivate
Last modified: 2011-12-08 13:43:48 UTC
glib 3.2 deprecates the C equivalents of these structs, because the non-Static ones, such as GMutex can now be allocated statically. Actually, I think that dynamic allocation of them is now deprecated, though we can deal with that separately. Here is the beginnings of a patch to deprecate them. Unfortunately, Glib::Mutex derives from Glib::StaticMutex, and the others do the same, so we will need to duplicate some the the Static* API in the non-Static versions. That should be just an API break, and not an ABI break, which is acceptable.
Created attachment 199619 [details] [review] glibmm_thread_staticmutex_deprecation.patch
Created attachment 202766 [details] [review] fix thirs-party applications FTBFS when including glibmm/thread.h
The following patch has side effects when compiling third-party applications with -Werror=deprecated-declarations like systemtap-grapher (RHBZ #759644 -- see https://bugzilla.redhat.com/show_bug.cgi?id=759644). It seems that template methods using deprecated symbols in glibmm/thread.h fail builds even if they are not instantiated. A workaround could be using non-template private methods (or helper functions not to break ABI) to implement the bodies of StaticPrivate<T>::set, StaticPrivate<T>::get and Private<T>::Private so that the following deprecated symbols: g_static_private_set, g_static_private_get, g_private_new. But this is probably suboptimal. I attached a patch which solves the aforementioned issue, using helper functions.
I should have closed this bug a while ago, because the changes, and more were made in git master. (In reply to comment #3) > The following patch has side effects when compiling third-party applications > with -Werror=deprecated-declarations like systemtap-grapher (RHBZ #759644 -- > see https://bugzilla.redhat.com/show_bug.cgi?id=759644). > It seems that template methods using deprecated symbols in glibmm/thread.h fail > builds even if they are not instantiated. This seems to be just a matter of builds failing when using -Werror=deprecated-declarations. They should fail in that case, because the deprecated methods are used in the headers. However, this is annoying, so we should probably try to prevent that with some ifdef/undef stuff like we already have for the old -DG_DISABLE_DEPRECATED system. But actually maybe this is indeed a neater way to do it. I'll try it out and maybe push it later.
I have pushed that with small changes: - Fixed the eGDestroyNotify typo. - Added a ChangeLog entry. - Added doxygen comments saying that these are for internal use. The whole file is in deprecation ifdefs anyway. Thanks.
(In reply to comment #5) > - Added doxygen comments saying that these are for internal use. The whole file > is in deprecation ifdefs anyway. In that case, it would be better to use the ‘internal’ directive provided by Doxygen: http://www.stack.nl/~dimitri/doxygen/commands.html#cmdinternal
OK. Feel free to use that there or anywhere else that's appropriate. Thanks.