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 667894 - Add a glib-unix-2.0 package
Add a glib-unix-2.0 package
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Bindings: GLib
unspecified
Other All
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks: 660235
 
 
Reported: 2012-01-13 19:33 UTC by Philip Withnall
Modified: 2012-02-05 13:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vapi: Add a glib-unix-2.0 package (9.81 KB, patch)
2012-01-13 19:35 UTC, Philip Withnall
none Details | Review
vapi: Add glib-unix.h functions to glib-2.0.vapi (1.67 KB, patch)
2012-01-21 10:18 UTC, Philip Withnall
none Details | Review
vapi: Add glib-unix.h functions to glib-2.0.vapi (updated) (1.67 KB, patch)
2012-02-04 19:05 UTC, Philip Withnall
committed Details | Review

Description Philip Withnall 2012-01-13 19:33:18 UTC
There are a couple of useful functions in glib-unix.h which need binding for Vala. Patch coming up.
Comment 1 Philip Withnall 2012-01-13 19:35:06 UTC
Created attachment 205220 [details] [review]
vapi: Add a glib-unix-2.0 package
Comment 2 Luca Bruno 2012-01-13 20:18:57 UTC
I believe the .gi + .metadata + custom are longer than the vapi itself :-) Do you think it's going to be that hard to maintain (i.e. many more functions coming) to require automatic generation?
Also if there's no glib-unix-2.0.pc file, it's unnecessary to have a separate vapi.
Comment 3 Philip Withnall 2012-01-16 09:01:46 UTC
(In reply to comment #2)
> I believe the .gi + .metadata + custom are longer than the vapi itself :-) Do
> you think it's going to be that hard to maintain (i.e. many more functions
> coming) to require automatic generation?

I don't really know. I expect functions would be more likely to be added to gio-unix instead, but I guess new ones could be added to glib-unix as well.

> Also if there's no glib-unix-2.0.pc file, it's unnecessary to have a separate
> vapi.

Even if glib-unix uses a separate C header file? Are you saying I should get rid of the .gi, .metadata and -custom files, and merge the .vapi into glib-2.0.vapi?
Comment 4 Luca Bruno 2012-01-16 09:09:44 UTC
(In reply to comment #3)
> Even if glib-unix uses a separate C header file? Are you saying I should get
> rid of the .gi, .metadata and -custom files, and merge the .vapi into
> glib-2.0.vapi?

Yes, as long as there's no glib-unix library. If they use a separate C header file, just summon cheader_filename.
Comment 5 Philip Withnall 2012-01-21 10:18:08 UTC
Created attachment 205756 [details] [review]
vapi: Add glib-unix.h functions to glib-2.0.vapi

How about this?

One of these days I'll somehow manage to write a .vapi file patch which gets accepted first time.
Comment 6 Luca Bruno 2012-01-21 10:52:00 UTC
(In reply to comment #5)
> Created an attachment (id=205756) [details] [review]
> vapi: Add glib-unix.h functions to glib-2.0.vapi
> 
> How about this?

Looks good. Any particular reason for the UnixSignal namespace instead of a simple unix_signal_add ? A namespace containing only one function isn't worth it.
Comment 7 Philip Withnall 2012-01-21 11:34:06 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Created an attachment (id=205756) [details] [review] [details] [review]
> > vapi: Add glib-unix.h functions to glib-2.0.vapi
> > 
> > How about this?
> 
> Looks good. Any particular reason for the UnixSignal namespace instead of a
> simple unix_signal_add ? A namespace containing only one function isn't worth
> it.

UnixSignal and UnixSignalSource were designed to follow the pattern of things like Timeout and TimeoutSource, since they're all ways of creating GSources. I think it works quite neatly.
Comment 8 Philip Withnall 2012-02-01 23:19:14 UTC
Ping?
Comment 9 Luca Bruno 2012-02-02 07:59:51 UTC
(In reply to comment #7)
> UnixSignal and UnixSignalSource were designed to follow the pattern of things
> like Timeout and TimeoutSource, since they're all ways of creating GSources. I
> think it works quite neatly.

We thought having a Unix namespace was another neat solution. Then have all static methods in there, without further sub namespaces. What do you think?
Comment 10 Philip Withnall 2012-02-03 21:29:24 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > UnixSignal and UnixSignalSource were designed to follow the pattern of things
> > like Timeout and TimeoutSource, since they're all ways of creating GSources. I
> > think it works quite neatly.
> 
> We thought having a Unix namespace was another neat solution. Then have all
> static methods in there, without further sub namespaces. What do you think?

That would also work fine, though would break the symmetry between UnixSignal.add() and Timeout.add(). I don’t think that’s a problem though. Shall I produce an updated patch?
Comment 11 Luca Bruno 2012-02-04 09:54:20 UTC
(In reply to comment #10)
> That would also work fine, though would break the symmetry between
> UnixSignal.add() and Timeout.add().

A namespace for one function is not worth it.

> Shall I produce an updated patch?

Patches are always welcome :-)
Comment 12 Philip Withnall 2012-02-04 19:05:42 UTC
Created attachment 206774 [details] [review]
vapi: Add glib-unix.h functions to glib-2.0.vapi (updated)

This moves everything inside a GLib.Unix namespace.
Comment 13 Luca Bruno 2012-02-05 11:06:52 UTC
Review of attachment 206774 [details] [review]:

Thanks for the patch.
Comment 14 Philip Withnall 2012-02-05 13:45:13 UTC
Comment on attachment 206774 [details] [review]
vapi: Add glib-unix.h functions to glib-2.0.vapi (updated)

commit 908e52301b10669149821888d02d6090b38c1dbf
Author: Philip Withnall <philip@tecnocode.co.uk>
Date:   Fri Jan 13 19:30:29 2012 +0000

    vapi: Add glib-unix.h functions to glib-2.0.vapi
    
    To bind the things in glib-unix.h. Creating a separate glib-unix-2.0.vapi is
    unneccessary because these functions are present in libglib-2.0.so itself,
    rather than a separate library. They just require the glib-unix.h header to
    be included.
    
    Closes: https://bugzilla.gnome.org/show_bug.cgi?id=667894

 vapi/glib-2.0.vapi |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)