Created attachment 165288 [details] [review]
Build the gtk-module for gtk-3.0 as well as gtk-2.0

Note: Javier's patch above does not work. First and most importantly, it builds both gtk+-2 and 3 handlers with the same includes and libs. So the gtk+-3 module ends up linked to libgdk-x11-2.0, which is not good.

Second, automake performs per-target object file naming only when per-target compilation flags are used. This means that with the above patch, gtk+-3 and gtk+-2 modules end up being built from the same object file, and that is almost certain to lead to interesting problems even if the Makefile used the proper libs for the gtk+-3 module.

Created attachment 188278 [details] [review]
Better patch for building gnomesegvhanlder for gtk-2 and gtk-3

Here is my take on the patch; I have tested it, and it builds and appears to work nicely, both with current git HEAD and with bug-buddy-2.32.0.

This patch allows bug-buddy's crash handler module to be built both for gtk-2 and 3. To test, export GTK_MODULES=gnomesegvhandler and make a gtk (2 or 3) application crash; if bug-buddy is installed, it will run and handle the crash.

Details:
* configure will take --enable-gtk2-segv-handler and --enable-gtk3-segv-handler options. By default, both options are "auto" (if the appropriate version of gdk is detected, the module for that version of gtk will be built), but can be set to "yes" or "no" to override that behavior.
* Both modules have the same name (libgnomesegvhandler, same as bug-buddy uses currently). They are built in separate subdirectories under segv_handler.
* The GDK_DISPLAY() macro in gnome-segvhanlder.c has been replaced with gdk_x11_get_default_xdisplay(), which AFAIK has been the recommended replacement for that macro since the first release of gdk-2. This is necessary since in gdk-3, GDK_DISPLAY is finally gone for good.
* Removed a comment about a long-abandoned idea that does not make sense (550135, resolved as NOTABUG in 2009).

Created attachment 193228 [details] [review]
bb patch

for bug-buddy;

I'd prefer either gtk2 or gtk3 module, not both. With this patch you can choose, but gtk3 is preferred (as gtk2 will come obsolete anyway), same as the whole bug-buddy interface is using the gtk version specified. This has also one more advantage, you are not forced to export environment variable GTK_MODULES, the module is loaded automatically, like it used to do.

(In reply to comment #4)

Your patch works too, and I can live with running configure twice to build plugins for different versions of gtk.

(One thing you may or may not want to look at is use of gtk2-only API, such as GTK_PROGRESS_LEFT_TO_RIGHT, in the .gtkbuilder file when running a gtk3-based bug-buddy. Doesn't affect the bug-buddy's functionality in any way as far as I can tell, but does result in some warnings being printed.)

You are right, I noticed those warnings too (the other is about separator not being there), though fixing it may result in providing two different .ui files (those are usually called .ui in gtk3), because it doesn't have conditionals in parsing). I decided to let it be as is after this finding.

Review of attachment 193228 [details] [review]:

::: configure.in
@@ +69,3 @@
 
+gtklibdir=`$PKG_CONFIG --variable=libdir $gtk_pkg_file`
+AC_SUBST(gtklibdir)

Why can't you just use $(libdir) in Makefile.am to construct the gnome-settings-daemon gtk-modules path?

::: data/Makefile.am
@@ +1,3 @@
 SUBDIRS = icons
 
+if BUG_BUDDY_GTK2_BUILD

I'm not sure this is completely right.
As far as I can see, the result is a GTK2 build of bug-buddy would not work with the 3.0 gnome-settings-daemon, as it uses GSettings to get the additional enabled GTK+ modules. Is this what you want?
Isn't it better to build two segvhandler modules (one linking to GTK2 and one linking to GTK3) instead, and choose a minimum g-s-d supported version (e.g. >= 3.0 in this case), dropping the GConf bits?

The gtklibdir is to ensure that files will be placed where gtk expects it. When I was compiling on my Fedora 15, then this was needed, because my gtk resided in /usr/lib64, where the build, even when configured with prefix /usr, is placed into /usr/lib, thus gtk cannot find it and it basically doesn't work. This seemed to me like a very nice way to ensure that gtk files are placed in the right place.

Alexander's patch provided both modules, built automatically, though for me it seemed better to build one or the other, also because bug-buddy itself is built for one or the other gtk, not always for gtk2 (as an effort to port it to gtk3 too). Thus the gtk2 build will only work with gtk2 applications, and not with gtk3. That's why I called it "Build target".

bug-buddy is not under active development anymore and had its last code changes
many years ago. Its codebase has been archived:
https://gitlab.gnome.org/Archive/bug-buddy/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality (see bug 796784). Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.