On Thu, 2014-03-06 at 08:42 +0800, Nor Jaidi Tuah wrote:
/home/flavio/Documentos/JAMediaSuite/UbuntuRadio/vala/UbuntuRadio.vala.c:164:2: warning: 'gtk_window_set_opacity' is deprecated (declared at /usr/include/gtk-3.0/gtk/gtkwindow.h:142): Use 'gtk_widget_set_opacity' instead [-Wdeprecated-declarations] gtk_window_set_opacity ((GtkWindow*) self, 0.5); ^ /home/flavio/Documentos/JAMediaSuite/UbuntuRadio/vala/UbuntuRadio.vala.c: In function 'main': /home/flavio/Documentos/JAMediaSuite/UbuntuRadio/vala/UbuntuRadio.vala.c:377:2: warning: 'g_type_init' is deprecated (declared at /usr/include/glib-2.0/gobject/gtype.h:669) [-Wdeprecated-declarations] g_type_init (); ^
Michael already mentioned one fix for the g_type_init warning (--target-glib=2.36 or later), but I thought I would provide a bit of background on why we can't really solve this in Vala, and another way to resolve it in your project. First, the basic problem: before glib-2.36, you were supposed to call g_type_init before doing pretty much anything else. As of 2.36, g_type_init is deprecated and shouldn't be called. So, if we want the software to work with glib versions prior to 2.36, we *have* to include it. At this point, you may be thinking that we should just detect the version of glib on your system (`pkg-config --modversion glib-2.0`) and target that automatically. Sadly, doing this would mean that the C generated by a call to valac may only work on systems with a glib newer than the one they were generated on, and due to autotools distributing the generated C in release tarballs as well as the vast majority of Vala software using autotools, that's a *very* common situation to be in. Throw in the fact that a significant number of people developing software are on systems with very new versions of glib (especially people using jhbuild—my glib is git master from about 6 hours ago), and it's pretty obvious that automatically targeting the installed glib isn't going to work. Like Michael mentioned, you could pass -w to the C compiler (-X -w to valac) to just make the noise go away. However, glib from 2.26 on include a really awesome feature that we can use to fix this: "Version information" macros (<https://developer.gnome.org/glib/stable/glib-Version-Information.html>). These allow you to pass some defines to the C compiler to specify exactly which version of glib you're targeting and, when coupled with a matching --target-glib argument to valac, you can get rid of these warnings, as well as have the C compiler emit an error if you try to use a feature which requires a glib newer than what you're targeting. So, let's say you want to target glib-2.34. Assuming you're using autotools (because if you care about any of this stuff you probably are using a build system, and if you're using a build system with Vala odds are it's autotools), you'll end up with something like this: target_VALAFLAGS = --target-glib=2.34 target_CFLAGS = \ $(GLIB_FLAGS) \ -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_34 \ -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_34 Now your generated C will contain a call to g_type_init, but thanks to some clever macros glib knows not to complain about it. The GTK+ warning, OTOH, isn't really possible to get rid of without passing -wdeprecated-declarations (or just -w) to the C compiler. GTK+ doesn't (AFAIK) contain anything like the glib version macros, so your choices at a C level are live with the warning or change your code. When generating C code from Vala we can't just abandon support for old versions of GTK+ with every release, so switching to the new function isn't really an option. The processor conditions to support the --target-glib option have to be maintained manually, and we don't have the manpower to do it for anything other than glib. Really, the only solution is to stop distributing the generated C (probably not going to happen for a very long time, if ever, since it would be a backwards incompatible change for autotools) and stop distributing the bindings for GTK+ (and every other library) with Vala. -Evan
Attachment:
signature.asc
Description: This is a digitally signed message part