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 769127 - Creates uncompilable bindings for grilo
Creates uncompilable bindings for grilo
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: GObject Introspection
unspecified
Other All
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-24 11:57 UTC by Bastien Nocera
Modified: 2018-05-22 15:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2016-07-24 11:57:22 UTC
vala-0.32.1-1.fc24.x86_64

After compiling grilo with --enable-vala, a vapi file is generated which contains:
                public void set_module (G.Module module);

This generates an error when trying to compile a program that uses the grilo VAPI (in this case, gnome-games):
grilo-0.3.vapi:578.27-578.27: error: The symbol `G' could not be found
		public void set_module (G.Module module);
		                        ^

You should be able to reproduce this problem easily through jhbuild:
jhbuild buildone grilo retro-gobject retro-gtk gnome-games
Comment 1 Bastien Nocera 2016-11-07 14:31:15 UTC
This is still a problem. It still makes gnome-games or anything that depends on the grilo Vala bindings unbuildable.
Comment 2 Bastien Nocera 2016-11-07 15:50:30 UTC
This commit "fixes" the problem:

commit 463d94d6022d3dd0acc8da8313ab10e01bfac7d9
Author: Bastien Nocera <hadess@hadess.net>
Date:   Mon Nov 7 16:33:01 2016 +0100

    core: Don't include private headers in introspection data
    
    We should only use the C sources, not the private headers in the
    introspection, so as to avoid making private API available.


It stops the gir file including grl_plugin_set_module() (a private API) in the gir file. That means that vapigen will try to add it to the bound API.

But I think that vapigen should error out instead of creating broken vapi files. Reverting the commit above, it's still possible to reproduce the problem.
Comment 3 Al Thomas 2016-11-07 18:05:21 UTC
The source for grl_plugin_set_module() ( https://git.gnome.org/browse/grilo/tree/src/grl-plugin.c#n346 ) includes the GObject annotation, "skip", for the symbol. "grl_plugin_set_module: (skip)"

Skip is documented ( https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations#GObject-Introspection_annotations ) and appears to be implemented ( https://bugzilla.gnome.org/show_bug.cgi?id=556628 )

The skip annotation should remove the symbol from the GIR and so vapigen just has to produce the VAPI based on the public GIR it is given. For vapigen to error out wouldn't it have to validate the symbols against the original C sources?
Comment 4 Rico Tzschichholz 2016-11-07 18:48:43 UTC
Using (skip) would have worked if the doc-blocks would use the correct syntax, e.g. starting with "/**"
Comment 5 Bastien Nocera 2016-11-07 20:33:01 UTC
(In reply to Rico Tzschichholz from comment #4)
> Using (skip) would have worked if the doc-blocks would use the correct
> syntax, e.g. starting with "/**"

That's a good point, but it would still be better if didn't write out broken vapi files. Whether or not the symbol is skipped isn't the problem. The problem is vapigen generating a .vapi file with a broken argument.

I'll reassign to vala, and fix those gtk-doc comments right now.
Comment 6 Al Thomas 2016-11-28 21:28:30 UTC
(In reply to Bastien Nocera from comment #5)
> The problem is vapigen generating a .vapi file with a broken argument.

The C signature from https://git.gnome.org/browse/grilo/tree/src/grl-plugin.c is:
void grl_plugin_set_module (GrlPlugin *plugin, GModule *module)

A GIR is produced then vapigen produces the Vala signature:
public void set_module (G.Module module);

whereas it should be (if the function wasn't skipped):
public void set_module (GLib.Module module);

From this it can be said GModule is translated to G.Module when it should be GLib.Module. What is confusing is GValue is fine. The GValue parameters show up as GLib.Value in the VAPI, not G.Value. I'm not sure what the difference is. Can you supply a simplified GIR that demonstrates the problem? It would be good to compare GModule with GValue in the GIR.
Comment 7 GNOME Infrastructure Team 2018-05-22 15:37:42 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/549.