There are a number of steps that you can take to prepare your GTK+ 2.x application for the switch to GTK+ 3.

Make sure your program only include the toplevel headers: make CFLAGS+="-DG_DISABLE_SINGLE_INCLUDES -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES"

Make sure your program doesn't use any functions that have been deprecated in GTK+ 2.x: make CFLAGS+="-DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED"

GTK+ 3 removes many implementation details and struct members from its public headers. To ensure that your application does not have problems with this, you define the preprocessor symbol GSEAL_ENABLE. This will make the compiler catch all uses of direct access to struct fields so that you can go through them one by one and replace them with a call to an accessor function instead. make CFLAGS+="-DGSEAL_ENABLE"

Some software packages install loadable GTK+ modules such as theme engines, gdk-pixbuf loaders or input methods. Since GTK+ 3 is parallel-installable with GTK+ 2.x, the two GTK+ versions have separate locations for their loadable modules. The location for GTK+ 2.x is libdir/gtk-2.0 (and its subdirectories), for GTK+ 3 the location is libdir/gtk-3.0 (and its subdirectories). For some kinds of modules, namely input methods and pixbuf loaders, GTK+ keeps a cache file with extra information about the modules. For GTK+ 2.x, these cache files are located in sysconfdir/gtk-2.0. For GTK+ 3, they have been moved to libdir/gtk-3.0/3.0.0/. The commands that create these cache files have been renamed with a -3 suffix to make them parallel-installable. Note that GTK+ modules often link against libgtk, libgdk-pixbuf, etc. If that is the case for your module, you have to be careful to link the GTK+ 2.x version of your module against the 2.x version of the libraries, and the GTK+ 3 version against hte 3.x versions. Loading a module linked against libgtk 2.x into an application using GTK+ 3 will lead to unhappiness and must be avoided.