After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764420 - Change default target for GLib version to that of host machine at compiler runtime
Change default target for GLib version to that of host machine at compiler ru...
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2016-03-31 15:27 UTC by Al Thomas
Modified: 2018-05-22 15:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use version of GLib on host machine when valac is run (1.13 KB, patch)
2016-03-31 15:37 UTC, Al Thomas
rejected Details | Review
Test case. For Vala 0.32.0 the GtkTemplate attribute is the only part of the vala compiler that uses a target GLib (96 bytes, text/plain)
2016-03-31 15:44 UTC, Al Thomas
  Details

Description Al Thomas 2016-03-31 15:27:30 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.
Comment 1 Al Thomas 2016-03-31 15:37:05 UTC
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.
Comment 2 Al Thomas 2016-03-31 15:44:29 UTC
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.
Comment 3 Evan Nemerson 2016-03-31 18:47:45 UTC
FWIW, I'm -1 on this.  Probably a decision for Jürg, though.
Comment 4 Jürg Billeter 2016-03-31 19:09:29 UTC
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.
Comment 5 Evan Nemerson 2016-03-31 20:32:49 UTC
(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.
Comment 6 Marcin Lewandowski 2016-04-01 18:49:58 UTC
I encourage to take a look at https://bugzilla.gnome.org/show_bug.cgi?id=763345, it's kind of similar.
Comment 7 Rico Tzschichholz 2016-10-13 19:23:34 UTC
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.
Comment 8 GNOME Infrastructure Team 2018-05-22 15:33:17 UTC
-- 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.