Most Deprecated GTK+ 2 API is not in GTK+ 3
GTK+ 3 has API changes compared to GTK+ 2, but some of the new API has been added to GTK+ 2.22 and 2.24, and older API has been deprecated. gtkmm has done this too. This is intended to ease porting to GTK+ 3 (or gtkmm 3). If your application builds with GTK+ 2.24 with deprecated API disabled then it will be much easier to port to GTK+ 3 afterwards.
This requires defining C macros such as GTK_DISABLE_DEPRECATED, though you’ll want to use GDK_DISABLE_DEPRECATED, GDK_PIXBUF_DISABLE_DEPRECATED, G_DISABLE_DEPRECATED and maybe PANGO_DISABLE_DEPRECATED too. You can specify these as -D options in your Makefile.am.
However, you should not disable deprecated API in your build at all times. That just makes life unnecessarily difficult for people building from tarballs.
So over the last few years, Daniel Elstner has perfected an MM_ARG_ENABLE_WARNINGS m4 macro for use with autotools. It adds an –enable-warnings=min/max/fatal/no configure option. We use it mostly to turn on compiler-warnings-as-errors, but I think that it would be very useful to many people now during the transition to GTK+ 3.
MM_ARG_ENABLE_WARNINGS
This macro is in mm-common, which you could depend on, though it contains other stuff that is only interesting to gtkmm projects. For instance, I use it in Glom’s configure.ac file, like so:
MM_ARG_ENABLE_WARNINGS([MYPROJECT_WFLAGS],
[-Wall],
[-Wall -Wextra -Wno-missing-field-initializers -DGSEAL_ENABLE],
[G GDK GDK_PIXBUF PANGO GTK])
I then use the resulting variable in my Makefile.am file, like so:
AM_CFLAGS = $(MYPROJECT_WFLAGS)If you use non-recursive autotools (and you should) then you won’t need to repeat that much.
I also added the option to DISTCHECK_CONFIGURE_FLAGS so I am forced to fix any warnings during make distcheck, when doing a tarball release. You don’t need to do that.
Whenever I build one of these projects from git I specify –enable-warnings=fatal to autogen.sh and fix any problems that it finds. That’s why there are zero compiler warnings or use of deprecated API in Glom.
DK_ARG_ENABLE_WARNINGS
You might prefer to copy the standalone version into your project instead. There are copies of the standalone macro in various projects already. Here is an example commit that adds it to a project.
The macro call looks like this in your configure.ac, for instance:
DK_ARG_ENABLE_WARNINGS([MYPROJECT_WFLAGS],
[-Wall -w1],
[-pedantic -Wall -Wextra -w1],
[G GDK GDK_PIXBUF PANGO GTK])
You mention it in your post, but I think it bears repeating, with a little extra emphasis.
You should not disable deprecated API in your build at all times. Particularly not in any shipping release tarballs!
Why? Because you don’t know what version of Gtk+ or other Gnome libraries will be used when compiling your application. It’s possible, and indeed very common, that someone with a newer version of Gtk+ will try to compile your application, only to have it fail with a build error, claiming some structure fields are no longer there, or some function that you used doesn’t exist.
New fields are being added to the deprecated list all the time. You can’t predict the future, so don’t disable deprecated Gtk+ functionality in your releases! (The same goes for -Werror; new GCC warnings are added regularly.)
> new GCC warnings are added regularly
And? If your code is standard compliant you should get no warning at all. If you do, you should report compiler’s bug. If your code is “custom standard compliant” than you should consider rewriting your code.
Developers wanting to ease porting their applications to gtkmm-3.0 should also add GLIBMM GIOMM PANGOMM CAIROMM GDKMM GTKMM to the deprecation flags, shouldn’t they?
Krzesimir, yes, as I do in Glom. Well, I think I’ve forgotten GIOMM.
The proper way to handle the “DISABLE_DEPRECATED” macros is to only enable them for the library version that you know your code compiles with cleanly. The solution you are proposing here is almost as annoying as having the macros always enabled. Rather fix it once and for all and use something like:
AC_MSG_CHECKING([if GLib is version 2.26.0 or newer])
if $PKG_CONFIG –atleast-version=2.26.0 glib-2.0; then
have_glib_2_26=yes
else
have_glib_2_26=no
fi
AC_MSG_RESULT($have_glib_2_26)
if test “x$have_glib_2_26” != “xyes”; then
CPPFLAGS=”${CPPFLAGS} -DG_DISABLE_DEPRECATED”
fi
Sven, if you have stopped using some deprecated API, then you probably started using the new replacement API. So you’d also need IFDEFs to support both APIs to make that work at all. I personally avoid that whenever possible, just branching to use a specific version. That has worked well for me for several years. This macro is very old news for the gtkmm people.
But even if you try it, at least it’s only an issue for people using git, not tarballs, and they have a fairly good chance of installing the latest API. And if they can’t, then they just don’t have to use this configure option.
But I’d be interested in some alternative macro that people could use easily, which doesn’t force people to use these options with tarball builds.