GNOME Bugzilla – Bug 614360
Help manage deprecation flags correctly
Last modified: 2014-05-02 17:09:36 UTC
Created attachment 157485 [details] [review] Proposed patch for gnome-common.m4 With all the GTK+ new deprecations leading up to version 3, the release team has been having a fun time with release tarballs that enable deprecation flags by default. As an Evolution maintainer I still want these flags enabled by default for development work, but I agree they should be disabled in release tarballs. What we need is a mechanism we can all agree on. Frederic Crozat suggested only enabling deprecation flags during configure if we detect we're in a git repository. I've encoded this policy into a new macro for gnome-common named GNOME_DEVELOPER_DEFINES, based on GNOME_MAINTAINER_MODE_DEFINES. The latter macro should be deprecated. According to recent posts on desktop-devel-list, automake's maintainer mode is the wrong mechanism for this.
I've worked in a similar patch, that added --enable-deprecated option. But I fine with this too. Take a look to bug #609810
I'm okay with --enable-deprecated, but I think the default should be based on whether a git repository is detected. So a hybrid of these two patches would be ideal.
There shouldn't be any need to detect a git repository. This is just a matter of whether or not you are using autogen.sh/autoreconf, I think. In the gtkmm world, thanks to Daniel Elstner, we have long had a configure.ac macro that uses the autotools idea of maintainer-mode, so we can use certain build options when using autogen.sh or when doing distcheck, without affecting tarballs builds. It works perfectly. The latest version is the MM_ARG_ENABLE_WARNINGS() macro, which is used in this example project: http://git.gnome.org/browse/mm-common/tree/skeletonmm/configure.ac#n55 It has some documentation here: http://git.gnome.org/browse/mm-common/tree/macros/mm-warnings.m4#n35 In Glom I still use the older DK_ARG_ENABLE_WARNINGS() macro and you can see where I've mentioned deprecations: http://git.gnome.org/browse/glom/tree/configure.ac#n189
Actually I think the deprecations shouldn't be enabled neither just because you use a git checkout, nor because you used autogen. That's because we should encourage contributors to do the right thing, i.e. use git, and we don't want them to have to fix unrelated stuff just because their distro is newer with new deprecations. So IMHO this macro should work like this: it should define a --disable-deprecated-functions (name not definitive) argument using AC_ARG_ENABLE, which those GNOME contributors that want to fix deprecations then use, possibly using the autoconf "site defaults" (see autoconf manual), or just for some modules individually. The macro should take the form GNOME3_DEPRECATIONS([VARIABLE],[EXTRA-DOMAINS],[EXCLUDE-DOMAINS]) where * VARIABLE is the name of the make variable with the FOO_DISABLE_DEPRECATED strings (using some standard name if empty), * EXTRA-DOMAINS specifies extra deprecation domains to use beyond the built-in default list, and * EXCLUDE-DOMAINS specifies domains from the default list that should NOT have the -$DOMAIN_DISABLE_DEPRECATED defined. Possibly the macro should also take the standard ACTION-IF-DEPRECATIONS-ENABLED and ACTION-IF-DEPRECATIONS-DISABLED arguments as 3rd/4th parameter. Finally, should this macro maybe live and be distributed in glib instead?
*** Bug 609810 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Actually I think the deprecations shouldn't be enabled neither just because you > use a git checkout, nor because you used autogen. That's because we should > encourage contributors to do the right thing, i.e. use git, and we don't want > them to have to fix unrelated stuff just because their distro is newer with new > deprecations. But it's not at all likely that the average contributors distro packages will be newer than the core developers' versions. It's certainly never been a problem for gtkmm.
True. However it also may be that they've built some other library from git too (e.g. a newer gtk because they need features from it), and then hit the new deprecations in the module they want to do unrelated work in.
> Finally, should this macro maybe live and be distributed in glib instead? Filled bug #635328
Although there has been a lot of discussion on this bug, with the new way of declaring API as deprecated as of GLib 2.32, bug 691139 is the spiritual successor. *** This bug has been marked as a duplicate of bug 691139 ***