GNOME Bugzilla – Bug 618639
CTree header isn't compilable
Last modified: 2010-09-14 15:27:09 UTC
CTree header fails to compile, claiming that GtkCList isn't defined. This is because GtkCList includes gtksignal.h, that itself includes gtk.h, which includes gtkctree.h. The problem is that gtkclist.h defines it guard *before* including other GTK headers, and then its definitions and declarations aren't defined at this time, and will no be when included by other headers. A simple fix would be to move inclusions before that header guard. Please note that even if these widgets are deprecated since a while, some old applications still need them, and then fails to build. In facts I noticed this trying to compile Glade 2 (2.12.2).
What version of GTK+ are you using?
(In reply to comment #1) > What version of GTK+ are you using? 2.20.1, from Debian Testing.
Created attachment 170049 [details] [review] Don't include gtk.h from gtksignal.h Some old code includes gtkctree.h or gtkclist directly (e.g. glade 2.12), which then fails to build because gtkclist.h includes gtksignal.h, which itself includes the global gtk.h header. This is a problem because GtkCList already defined its guard, but gtkctree needs the GtkCList type to be defined. Another fix for this would be to move the inclusions before the guards, but it doesn't seem to fit GTK coding style.
[This is closed as OBSOLETE currently as CTree is dead.] No idea if this makes sense to add this only for GTK 2.22.
(In reply to comment #4) > [This is closed as OBSOLETE currently as CTree is dead.] > No idea if this makes sense to add this only for GTK 2.22. I think it does make sense since CTree is only deprecated in GTK2; and I'd think it means that it won't be updated, not that it might not work anymore. This is actually the same thing than an API break for the applications that use it: you couldn't build them anymore (although it can be fixed in the application side by simply including gtk.h and not gtkctree.h).
As far as I can see, the includes (gtkctree.h -> gtkclist.h -> gtksignal.h -> gtk.h) have been like this since forever (I checked as far back as 2.14. How is this a problem all of a sudden now, did something else change ?