GNOME Bugzilla – Bug 764420
Change default target for GLib version to that of host machine at compiler runtime
Last modified: 2018-05-22 15:33:17 UTC
The Vala compiler can select code paths based on the targeted version of GLib. With bindings this is done in the VAPI with: #if GLIB_X_YY ... #else ... #endif In the Vala compiler this is done with: if (!context.require_glib_version (X, YY)) { } else { } For the current stable release of Vala, 0.32.0, this mechanism is used only twice in VAPI bindings distributed with Vala and only once in the Vala compiler. These are MarkupParseContext and OptionGroup in the glib-2.0.vapi and GtkTemplate in codegen/valagtkmodule.vala. By default Vala will target a version of GLib from several years ago and this has caused confusion for new users of Vala in the past because the feature they are trying to use in GLib is not being found. This was the case with some of the GLib.Test functions when Vala was targeting 2.24 by default for example. This could also be a problem with future features of Vala such as a switch to using GTask in the async module - see https://bugzilla.gnome.org/show_bug.cgi?id=763345 At present it is assumed anyone using Vala knows about GLib versions and to use newer features they with use the --target-glib option when compiling. This favours anyone compiling programs that will be distributed and used on older distributions of GLib.
Created attachment 325093 [details] [review] Use version of GLib on host machine when valac is run This patch makes it easier for most users of valac to use the features available in GLib on their machine when compiling. For anyone creating a binary that will be distributed to others, it is assumed the binary will be compiled with valac on a host machine that has the target minimum version of GLib. An example would be distribution build machines. Otherwise this can be changed manually using the --target-glib option of valac.
Created attachment 325096 [details] Test case. For Vala 0.32.0 the GtkTemplate attribute is the only part of the vala compiler that uses a target GLib Compile with: valac --pkg gtk+-3.0 test_for_target-glib_using_gtktemplate.vala For Vala 0.32.0 this will produce: error: glib 2.38 is required for using Gtk templates (with --target-glib=2.38) When adding --target-glib=2.38 the error is because there is no GResouces file, which is correct: error: UI resource not found: `/empty/test'. Please make sure to specify the proper GResources xml files with --gresources. With the patch applied and building a current Linux distribution, such as Fedora 23, there is no need to use --target-glib=2.38. To simulate the old behaviour then --target-glib=2.32 will produce the error about Gtk templates needing a newer version of GLib.
FWIW, I'm -1 on this. Probably a decision for Jürg, though.
The current situation may not be ideal, however, the proposed patch would cause other issues. The content of tarballs created via autotools 'make dist' would differ based on the machine's GLib version, if --target-glib is not specified. Due to this I agree with Evan that this patch should not be applied as is. However, one option would be to change the behavior only when -C is not specified. I.e., when you don't distribute the generated C code, there should be no issue using all features of the installed GLib library. It may still create some confusion, though. I'm not sure whether it'd be better or worse than the status quo.
(In reply to Jürg Billeter from comment #4) > However, one option would be to change the behavior only when -C is not > specified. I.e., when you don't distribute the generated C code, there > should be no issue using all features of the installed GLib library. It may > still create some confusion, though. I'm not sure whether it'd be better or > worse than the status quo. I do see the advantages there, but I think I would prefer consistency… it would be pretty annoying for someone with working code to add a build system and start getting weird errors. Changing the targeted version of glib is a non-obvious side effect for -C, which is problematic for debugging.
I encourage to take a look at https://bugzilla.gnome.org/show_bug.cgi?id=763345, it's kind of similar.
Comment on attachment 325093 [details] [review] Use version of GLib on host machine when valac is run As mentioned, this is not a good idea, and passing the wanted target-glib is still preferred.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/533.