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 700978 - Misc Utility Function g_build_filename() is not supported in GJS
Misc Utility Function g_build_filename() is not supported in GJS
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-05-24 21:43 UTC by Meg Ford
Modified: 2018-02-08 12:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Meg Ford 2013-05-24 21:43:51 UTC
Since GJS does not support vararg functions, g_build_filename(). It's my understanding that the bindings for varargs need to be implemented manually, as they are not supported by introspection. I am reporting the bug since (1) it is not documented anywhere; and (2) since there was a recent agreement that GJS would be the officially supported application language for GNOME, which may be an argument for adding a manually-implemented binding. Thanks!
Comment 1 Colin Walters 2013-05-24 21:49:04 UTC
You can use GLib.build_filenamev(["foo", "bar"]) instead. 

Yes, it's ugly, but it's just a fundamental tradeoff introspection makes.

Note introspection does support a "Rename to:" annotation, but the downside of that is that were we to do it now, the old symbol disappears.  Perhaps we need a "Rename to and keep:" annotation...I think I tried to implement that once.
Comment 2 Meg Ford 2013-05-24 22:04:53 UTC
(In reply to comment #1)
> You can use GLib.build_filenamev(["foo", "bar"]) instead. 

I am using it as a workaround. The general problem I think it that the missing functions need to at least be documented as missing in GJS, so people don't try to use them and fail. There are quite a lot of functions that don't work because of this, I'm finding. Some have alternative methods that are reasonable substitutes (like build_filenamev()), but others (e.g. element_link_many() in GStreamer, which requires a loop of element_link())do not.
> 
> Yes, it's ugly, but it's just a fundamental tradeoff introspection makes.
> 
> Note introspection does support a "Rename to:" annotation, but the downside of
> that is that were we to do it now, the old symbol disappears.  Perhaps we need
> a "Rename to and keep:" annotation...I think I tried to implement that once.

Having a solution in GObject would at least have the upside of maintainers not having to put up with a lot of bug reports from me :)
Comment 3 Matthias Clasen 2013-08-17 17:05:30 UTC
the real fix here is to finally have accurate, generated docs for bindings, I assume.
Comment 4 Meg Ford 2013-08-19 04:45:05 UTC
(In reply to comment #3)
> the real fix here is to finally have accurate, generated docs for bindings, I
> assume.

For this particular function it would be a good enough fix, I think. 

wrt automatically generated documentation for bindings (as they exist now), there are some issues that imo can't be addressed by automatically generated documentation (e.g. the generated documentation doesn't change return types for functions even if the type in gjs is different than the type in C). But I think I should file bugs against g-ir doc tool rather than trying to discuss those issues here.
Comment 5 André Klapper 2015-02-07 17:16:05 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 6 GNOME Infrastructure Team 2018-02-08 12:22:44 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/gobject-introspection/issues/87.